IPsec Site-to-Site VPN Palo Alto <-> Cisco Router w/ VTI

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.

This is one of many VPN tutorials on my blog. –> Have a look at this full list. <–

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

S2S VPN Palo Alto - Cisco Router w VTI Laboratory

Palo Alto

These are the configuration steps on the Palo Alto firewall:

  1. IKE and IPSec Crypto profiles, e.g., aes256, sha1, pfs group 14 (!), lifetime 8h/1h.
  2. IKE Gateway with the pre-shared key and the corresponding IKE Crypto Profile. The “Identification” fields are not needed.
  3. Tunnel Interface with an IPv4 address within a virtual router (e.g., “default”) and a security zone (e.g., “vpn-s2s”).
  4. 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!
  5. 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.
  6. Policy from untrust to untrust with the applications “ike”, “ipsec”, and “ciscovpn” allowed.
  7. 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:

  1. crypto isakmp policy appropriate to the “IKE Crypto” on the PA
  2. crypto isakmp key with the pre-shared key
  3. crypto ipsec transform-set appropriate to the “IPSec Crypto” on the PA
  4. crypto ipsec profile that points to the transform-set and has pfs group14 set
  5. 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
  6. Finally, a static ip route through the tunnel interface to the tunnel IPv4 address of the Palo Alto side
  7. (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:

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:

Routing IOS2-PA without and with route through 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:

 

Done :)

Links

12 thoughts on “IPsec Site-to-Site VPN Palo Alto <-> Cisco Router w/ VTI

  1. In the crypto ipsec transform-set context, there should be the line:
    mode transport

    Otherwise the tunnel is erratic and unstable.

    1. 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. ;)

      1. 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.

  2. 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.

    1. 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”.

  3. Can you create a page or extension to this that goes over ikev2 tunnel from a Cisco router to a Palo Alto FW?

  4. 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!

  5. Will Proxy ID on Palo needs to be configured since then s is a route based vpn ?

Leave a Reply

Your email address will not be published. Required fields are marked *