Dual Site to Site IPsec tunnels (Palo to Palo) with tunnel monitoring

 In this post, I wanted to add a second ipsec tunnel between sites 1 and 2…and use tunnel monitoring to route via the secondary tunnel should the primary go down.

Tunnel-1 (primary) will utilize ISP1 between both sites. Tunnel 2, the secondary, will use ISP2

The basic tunnel build can be found in this post

Site to Site IPsec tunnel (Palo to Palo) via single ISP with Static Routing

And here’s some reference from Palo Alto HERE

Another nice reference is vpn \ tunnel CLI commands that can come in handy 

Ok, so here is the topology – I’ve added ip address to the tunnels as well as shown in the screen shot…as they are necessary for monitoring.

Another thing to note, you want to add your tunnel interfaces to an interface management profile (tunnel-mgmt here), and allow ping, so they can be monitored. Also, both tunnel interfaces on each firewall are added to the tunnel-site x zone – which is part of a security rule allowing traffic to and from the tunnels - see below.

Here’s your IKE gateway config on site 1 firewall

And the ipsec tunnels

Next, you want to create your static routes in the default vr at each firewall, giving tunnel.1, the primary, a better metric so that’s preferred.

Next, you want to create a Monitor Profile – w the failover action - Network-Network Profiles-Monitor

And, the last thing is enable the tunnel monitor itself on the tunnels. I only enabled this on the Site 1 firewall, which should suffice with monitoring the ip address of the tunnel interfaces on the Site 2 end.

I will go ahead and kill the link on ISP 1 for site 1, and we should begin to route over the secondary tunnel.

The routing table on site 1 firewall now shows tunnel.2 as the path to site 2 – that’s great ! BUT, site 2 is still sending traffic via it’s primary tunnel, which is now down since site 1’s ISP 1 peer interface is not reachable, so we will indeed need to monitor on that end as well!

Ok, Now monitoring was added to the site 2 firewall tunnels , and the ISP 1 link at site 1 was taken down again.

You can now see, at site 2, both tunnels go down, and about a minute later, tunnel 2 is up

And you can see on site 2’s vr – tunnel 2 is now forwarding traffic to site 1 !

This is quite a cool little feature and provides resiliency and redundancy capabilities out of the box. There are other ways to accomplish this as well, and I’ll explore those in future posts Thanks for reading !..until next time.

Site to Site IPsec tunnel (Palo to Palo) via single ISP with Static Routing

In this post, I wanted to go over a typical IPsec tunnel between 2 Palo Alto Firewalls, using static routing, and a single ISP.

Referring to our lab topology below, we have our 2 ISPs, configured for redundancy for outbound traffic should one ISP fail. I want to connect the sites via only ISP1 at each site, with an IPsec tunnel

Perform the following on each firewall. Screen shots are from the Site 1 firewall unless otherwise noted

Step 1

Create Layer 3 Zones for your Outside \Untrust Traffic and add the appropriate interfaces if you haven’t already

Network-Zones – here I used “outside” to define my internet facing zone(s)

Step 2

Network-Zones- Create a Layer 3 Zone for the tunnel interfaces\traffic also – tunnel-site2 (tunnel-site1 on Site 2’s firewall) (See above)

Step 3

Define your IKE Crypto and IPSEC Crypto profiles – these values need to match exactly on both firewalls. I’m just using the defaults here, but in production you want to use the strongest supported authentication and encryption algorithms (see Palo recommendations HERE) – no DES,MD5 or SHA1 for certain ! – Choose the highest DH group number in general.

Network-Network Profiles-IPSec Crypto \ IKE Crypto

Step 4

Create a tunnel interface (tunnel.xx) and associate with the security zone you created earlier – also place the interface in the default router (in this example)

No ip address is needed for this method, so you can leave that blank

Network-Interfaces-Tunnel

Step 5

Create your IKE Gateway – Define your local \ peer interfaces \ ip address here. You also will want to define a preshared string value\key to use at both ends.

The peers in this topology are ethernet1/3 interfaces:

Site 1: 1.1.1.10 /29

Site 2: 2.2.2.10 /29

IKE-Gateway name: ike-gtwy-1

You would also want to use IKEv2 in production if supported

Network-Network Profiles- IKE Gateways

Note- this is where you would specify the IKE Crypto Profile you created earlier– again, using default here so there’s nothing specific to choose.

Step 6

Create your IPSec Tunnel- this is where the final “tie-in” happens.

Chose the IKE Gateway you created earlier – and the tunnel interface (tunnel.1 here) -again, the IPSec Crypto Profile is using the default

Network-IPSec Tunnels

Step 7

Create security policy rules to allow the tunnel traffic and IKE setup.

You’ll need to create a rule for the IKE application as it needs to be allowed inbound to the internet facing zone (Outside)- you could, and should, scope this rule further to only allow known peers - here I just allowed any source

And a “in-out” rule for your interzone traffic between the LAN facing zone (Inside) and Tunnel Zone (tunnel-sitexx) as shown below

Policies-Security

Step 8

Create routes to each site – in this network, site 1 is 10.1.x.x – site 2 is 10.2.x.x

Simply create a static route to each destination network on each site firewall in the default router, pointing to the respective tunnel interface we created (tunnel.1).

Network-Virtual Routers

This should do it … now send some traffic across sites– you should see the IKE setup (Phase1) -traffic below in Monitor-Traffic – to port 500

And your tunnel should turn green – and your pings or other traffic should be successful!

I hope this was a useful guide to a basic tunnel config on Palo Alto ! Next post I’ll cover redundant tunnels and failover – thanks for reading !!

Local Preference for outbound Palo Alto traffic – default route filtering – Dual ISPs

 In this post, I wanted to go over a typical dual isp topology with default routes learned via BGP, utilizing a Palo Alto gateway as an edge device.

Referencing the topology below, we have our 2 ISPs. Each ISP will send our firewall a default route via an eBGP peering. ISP1 will be our preferred path out, so we will want to make this route more attractive.

We can do this with Local Preference.

Remember the BGP path selection hierarchy. Weight is a Cisco only criteria (mostly – Palo does support it) but Local Presence is more suitable here.

This first thing I want to do is disable the injected default route I had setup on the Palo, and exported to CS1, as there will be no need for this now. I’ll just got to Default Router -BGP – Redist Rules and disable the rule.

We will configure the ISP 1 and 2 routers to export their default routes to the Palo, then create import policies on the Palo to change the local preference on those routes. The route with the higher preference will be used as the egress route.

ISP1-1 pertinent config lines:

Default-originate injects the default route for that specific neighbor (the Palo)- routes are scoped with a prefix list, which is refenced in a route-map. The route-map is used in the neighbor statement and applied to outbound routes. And, I added in the 5.5.5.5 route and applied a metric of 11 to it, just to illustrate how that is done also.

router bgp 1

bgp log-neighbor-changes

redistribute connected

redistribute static

neighbor 1.1.1.2 remote-as 5

neighbor 1.1.1.2 soft-reconfiguration inbound

neighbor 1.1.1.10 remote-as 65111

neighbor 1.1.1.10 description "ISP1-to-Palo-send default only-5.x route w metric of 11"

neighbor 1.1.1.10 default-originate

neighbor 1.1.1.10 route-map DEFAULT-ONLY out

!

ip prefix-list DEFAULT-ROUTE seq 5 permit 0.0.0.0/0

ip prefix-list DEFAULT-ROUTE seq 7 permit 5.5.5.5/32

ip prefix-list DEFAULT-ROUTE seq 10 deny 0.0.0.0/0 le 32

!

route-map DEFAULT-ONLY permit 5

match ip address prefix-list DEFAULT-ROUTE

set metric 11

ISP1-2 pertinent config lines:

Same config here – just a different specific route

router bgp 11

bgp log-neighbor-changes

redistribute connected

redistribute static

neighbor 11.11.11.2 remote-as 55

neighbor 11.11.11.2 soft-reconfiguration inbound

neighbor 11.11.11.10 remote-as 65111

neighbor 11.11.11.10 description "ISP1-to-Palo-send default only-55.x route w metric of 11"

neighbor 11.11.11.10 default-originate

neighbor 11.11.11.10 route-map DEFAULT-ONLY out

!

ip prefix-list DEFAULT-ROUTE seq 5 permit 0.0.0.0/0

ip prefix-list DEFAULT-ROUTE seq 7 permit 55.55.55.55/32

ip prefix-list DEFAULT-ROUTE seq 10 deny 0.0.0.0/0 le 32

!

route-map DEFAULT-ONLY permit 5

match ip address prefix-list DEFAULT-ROUTE

set metric 11

You can check what routes are being advertised with a specific neighbor with the command below:

Here are the peer groups (neighbor statements per se) on the Palo side: One group for each ISP router -and one for the LAN Core switch.

Next, we create an Import policy on the Palo for each ISP router – each router will have an import rule for their respective default route and specific route (5.x \ 55.x), with a deny at the end. ISP1 will have it’s Local Preference changed to 200 – making this the better goto path.

We also want to have an Export policy for the 0.0.0.0 default route sent to CS1. Since this route is learned from an eBGP speaker (ISP routers to Palo) and then subsequently sent to an iBGP speaker (CS1\Palo), it was retaining the next hop address of 1.1.1.9 \ 11.11.11.9 – the ISP interfaces where the route was originated, and passing that onto CS1. CS1 has no idea how to get to those networks! Here you need to enable Use Self on the LAN-PEERS Peer group. This is similar to the next-hop-self directive in a neighbor statement on Cisco IOS.

Here is the Import policy for default route learned from ISP1-1 – setting the Local Pref to 200

Similarly, we will set the Local Pref for ISP1-2 to 150

Here, on the Local BGP RIB on the Palo- you can see the imported route from ISP1 – with new local pref of 200

And the Local RIB out – only the default route from ISP1 is exported at the Palo to CS1 – now with the correct next hop and 200 for local pref

Palo routing table

And, here’s the default route on CS1’s BGP table -

Now let’s test our design and fail the primary ISP1 link

Our peering is down for ISP-1!

And the Palo has now installed the default route pointing to ISP2

BGP Table

And finally, the Exported routes – RIB Out- to CS1 – w local Pref of 150

As a side note, make sure your destination interfaces are specified in your NAT/PAT rules, or else nothing past the top most rule will evaluated or used ! Since the traffic is matching via the same source and destination zones for both rules.

Hope this basic Palo Alto BGP config walk-through was helpful --- thanks for reading my blog !

Advertise default route to Cisco neighbor via BGP from Palo Alto Firewall

I thought to blog down some basic BGP peering configs between a Palo device and Cisco routers in my lab for reference, starting with default route advertising, and focusing more on the Palo side.

Refer to the network topology below:

CS1 and the Palo are peered via ASN 65111 (iBGP) across the 10.1.1.0/29 subnet

My goal here is to send a default route to the CS-1 switch from the Palo – no static routes – just dealing with Site 1 for now – and a single Virtual router

So in Palo- you can inject a default route into BGP despite not having that route in the routing table as normal – kind of like the “neighbor x.x.x.x default-originate” in Cisco.

https://knowledgebase.paloaltonetworks.com/kcSArticleDetail?id=kA10g000000PNt2

You do that here under BGP – Distribution rules – I set a metric of 10 here

Now, you can scope the route to a particular neighbor (if desired) – I just want the default route to pass to the core switch neighbor (CS1) on the LAN side. For this, you create an export policy, that allows the routes you want (this case- the default) – and specify the peer group. Peer groups are how you configure and group your bgp neighborships – akin to BGP neighbor statements in cisco ie neighbor 1.1.1.1 remote-as 65111

Two peer groups here – one for the Lan side (CS-1) and one for the ISP\WAN routers. I did have to create deny rules for the WAN peers- if not- they would get the default route as well- which I don’t want

You can check your outbound routes in BGP – RIB Out – here you see the 0.0.0.0/0 route advertised to CS1 – with a MED of 10 – set in the redistribution rule above

Route received at the CS1 router from the Palo

I hope to have a lot more Palo based labs planned for the future ---thanks for reading!