One more VPN article. Even one more between a Palo Alto firewall and a Cisco router. But this time I am using a virtual tunnel interface (VTI) on the Cisco router which makes the whole VPN set a “route-based VPN”. That is: Both devices decide their traffic flow merely based on the routing table and not on access-list entries. In my opinion, this is the best way to build VPNs, because there is a single instance (the routing table) on which a network admin must rely on in order to investigate the traffic flow.
Note that I also wrote a blog post about the “policy-based VPN” between a Cisco router and the Palo Alto firewall. This here is mostly the same on the Palo Alto side while some other commands are issued on the Cisco router.
My lab units are a Palo Alto PA-200 with PAN-OS 6.0.3 and a Cisco router 2811 with IOS 12.4(24)T8 (c2800nm-advipservicesk9-mz.124-24.T8.bin).
Laboratory
Palo Alto
These are the configuration steps on the Palo Alto firewall:
- IKE and IPSec Crypto profiles, e.g., aes256, sha1, pfs group 14 (!), lifetime 8h/1h.
- IKE Gateway with the pre-shared key and the corresponding IKE Crypto Profile. The “Identification” fields are not needed.
- Tunnel Interface with an IPv4 address within a virtual router (e.g., “default”) and a security zone (e.g., “vpn-s2s”).
- IPSec Tunnel: Tying all together: tunnel interface, IKE gateway, IPSec crypto profile. The Tunnel Monitor can be used to ping the other side of the tunnel. And since this is a route-based VPN, the Proxy IDs are not needed here!
- Static route to the destination network through the tunnel interface with a next-hop address of the tunnel interface IP address of the other side.
- Policy from untrust to untrust with the applications “ike”, “ipsec”, and “ciscovpn” allowed.
- Policies from trust zones to the zone in which the tunnel interface resides, and vice versa.
Here are my test lab screenshots:
Cisco Router
The Cisco router, configured through the CLI, needs the following lines:
- crypto isakmp policy appropriate to the “IKE Crypto” on the PA
- crypto isakmp key with the pre-shared key
- crypto ipsec transform-set appropriate to the “IPSec Crypto” on the PA
- crypto ipsec profile that points to the transform-set and has pfs group14 set
- interface Tunnel with an IPv4 address, tunnel source and destination addresses (outside addresses of the router and the Palo Alto), tunnel mode of ipsec and a reference to the crypto profile
- Finally, a static ip route through the tunnel interface to the tunnel IPv4 address of the Palo Alto side
- (Note, there is no “crypto map” used here, the real outside interface is not touched, and no access-list is configured!)
Here is the bunch of my configuration commands:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
crypto isakmp policy 10 encr aes 256 authentication pre-share group 14 lifetime 28800 ! crypto isakmp key 5Tc56Q5A4HcLB72AUQqhzAFcXY0Lm8 address 172.16.1.2 ! crypto ipsec transform-set aes256-sha esp-aes 256 esp-sha-hmac ! crypto ipsec profile PA set transform-set aes256-sha set pfs group14 ! interface Tunnel121 ip address 10.0.0.6 255.255.255.252 tunnel source 172.16.1.5 tunnel destination 172.16.1.2 tunnel mode ipsec ipv4 tunnel protection ipsec profile PA ! ip route 192.168.121.0 255.255.255.0 Tunnel121 10.0.0.5 |
Don’t forget the Route
During the first test in my lab, the VPN was up but the traffic flew through the network even without the route through the tunnel! This was because the normal routing could reach the network from the Cisco router to the Palo Alto directly. So, one more time: Check the routing through the correct VPN tunnel! (This becomes even more serious when IPv6 with global unicast addresses will be used, in which situation every address could reach every other address on the Internet even without VPNs.)
The following screenshot shows two traceroute commands on a Linux test machine. During the first command, the route entry on the Cisco router was not added (though the VPN tunnel was already established), while the second traceroute went over the correct VPN tunnel:
Monitoring
Green bubbles in the Palo Alto tunnel pane and system log entries corresponding to the IKE gateway and IPsec tunnel objects. (Note the hourly refresh of the key due to the IPsec lifetime of 3600 sec):
Show commands on the Cisco router:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 |
fd-wv-ro03#show crypto isakmp sa detail Codes: C - IKE configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal T - cTCP encapsulation, X - IKE Extended Authentication psk - Preshared key, rsig - RSA signature renc - RSA encryption IPv4 Crypto ISAKMP SA C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap. 1135 172.16.1.5 172.16.1.2 ACTIVE aes sha psk 14 05:25:04 Engine-id:Conn-id = SW:135 IPv6 Crypto ISAKMP SA --------------------------------------- fd-wv-ro03#show crypto ipsec sa interface: Tunnel121 Crypto map tag: Tunnel121-head-0, local addr 172.16.1.5 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0) current_peer 172.16.1.2 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 679743, #pkts encrypt: 679743, #pkts digest: 679743 #pkts decaps: 680929, #pkts decrypt: 680929, #pkts verify: 680929 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 66, #recv errors 0 local crypto endpt.: 172.16.1.5, remote crypto endpt.: 172.16.1.2 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0 current outbound spi: 0xFF5F2879(4284426361) PFS (Y/N): Y, DH group: group14 inbound esp sas: spi: 0xFA8A1BF5(4203355125) transform: esp-256-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 4161, flow_id: NETGX:2161, sibling_flags 80000046, crypto map: Tunnel121-head-0 sa timing: remaining key lifetime (k/sec): (4436876/1194) IV size: 16 bytes replay detection support: Y Status: ACTIVE inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xFF5F2879(4284426361) transform: esp-256-aes esp-sha-hmac , in use settings ={Tunnel, } conn id: 4162, flow_id: NETGX:2162, sibling_flags 80000046, crypto map: Tunnel121-head-0 sa timing: remaining key lifetime (k/sec): (4436876/1194) IV size: 16 bytes replay detection support: Y Status: ACTIVE outbound ah sas: outbound pcp sas: --------------------------------------- fd-wv-ro03#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is 172.16.1.1 to network 0.0.0.0 S 192.168.121.0/24 [1/0] via 10.0.0.5, Tunnel121 C 192.168.151.0/24 is directly connected, FastEthernet0/1.151 S 192.168.120.0/24 [1/0] via 172.16.1.2 C 192.168.150.0/24 is directly connected, FastEthernet0/1.150 S 192.168.111.0/24 [1/0] via 10.0.0.9, Tunnel111 S 192.168.125.0/24 [1/0] via 172.16.1.2 172.16.0.0/24 is subnetted, 1 subnets C 172.16.1.0 is directly connected, FastEthernet0/0 10.0.0.0/30 is subnetted, 2 subnets C 10.0.0.8 is directly connected, Tunnel111 C 10.0.0.4 is directly connected, Tunnel121 S* 0.0.0.0/0 [1/0] via 172.16.1.1 |
Done :)
In the crypto ipsec transform-set context, there should be the line:
mode transport
Otherwise the tunnel is erratic and unstable.
Is there a way to do this if the cisco device is behind NAT?
Hi Tormod,
I have not tested this explicitly, but I think it should work, especially if it is a static 1:1 NAT to the private IP address of the router. Then you should adjust the “tunnel source” value to the external IP address.
If the router is behind a dynamic NAT/PAT, then I am not quite sure. Maybe the configuration without VTIs can work better because you don’t have to specifiy the “tunnel source”. Refer to my other tutorial which is linked in the second paragraph. Furthermore, the “Peer IP Type” on the Palo must be set to “Dynamic”.
Try and error is key. ;)
Thanks alot for the quick answer!
Yeah, the cisco it behind a dynamic NAT/PAT, not 1:1 :(
I have to try the other way, that might be the key. But i still hope the other way works first. Its a bit more the way im used to ;)
Ill post the results.
So if you had multiple Cisco routers connecting to the Palo would you need multiple tunnel interfaces and assign each tunnel interface to each IPSEC tunnel? Assuming all networks can talk to each other.
Yes, exactly. For each IPsec tunnel you need a unique tunnel interface. This is due to the routing table entries which must be configured in order to route traffic x to tunnel x, traffic y to tunnel y, etc.
Of course, the routing entries on the Cisco routers must be correct, too, in order to “assuming all networks can talk to each other”.
Can you create a page or extension to this that goes over ikev2 tunnel from a Cisco router to a Palo Alto FW?
Good point. I have added it to the list of ideas for new blog posts. (That is: Don’t wait for it…)
Did you test IKEv2 between PA and Cisco IOS router? looks like lots of trick. I cannot find anything from website about that scenario. Thanks for help!
Sorry, I haven’t tested IKEv2 with a Cisco IOS router so far.
Will Proxy ID on Palo needs to be configured since then s is a route based vpn ?
Citing a sentence from above: “And since this is a route-based VPN, the Proxy IDs are not needed here!”