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!

Originating a default route via BGP from Cisco router - Advertise to Palo

My goal here is to have IPS1 peer with the Palo, send it only a default route (or any other more specific route specified)…with a preconfigured metric

Here’s some background on generating default routes: https://community.cisco.com/t5/routing/difference-between-default-originate-and-network-0-0-0-0-in-bgp/td-p/1780201

Referring to the topology below: ISP-1 is peered with the Palo via eBGP – ASN 1 \ ASN 65111

Firstly … on the ISP-1 router, you inject the default into BGP… you can do it like this… at the neighbor statement – note that this route is NOT in the routing table previously, but “artificially” injected

neighbor 1.1.1.10 default-originate

Next create a prefix list to identify the routes you want to send to the neighbor, and block the rest – here, I’m permitting the 0.0.0.0 default roue, and the 5.5.5.5, then denying all subnets with a mask LESS than (le) 32…which is everything

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

Next, create a route map and reference the prefix-list you just created I also wanted to set the metric here – presumably for both allowed routes, to 11

route-map DEFAULT-ONLY permit 5

match ip address prefix-list DEFAULT-ROUTE

set metric 11

Now, you reference the route-map in a neighbor statement that will filter the outbound routes to this particular neighbor, in this case, the Palo.

neighbor 1.1.1.10 route-map DEFAULT-ONLY out

You can use this command to force the updates outbound to the neighbor (Palo) without tearing down the established peering.

clear ip bgp 1.1.1.10 soft out

You can see above on the Palo-routes from the ISP-1 router, that the 5.5.5.5 route WILL have it's metric set- the default route included in the same prefix list will not- seems because it's a default-originate route and NOT really in the routing table, so it behaves differently. (??)

From the perspective of the ISP-1 router (the sending router)

show ip bgp neighbors 1.1.1.10 advertised-routes

Next time, I’ll dive into how we can further manipulate this default route, making it more or less preferred for traffic headed out of our AS towards the internet.

Influencing EIGRP Path Selection

 

Being an enhanced distance vector IGP, there are several ways to influence the route and path selection of EIGRP

Administrative Distance:

Consider the topology below. We would like to prefer the link between R7 and R1 when sending traffic to the 4.4.4.4 network (R4's loopback)

Currently we have 2 equal cost routes to 4.4.4.4 as shown in the ip routing table

Also, in the EIGRP topology table, we see the 2 successor routes of equal cost

Here, we are going to use the distance command to change the AD of the route for 4.4.4.4 on R7, preferring the path towards R1s neighbor interface.

First thing is define the route in an access list 

R7(config)#access-list 1 permit host 4.4.4.4 

Next we jump into router config mode and issue the distance command, with the source interface being R1's neighbor interface (10.1.17.1) and access-list 1 on the end to define the route - 4.4.4.4

R7(config)#router eigrp 7
R7(config-router)#distance 88 10.1.17.1 0.0.0.0 1

Now we can see that the AD is 88, lower then the default of 90, so R7 will prefer this this path on the way to 4.4.4.4 only.

The EIGRP topology table remains the same as above...as we haven't changed the link metrics in any way. We'll explore that next !

Interface Bandwidth and Delay values:

If we take a look at the current values of interface gig 0/0 on R7 (the link that we want to prefer here), we see the following (truncated)

R7#show interfaces gigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up 

  Hardware is iGbE, address is 5254.0014.1def (bia 5254.0014.1def)

  Internet address is 10.1.17.7/24

  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec, 

     reliability 255/255, txload 1/255, rxload 1/255

To favor this link, we can increase the bandwidth or decrease the delay, which will cause EIGRP to recalculate it's route. We can also do the inverse on a link we do NOT want to favor to make the EIGRP metric WORSE - increase the delay and decrease the bandwidth. And in this case, I need to do just that since the delay and bandwidth metrics on these links are already at their optimum value as shown above, and can't be made better.

Here I decrease the bandwidth to 50000 Kbps (or 500 Mbps) and increase the delay to 20 (in 10 of miroseconds) which would be 200 usec.

interface GigabitEthernet0/1

 bandwidth 500000

 delay 20

Now we get this

GigabitEthernet0/1 is up, line protocol is up 

  Hardware is iGbE, address is 5254.000f.ef31 (bia 5254.000f.ef31)

  Internet address is 10.1.27.7/24

  MTU 1500 bytes, BW 500000 Kbit/sec, DLY 200 usec, 

     reliability 255/255, txload 1/255, rxload 1/255

show ip route - Link between R7 and R1 is now preferred.

show ip eigrp topology - metric is worse on Gig0/1 link as show shown in the topology table

Of course this affects all routes egressing from R7 towards R1, R2 and beyond.

EIGRP Offset List:

Another way to influence EIGRP routes is via an offset list. You can only make a metric WORSE with an offset list, not BETTER...so you'll need to set the offset on the link you do NOT want to favor.

Here we add the offset list to the incoming interface on R7 - (R2-R7 Link) 

offset-list <access list defining route you want to alter><in\out><off set list value><interface>

R7(config-router)#offset-list 1 in 2 gigabitEthernet 0/1

You can see below - route table favors the R1-R7 link, and only for the 4.4.4.4 route defined by access-list 1....which is nice.

And the EIGRP topology table shows the incremented metric value on the R2-R7 link - 2 above, just enough to make it fall back to a feasible successor.

If you run a show ip protocol on R7 - it will tell you that an offset list has been applied and state the additional metric.

show ip protocol

Routing Protocol is "eigrp 7"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Incoming routes in GigabitEthernet0/1 will have 2 added to metric if on list 1
Default networks flagged in outgoing updates
Default networks accepted from incoming updates

There you have it...hope this was helpful!

MPLS3 with GETVPN

Hello all…wanted to share my version of a MPLS lab with you....as if there's not enough MPLS material online! Well, here's one more! The base of the lab was configured with the guidance of Keith Barker, who put up an excellent you tube video on MPLS-check it out here!

https://www.youtube.com/watch?v=pia2WceaevQ&list=PLC3E6D83668FB81C7&index=2

I just kind of elaborated on it a bit-added a second customer, a third customer CE, and some GETVPN to get some traffic encryption going. Here’s the config for PE-R2…… at the end of all this, I’ll make my GNS3 lab available for those who want to download it.

version 15.2 service timestamps debug datetime msec service timestamps log datetime msec ! hostname PE-R2 ! boot-start-marker boot-end-marker ! ! vrf definition dtech  rd 120:120  !  address-family ipv4   route-target export 20:20   route-target import 30:30   route-target import 40:40   route-target import 137:137  exit-address-family ! vrf definition isp  rd 137:137  !  address-family ipv4   import map DTECH_SELECT   route-target export 137:137   route-target import 21:21   route-target import 31:31   route-target import 20:20   route-target import 30:30   route-target import 40:40  exit-address-family ! vrf definition pizza  rd 121:121  !  address-family ipv4   route-target export 21:21   route-target import 31:31   route-target import 137:137  exit-address-family ! no aaa new-model no ip domain lookup ip domain name lab.local ip cef no ipv6 cef ! ! multilink bundle-name authenticated ! interface Loopback0  ip address 2.2.2.2 255.255.255.255 ! interface FastEthernet0/0  ip address 10.0.23.2 255.255.255.0  speed auto  duplex auto  mpls ip ! interface FastEthernet0/1  ip address 10.0.24.2 255.255.255.0  speed auto  duplex auto  mpls ip ! interface FastEthernet1/0  vrf forwarding dtech  ip address 172.16.12.2 255.255.255.0  speed auto  duplex auto ! interface FastEthernet1/1  vrf forwarding pizza  ip address 172.16.29.2 255.255.255.0  speed auto  duplex auto ! router ospf 2 vrf pizza  router-id 0.0.29.29  redistribute bgp 27 subnets  network 172.16.29.0 0.0.0.255 area 0  default-information originate ! router ospf 1  network 2.2.2.2 0.0.0.0 area 0  network 10.0.0.0 0.0.255.255 area 0 ! router rip  !  address-family ipv4 vrf dtech   redistribute bgp 27 metric 2   network 172.16.0.0   no auto-summary   version 2  exit-address-family ! router bgp 27  bgp log-neighbor-changes  neighbor 7.7.7.7 remote-as 27  neighbor 7.7.7.7 update-source Loopback0  neighbor 11.11.11.11 remote-as 27  neighbor 11.11.11.11 update-source Loopback0  !  address-family vpnv4   neighbor 7.7.7.7 activate   neighbor 7.7.7.7 send-community extended   neighbor 11.11.11.11 activate   neighbor 11.11.11.11 send-community extended  exit-address-family  !  address-family ipv4 vrf dtech   redistribute rip  exit-address-family  !  address-family ipv4 vrf pizza   redistribute ospf 2  exit-address-family ! ip forward-protocol nd ! ! no ip http server no ip http secure-server ! ! ip prefix-list DTECH_LOOPS seq 5 permit 1.1.1.1/32 ip prefix-list DTECH_LOOPS seq 10 permit 8.8.8.8/32 ip prefix-list DTECH_LOOPS seq 15 permit 12.12.12.12/32 ! route-map DTECH_SELECT deny 10  match ip address prefix-list DTECH_LOOPS ! route-map DTECH_SELECT permit 20

Define your customer VRF and assign a unique Route Distinguisher value in order to keep possible overlapping customer routes unique when traversing MP-BGP. Define which routes in the customer’s VRF you want to share with other VRFs route-targets. Most times you can just assign the same value for import and export, since you would normally want to share all routes among the same customer vrf, but I just wanted to make them unique for each vrf instance. One for each PE. For the ISP vrf, I used a route map import so that only select routes were imported in, and others denied. Using the route-target values is all or nothing. Import and export maps will give you more control. In this case, the ISP vrf is importing all other vrf routes, with the exception of dtech, and are modified via the import map command. See at the bottom of the config… Enable mpls for the interfaces connecting your core routers This would be your customer facing interface- you’ll want to place this interface in the vrf for your customer. This interface will also exchange routes with the CE’s local routing protocol. This customer (pizza) uses OSPF as their IGP at the CE. This OSPF instance is placed in the customer vrf and MP-BGP is redistributed into it- which is carrying the injected routes through the MPLS core from the other customer VRFs\PE interface. Note the use of “default-information originate” here. This is necessary to distribute a default route to the CE via OSPF. The route is originated on PE-R7 in the isp vrf, and distributed via MP-BGP like the rest of the routes. OSPF 1 servers as the core IGP for the MPLS backbone This customer (dtech) uses RIPv2 as their IGP at the CE. This rip instance is placed in the customer vrf and MP-BGP is redistributed into it- which is carrying the injected routes through the MPLS core from the other customer VRFs\PE interfaces Here we are defining the BGP pairings for our PE routers that define the MPLS backbone. I did a full mesh between the 3. Also using the loopback0 as the update source instead of the physical interface for redundancy. It’s here, in the vpnv4 address family, where you are activating the PE BGP neighbors to send vpnv4 customer prefixes which are made globally unique by use of the Route Distinguisher defined earlier. Also, it is the enabling of the extended send-communities in MP-BGP that carry the RD and RT information needed for MPLS vpns to work. Next, we redistribute the CE’s local IGP into BGP within the respective customer vrfs Here’s the prefix used in the above import map. I didn't want the isp vrf to show the dtech loopback networks (lets pretend these were top secret networks). So the loopbacks are defined in the prefix list here, then denied in the DTECH_SELECT route map, effectively preventing them from importation on the to the isp network. Notice the unmatched permit statement at the end of the route map…basically saying “leave everything else as is”

Now, take a look at PE-R7…I’ll go over the differences from PE-R2- it’s all configured the same except for these exceptions.

When your CE’s are using EIGRP as there local routing IGP, you can just create a single EIGRP AS instance on the PE (AS 7 in this case)- then, under your address-family commands, reference the CE’s local EIGRP AS number…. (8, 10, 13 respectively)- then you’ll redistribute BGP into those AS’s so that your customers get the routes.

router eigrp 7

 !

 address-family ipv4 vrf dtech

  redistribute bgp 27 metric 1 1 1 1 1

  network 0.0.0.0

  autonomous-system 8

 exit-address-family

 !

 address-family ipv4 vrf pizza

  redistribute bgp 27 metric 1 1 1 1 1

  network 0.0.0.0

  autonomous-system 10

 exit-address-family

 !

 address-family ipv4 vrf isp

  redistribute bgp 27 metric 1 1 1 1 1

  network 0.0.0.0

  autonomous-system 13

 exit-address-family

Now, there’s a default static route on PE-R7 pointing to the ISP router. I have this route shared among all the vrfs, so that any traffic wo specific routes heads out towards the internet. I distributed this route via the MPLS network to the CEs.

ip route vrf isp 0.0.0.0 0.0.0.0 137.137.137.13

router bgp 27

address-family ipv4 vrf isp

  redistribute static

  default-information originate

 exit-address-family

You’ll want to redistribute static routes into BGP for the isp vrf as shown above- you’ll also need default-information originate so that’s it’s distributed via MP-BGP and shows up in the ipv4 tables for all the vrfs on all the Pes. I’m also peering with the ISP routers local EIGRP as show above on this PE-R7…..other than that, it’s the same as PE-2

The CE routers are just straight peering with their respective IGPs (no redistribution done at the CEs)- advertise the networks you want (I advertised all the CE loopbacks- ie R1 loopback is 1.1.1.1/32) and you should be good to go. You should see the routes for your respective customer offices on the CE (show ip route).

 To check the that you have the correct BGP routes on your PE routers, use show ip bgp all - you'll get a table for each vrf under the VPNv4 address family. (see below) Note the default route in each vrf

Now, you have a functioning MPLS network serving 2 customers! Pretty cool! But….dtech is worried about the security of their traffic between office locations. Pizza doesn’t care- they’re busy making pizzas! So, I’ll implement GETVPN over MPLS to encrypt the interoffice traffic for DTech in the next section. And I'll upload the lab files as well.......  until then....thanks for reading.

Update: 3-2015.............................................................................................................................

Actually....I went through the GETVPN config on another lab.....combining it with DMVPN....so if interested, you can head there and take a look.    http://techjuice.blogspot.com/2015/03/dmvpn-w-getvpn-for-encryption.html

Update: 1-2024...............................................................................................................................

Added new Cisco Modeling Labs version of the lab (Less the GET-VPN part)  Download Lab