Skip to content
This repository has been archived by the owner on Jul 7, 2021. It is now read-only.

BGP Redundancy #33

Open
bmfrench89 opened this issue Jun 19, 2018 · 6 comments
Open

BGP Redundancy #33

bmfrench89 opened this issue Jun 19, 2018 · 6 comments

Comments

@bmfrench89
Copy link

Can you walk me through how to set up the BGP redundancy on the Palo Alto? I am currently trying to deploy this in an unsupported region of AWS and therefore trying to reverse engineer the template, which is taking quite some time.

Thanks!

@jpeezus
Copy link
Contributor

jpeezus commented Jun 19, 2018

You can take the configuration snapshot from the provided bootstrap.xml file and load it onto a device but NOT commit in order to see the configuration. That is one option from the Palo Alto Side of things. From the AWS side you will need to look up how to configure BGP. Here is an AWS article this combines the two

https://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/palo-alto.html

@bmfrench89
Copy link
Author

So after going through and looking at the bootstrap.xml file I noticed we have a different setup....

In your setup you have 1 VR and 1 interface with multiple tunnels per Palo Alto (PA active and PA passive) in the group. We are trying to set up multiple VRs, tunnels, and interfaces in a 1:1 ratio.

We have been successful in setting up pretty much everything and we have been successful in setting up routing in one of the Palo Altos. However, by manually disabling one of the tunnels on the active Palo Alto traffic to the attached VPC no longer makes it to it's destination. Should we be able to sustain a 1 tunnel failure?

I realize that this may be a lot to discuss via a forum, would it be better to direct message you via email or another form of messaging?

We would GREATLY appreciate it :-D

@tbone31
Copy link

tbone31 commented Jun 22, 2018

I'm having a very similar problem. Any help would be appreciated. @jpeezus

@jpeezus
Copy link
Contributor

jpeezus commented Jun 22, 2018

The 2 VM-Series firewalls that are spun up are in an Active/Passive which means 1 firewall is active BGP and the second is passive. That is how the Transit VNet solution handles failover. If I understand correctly you would like 1 VM-Series firewall with multiple tunnels and if one tunnel goes down you would like to not lose traffic by routing to the other tunnel. You will need a Policy Based Forwarding Profile to accomplish this. If I am reading your statement correctly this should work.

https://live.paloaltonetworks.com/t5/Configuration-Articles/How-to-Configure-a-Palo-Alto-Networks-Firewall-with-Dual-ISPs/ta-p/59774

@tbone31
Copy link

tbone31 commented Jun 23, 2018

@jpeezus As you know, when you create a VPN connection in AWS it actually creates two tunnels. We have two Palo Alto's with a tunnel to all of our spoke VPCs. So, for one spoke VPC there are 4 total connections, 2 from each firewall.

Currently, we only have 1 of the AWS VPN tunnels configured per Palo Alto connection. That is to say out of the 4 possible connections, we are only using 2, 1 for each PA.

BGP peering is setup correctly and through some packet captures we have been able to determine that once we manually drop the tunnel on Palo Alto A, we can see the route table update. The next hop address changes over to Firewall B's IP address, BUT the traffic is never getting to Firewall B.

There is a NAT policy that is coming into play when passing traffic between palo alto's that I think may be causing issues.

How are you guys getting around NAT/communicating between the palo altos in the different AZs?

@jpeezus
Copy link
Contributor

jpeezus commented Nov 5, 2018

@tbone31 you have probably figured this out by now but we posted a manual build guide for this process. The XML file for the bootstrap config if you are bootstrapping also shows the configuration

https://github.com/PaloAltoNetworks/aws-transit-vpc/blob/master/documentation/Transit_VPC_Manual_Build_Guide.pdf

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants