Ipsec tunnel cisco router. Cisco SD-WAN IPsec Tunnel Configuration

Cisco SD-WAN IPsec Tunnel Configuration

This blog post describes configuring a site-to-site IPsec VPN tunnel from a Cisco SD-WAN iOS-XE-based router to a non-SD-WAN device.

How to enable configure Cisco SD-WAN IPsec Tunnels to a non-SD-WAN device? In Cisco SD-WAN template-based deployment, IPsec tunnels are configured via the Cisco VPN Interface IPsec feature template. This template is then applied to the Transport VPN (0) or one of the Service VPNs.

Cisco SD-WAN IPSec Tunnels Step-by-step

The logical elements required to be configured shown in Figure 1. All pre-configured elements have check mark symbols next to them.

In our example, the edge device has a device template attached with basic configuration applied, such as system and transport interfaces, sufficient for the router to have control connections to the controllers.

The device template uses a service VPN, which is described by the Cisco VPN feature template. This type of template, despite its name, is not related to IPsec VPN settings. Cisco VPN feature template defines VRF settings and is a container for routing and participating interface information. In our example, the user-facing interface is assumed to be configured and associated with the VRF.

While it is possible to configure all child templates from within the device template, in our example, we will pre-configure child feature templates first and then select them in the device template.

Create and Configure Cisco VPN Interface IPsec Feature Template

The first two steps deal with configuration of IPsec feature template.

Step 1. Create feature template

• Select Configuration section of the side menu
• Click on Templates
• Click on the Feature tab
• Click on Add Template button
• Select model of devices that this feature template will be applied
• Select Cisco VPN Interface IPsec

Step 2. Configure feature template

Customize IPSec tunnel parameters. There are 5 sections in IPsec template:

• Basic configuration, such as name and IP address of the tunnel interface and its underlying source (local router) and destination (remote router)
• Dead-peer detection settings
• IKE or Phase 1 parameters
• IPSEC or Phase 2 parameters
• Advanced Settings

SD-WAN requires an IP-numbered interface (/30) and supports route-based tunnels known as VTI (Virtual Template Interface) in Cisco iOS documentation.

Instead of specifying interesting traffic using ACL known as policy-based tunnels, route-based tunnels use static or dynamic routing over a tunnel interface.

As figure 4 shows, there are various options available for both IKE and IPSEC security parameters. These need to match between tunnel endpoints.

Adjust device template to use IPsec Feature Template

Step 3. Add feature template to the device template.

IPsec interface template can now be attached to the service VPNs. Figure 6 shows how to modify the existing device template.

Routing Configuration

Step 4. Set-up routing over the tunnel. This can be static or dynamic-routing protocol-based. In the screenshot below, the static route configuration is shown.

Step 5. Test the tunnel.

As the tunnels are VTI-based and have Layer 3 addresses on both sides, the simplest test is to ping the remote side of the tunnel.

There is limited information available via real-time monitoring using vManage web interface. Native SD-WAN tunnels are also IPSec-based. These tunnels have centralized authentication and key management done by OMP instead of IKE/ISAKMP protocols used in non-SD-WAN tunnels. Real-time device options that contain string IKE in their name will be relevant to us in the context of this article.

Using SSH connection to the router these 2 commands can be used to check operational details of the tunnel:

We will demonstrate output of these commands in the practical example below.

Cisco SD-WAN IPSec Tunnels Example

Now it’s time for a practical example. We will establish an IPsec tunnel to a Cisco iOS-XE router configured to match VPN gateways settings in public clouds. For example, AWS provides sample configuration files for different platforms (see this URL). We will apply configuration from the Cisco iOS sample, and we can assume that if our router can work with it, it will work with a real AWS gateway. The configuration is slightly adjusted to use IKEv2 by replacing all isakmp commands with IKEv2-variants.

External router configuration

Non SD-WAN router shown on the top in figure 10 has the following configuration:

interface GigabitEthernet2 IP address 5.5.5.10 255.255.255.0 IP route 0.0.0.0 0.0.0.0 5.5.5.1 crypto ikev2 keyring KEYRING-1 peer 21.1.1.2 address 21.1.1.2 pre-shared-key cisco crypto ikev2 proposal IKE-PROPOSAL-1 encryption aes-cbc-256 integrity sha1 group 16 crypto ikev2 policy IKE-POLICY-1 match address local 5.5.5.10 proposal IKE-PROPOSAL-1 crypto ikev2 profile IKE-PROFILE-1 match address local interface GigabitEthernet2 match identity remote address 21.1.1.2 255.255.255.255 authentication remote pre-share authentication local pre-share keyring local KEYRING-1 crypto ipsec transform-set TRANSFORM-SET esp-256-aes esp-sha-hmac mode tunnel crypto ipsec profile IPSEC-PROFILE-1 set security-association lifetime kilobytes 102400000 set transform-set TRANSFORM-SET set ikev2-profile IKE-PROFILE-1 interface Tunnel0 IP address 169.254.23.2 255.255.255.252 IP tcp adjust-mss 1400 tunnel source GigabitEthernet2 tunnel mode ipsec ipv4 tunnel destination 21.1.1.2 tunnel protection ipsec profile IPSEC-PROFILE-1 IP route 192.168.22.0 255.255.255.0 Tunnel0

SD-WAN configuration

We followed the same steps described in the first part of the article to configure vManage. To make it easier to follow, the majority of parameters are hardcoded into the template. In a real deployment, per-device variables can be used to allow for template re-use.

Then the feature template was added to the device template under VPN 1 section (see Figure 6 above) and route to 192.168.15.0/24 was added to VPN 1 feature template (see Figure 8).

Testing and Validation

Let’s assume that we have access only to the SD-WAN router, and testing will be done only from one side of the connection. We will use the router’s command-line interface via SSH from the vManage web console, as it gives access to information not available via the web interface.

The first test that we perform is checking if the remote side of the tunnel is reachable. The “vrf 1” parameter makes sure that the router uses the correct interface.

CSR01#ping vrf 1 169.254.23.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 169.254.23.2, timeout is 2 seconds:. Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms CSR01#

If ping responses are not received, we can run “show crypto ikev2 sa” and “show crypto ipsec sa” commands. The first command displays if the IKEv2 security association is established, which is a prerequisite for IPSEC security associations. The troubleshooting should start here. If IKEv1 is used, the command is “show crypto isakmp sa.”

CSR01#show crypto ikev2 sa IPv4 Crypto IKEv2 SA Tunnel-ID Local Remote fvrf/ivrf Status 1 21.1.1.2/500 5.5.5.10/500 none/1 READY Encr: AES-CBC, keysize: 256, PRF: SHA1, Hash: SHA96, DH Grp:16, Auth sign: PSK, Auth verify: PSK Life/Active Time: 86400/545 sec IPv6 Crypto IKEv2 SA

We were running ping of the tunnel interface in our example, which is directly connected to both routers. This test might be successful; however, the connectivity between devices behind the tunnel gateways may still not work.

In this case, we can use the “show crypto ipsec sa” command. It displays a set of counters for the number of encrypted and decrypted packets.

If the encrypted packets count is not increasing, that usually suggests a local routing problem when traffic is not being sent out of the tunnel interface.

If the encrypted packets count does increase but decrypted doesn’t, it can mean that the remote router has routing misconfiguration.

CSR01#show crypto ipsec sa interface: Tunnel100001 Crypto map tag: Tunnel100001-head-0, local addr 21.1.1.2 protected vrf: 1 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 5.5.5.10 port 500 PERMIT, flags= #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5 #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0

There are some useful debug commands available, such as “debug crypto ikev2”. It can generate extensive output on a router with multiple tunnels, so be careful not to overload the production router. In the example below, we’ve changed the key on the other side of the tunnel to break the tunnel. Auth exchange failed message is logged, suggesting that we have mismatched keys and “show crypto ikev2” will not display any tunnels.

CSR01#debug crypto ikev2 Payload contents: VID IDi AUTH SA TSi TSr NOTIFY(INITIAL_CONTACT) NOTIFY(SET_WINDOW_SIZE) NOTIFY(ESP_TFC_NO_SUPPORT) NOTIFY(NON_FIRST_FRAGS) Jul 10 00:46:36.630: IKEv2:(SESSION Packet [To 5.5.5.10:500/From 21.1.1.2:500/VRF i0:f0] Initiator SPI : EE7E2D729412F370. Responder SPI : B37D8CA8BAB8C150 Message ID: 1 IKEv2 IKE_AUTH Exchange REQUEST Payload contents: ENCR Jul 10 00:46:36.633: IKEv2:(SESSION Packet [From 5.5.5.10:500/To 21.1.1.2:500/VRF i0:f0] Initiator SPI : EE7E2D729412F370. Responder SPI : B37D8CA8BAB8C150 Message ID: 1 IKEv2 IKE_AUTH Exchange RESPONSE Payload contents: NOTIFY(AUTHENTICATION_FAILED) Jul 10 00:46:36.633: IKEv2:(SESSION auth response notify Jul 10 00:46:36.633: IKEv2-ERROR:(SESSION Jul 10 00:46:36.633: IKEv2:(SESSION exchange failed Jul 10 00:46:36.633: IKEv2-ERROR:(SESSION Auth exchange failed Jul 10 00:46:36.633: IKEv2:(SESSION exchange Jul 10 00:46:36.633: IKEv2:(SESSION SA CSR01# show crypto ikev2 sa CSR01#

And finally we can perform end to end test from the test machines using ping and tracert commands.

IPSec tunnel between Cisco iOS router and AWS VPC. Static VTI and crypto map with HSRP redundancy.

Home BlogIP NetworksEnterprise Networks IPSec tunnel between Cisco iOS router and AWS VPC. Static VTI and crypto map with HSRP redundancy.

IPSec tunnel between Cisco iOS router and AWS VPC. Static VTI and crypto map with HSRP redundancy.

AWS VPC and data center resources connectivity. Concern.

Lately I was asked about the possibility of building the IPsec tunnel between Amazon VPC and Cisco iOS routers that were located at customer premises (DC). There is quite nice automation tool at Amazon that prepares almost accurate tunnel config for Cisco iOS taking addressing parameters as an input. Anyway the task would not be sophisticated if the main concern would not be related to satisfying different crypto technologies and HSRP simultaneously: static VTI generated by AWS, legacy crypto map that terminates several other S2S tunnels and IPSec HSRP redundancy on the same router. I met few unresolved threads around the networking community that consider SVTI and HSRP IPSec redundancy as unsupported configuration on iOS. However i took the gauntlet and put the config on my lab.

Small piece of tunnel configuration output from AWS automation tool.

AWS tunnel side

I need to simulate an AWS side. There were no issue with this as the AWS VPC side used purely static VTI interface for connectivity, so I just put the right config that reflected VTI VPN headend (on premise). Here are the most important parts:

Generating crypto keyring to point the peer to proper PSK:

crypto keyring keyring1 local-address 10.253.51.103 pre-shared-key address 10.253.51.203 key KeY221# !- don’t use easy keys 🙂

Defining crypto policy for phase 1 (ISAKMP):

crypto isakmp policy 200 encr aes 256 authentication pre-share group 2 lifetime 28800

Making isakmp profile to use with the peer:

crypto isakmp profile isakmp1 keyring keyring1 match identity address 10.253.51.203 255.255.255.255 local-address 10.253.51.103

Time to define security algorithms for phase 2 IPSec:

crypto ipsec security-association replay window-size 128 crypto ipsec transform-set AES esp-aes esp-sha-hmac mode transport ! crypto ipsec transform-set set1 esp-aes 256 esp-sha-hmac crypto ipsec df-bit clear

Bundling transform set perfect forwarding secrecy in one profile:

crypto ipsec profile isakmp1 set transform-set set1 set pfs group2

interface Tunnel1 IP address 10.0.0.2 255.255.255.252 IP virtual-reassembly IP tcp adjust-mss 1379 tunnel source 10.253.51.103 tunnel destination 10.253.51.203 tunnel mode ipsec ipv4 tunnel protection ipsec profile isakmp1 end

Customer tunnel side

Now is the most important part. Two routers with HSRP IPSec redundancy and legacy crypto map and new SVTI for traffic directed to Amazon VPC.

Router 1 (priority for HSRP)

crypto keyring keyring1 local-address 10.253.51.203 pre-shared-key address 10.253.51.103 key KeY221# crypto isakmp policy 200 encr aes 256 authentication pre-share group 2 lifetime 28800 ! crypto isakmp key KeY221# address 10.253.51.204 crypto isakmp keepalive 10 10 ! crypto isakmp profile isakmp1 keyring keyring1 match identity address 10.253.51.103 255.255.255.255 local-address 10.253.51.203 ! crypto ipsec security-association replay window-size 128 crypto ipsec transform-set set1 esp-aes 256 esp-sha-hmac crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac crypto ipsec df-bit clear ! crypto ipsec profile isakmp1 set transform-set set1 set pfs group2 ! crypto map VPN redundancy replay-interval inbound 1000 outbound 20000 crypto map VPN 1 ipsec-isakmp set peer 10.253.51.204 set transform-set ESP-3DES-MD5 !- use AES in production match address VPN crypto map VPN redundancy HA-WAN-LAN

interface FastEthernet0/0 description.- POD.- ip address 10.253.51.201 255.255.255.0 duplex auto speed auto ipv6 address 2001:41B0:110:A100::1/120 ipv6 nd ra suppress standby 1 IP 10.253.51.203 standby 1 preempt standby 1 name HA-WAN-LAN crypto map VPN redundancy HA-WAN-LAN

interface Tunnel1 IP address 10.0.0.1 255.255.255.252 IP virtual-reassembly IP tcp adjust-mss 1379 tunnel source 10.253.51.203 tunnel destination 10.253.51.103 tunnel mode ipsec ipv4 tunnel protection ipsec profile isakmp1 end

FastEthernet0/0. Group 1 State is Active 4 state changes, last state change 18:23:33 Virtual IP address is 10.253.51.203 Active virtual MAC address is 0000.0c07.ac01 Local virtual MAC address is 0000.0c07.ac01 (v1 default) Hello time 3 sec, hold time 10 sec Next hello sent in 2.844 secs Preemption enabled Active router is local Standby router is 10.253.51.202, priority 90 (expires in 7.296 sec) Priority 100 (default 100) Group name is HA-WAN-LAN (cfgd)

Router 2 crypto pki token default removal timeout 0 ! crypto keyring keyring1 local-address 10.253.51.203 pre-shared-key address 10.253.51.103 key KeY221# ! crypto isakmp policy 200 encr aes 256 authentication pre-share group 2 lifetime 28800 ! crypto isakmp key cisco address 10.253.51.204 crypto isakmp keepalive 10 10 crypto isakmp profile isakmp1 keyring keyring1 match identity address 10.253.51.103 255.255.255.255 local-address 10.253.51.203 ! crypto ipsec security-association replay window-size 128 crypto ipsec transform-set set1 esp-aes 256 esp-sha-hmac crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac crypto ipsec df-bit clear ! crypto ipsec profile isakmp1 set transform-set set1 set pfs group2 ! crypto map VPN redundancy replay-interval inbound 1000 outbound 20000 crypto map VPN 1 ipsec-isakmp set peer 10.253.51.104 set transform-set ESP-3DES-MD5 match address VPN crypto map VPN redundancy HA-WAN-LAN

interface FastEthernet0/0.551 description.- POD.- encapsulation dot1Q 551 IP address 10.253.51.202 255.255.255.0 ipv6 address 2001:41B0:110:A100::2/120 ipv6 nd prefix 2001:41B0:110:A100::/120 3600 3600 ipv6 nd managed-config-flag ipv6 dhcp relay destination 2001:41B0:110:B100::5 FastEthernet0/0.550 standby 1 IP 10.253.51.203 standby 1 priority 90 standby 1 name HA-WAN-LAN crypto map VPN redundancy HA-WAN-LAN end ! interface Tunnel1 IP address 10.0.0.1 255.255.255.252 IP virtual-reassembly IP tcp adjust-mss 1379 tunnel source 10.253.51.203 tunnel destination 10.253.51.103 tunnel mode ipsec ipv4 tunnel protection ipsec profile isakmp1 end

The moment of truth

After configuration landed on iOS we are ready to start traffic verification. I generated the icmp traffic first to simulate communication between legacy VPN sites and customer Data Center LAN.

ICMP from reugular IPSec site to redundant DC VPN hub:

R4#ping 10.10.11.1 so l11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.11.1, timeout is 2 seconds: Packet sent with source address of 10.10.14.1.

So far so good. Now lets ping from AWS VPC to DC LAN

R3#ping 10.10.11.1 so l11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.11.1, timeout is 2 seconds: Packet sent with source address of 10.10.10.1. Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms

That works! So it is the time to display some outputs to proof the connectivity and encryption goes as supposed to. IKE phase 1 view from legacy site (crypto map):

R4#sh cry isa sa IPv4 Crypto ISAKMP SA dst src state conn-ID slot status 10.253.51.203 10.253.51.204 QM_IDLE 1003 0 ACTIVE

IPSec SAs view from legacy site (crypto map). Traffic is bidirectional and encrypted:

R4#sh cry ipse sa interface: FastEthernet0/0 Crypto map tag: VPN, local addr 10.253.51.204 protected vrf: (none) local ident (addr/mask/prot/port): (10.10.14.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.10.11.0/255.255.255.0/0/0) current_peer 10.253.51.203 port 500 PERMIT, flags= #pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9 #pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9

Output of show crypto isakmp sa on active HSRP router R1. As seen the phase 1 negotiated correctly:

R1#sh cry isa sa IPv4 Crypto ISAKMP SA dst src state conn-ID slot status 10.253.51.203 10.253.51.204 QM_IDLE 1005 0 ACTIVE !- Legacy Phase1 10.253.51.203 10.253.51.103 QM_IDLE 1006 0 ACTIVE !- AWS SVTI Phase1

Output from crypto ipsec sa. The VTI tunnel is working and traffic to AWS is encrypted:

interface: Tunnel1 Crypto map tag: Tunnel1-head-0, local addr 10.253.51.203

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 10.253.51.103 port 500 PERMIT, flags= #pkts encaps: 15, #pkts encrypt: 15, #pkts digest: 15 #pkts decaps: 15, #pkts decrypt: 15, #pkts verify: 15

Also crypto map does its job

interface: FastEthernet0/0 Crypto map tag: VPN, local addr 10.253.51.203 protected vrf: (none) local ident (addr/mask/prot/port): (10.10.11.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.10.14.0/255.255.255.0/0/0) current_peer 10.253.51.204 port 500 PERMIT, flags= #pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9 #pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9

In conclusion, my test shows that the Static VTI sourced from HSRP address and legacy Crypto Map (also sourced from the HSRP IP address) with IPSec redundancy can coexist on the same router preserving current corporate VPN tunnels while building Amazon Web Services VPC tunnel connection simultaneously.

Update: Works in production too. Confirmed by the customer 🙂

Testbed used for this scenario: Cisco ISR routers with iOS Version 12.4(15)T17

IPsec Site-to-Site VPN Palo Alto Cisco Router

This time I configured a static S2S VPN between a Palo Alto firewall and a Cisco iOS router. Here comes the tutorial:

I am not using a virtual interface (VTI) on the Cisco router in this scenario, but the classical policy-based VPN solution. That is, no route entry is needed on the Cisco machine. However, the Palo Alto implements all VPNs with tunnel interfaces. Hence, a route to the tunnel and Proxy IDs must be configured. (I also wrote a guide for a route-based VPN between a Cisco router and a Palo Alto firewall here.)

In my test lab I am running a PA-200 with PAN-OS 6.0.3. The Cisco router is an old Cisco 2621 with iOS 12.3(26) and image “c2600-ik9o3s3-mz.123-26.bin”.

Laboratory

The following figure depicts my test laboratory:

Palo Alto

The configuration steps for the Palo Alto Networks firewall are the following:

• IKE and IPSec Crypto profiles, e.g., aes256, sha1, pfs group 5, lifetime 8h/1h.
• IKE Gateway with the pre-shared key and the corresponding IKE Crypto Profile. The “Identification” fields are not needed.
• Tunnel Interface within a virtual router (e.g., “default”) and a security zone (e.g., “vpn-s2s”). The interface does not need an IP address.
• IPSec Tunnel: Tying all together: tunnel interface, IKE gateway, IPSec crypto profile. Furthermore, the Proxy IDs (= protected networks) are set here.
• Static route to the destination network through the tunnel interface (without next hop address).
• 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.

Here are my configuration screenshots:

Cisco Router

The Cisco router, configured through the CLI, needs the following lines:

• crypto isakmp appropriate to the “IKE Crypto” on the PA
• crypto isakmp key with the pre-shared key
• crypto ipsec appriopriate to the “IPSec Crypto” on the PA
• access-list which defines the protected networks, corresponding to the “Proxy IDs”
• crypto map with the transform-set, peer, pfs group, and access-list
• crypto map applied to the outside interface
• (Note: No route entry is needed since this VPN is a policy-based VPN which makes its routing decision based on the access-list.)

Here is the bunch of my configuration commands:

Monitoring

After a successful establishment of the tunnel, the PA shows green bubbles in its IPSec Tunnels overview. The Session Browser reveals active sessions for ike or ciscovpn and ipsec-esp. However, I noticed that after these sessions are gone, only the ike sessions are in my traffic log, while the ipsec sessions are not correct according to the listed traffic bytes. Hm. Has anyone else recognized a similar behaviour?

The Cisco router can be queried with the subsequent commands:

And one more time: Since the Cisco Router decides its forwarding decisions for VPNs on the policy (ACL) and NOT on route entries, the routing table does NOT show any of my site-to-site remote networks, but only the connected and static configured routes:

Links

Similar information about this tunnel can be found here:

thoughts on “ IPsec Site-to-Site VPN Palo Alto Cisco Router ”

What if you have to make 4 policies on the Cisco Router? Do you create 4 tunnels on Palo Alto, or only the proxy ID

You mean if you have 4 ACL entries on the Cisco router? Then you have to set up these 4 networks in the Proxy ID section. You do NOT need to create 4 IPsec tunnels.

“And one more time: Since the Cisco Router decides its forwarding decisions for VPNs on the policy (ACL) and NOT on route entries, the routing table does NOT show any of my site-to-site remote networks, but only the connected and static configured routes” The ACL defines what traffic should be encrypted when it is being routed. However, you will NEED to have a route for your remote destinations. The routing decision is done first. Yes, you do not have the routes explicitly configured. You have a static route with a next hop given. This next hop is reachable out of Fa0/0. Traffic for your remote network will be routed out of Fa0/0 and since this interface has the crypto map applied and now the traffic does match the ACL it will be encrypted. Forwarding decision is done based on the routing table. What is being encrypted in decided by the ACL.

Sorry, but I am not showing these “vendor A to vendor A” cases. Please read the official Palo Alto documentation where it is explained in detail.

Hi, I’m not able to establish the vpn connection. I followed the instructions except for the IP addressing part. Not sure what’s the issue. I’m using GNS3 to do the testing. any advice on what to check? Cheers

Hi Dong, sorry, I cannot help you. There are MANY potential problems when it comes to IPsec with different vendors. Furthermore, I don’t know how exactly the IPsec implementation is build in GNS3. Try to debug as much as possible on both sides…

what if instead you had another cisco router behind the palo that wanted to initiate a tunnel with the cisco router on the other side? the palo would be nating traffic to the cisco router…

You mean: Router Palo Router while the VPN is terminated on both routers? Then it’s straightforward, since the Palo only acts as another router than can (but must not) do NAT.

Categories

This website uses cookies to improve your experience. We’ll assume you’re ok with this, but you can opt-out if you wish.Accept Read

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.

Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.

Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.

IPSec VPNs on Cisco routers when both are behind NAT

IPSec VPNs or really any site-to-site VPN works best when at least one of the sides or better yet both have Public IP addresses. But what if one is behind NAT, or even both? It gets increasing tricky to configure the correct IP addresses for authentication, and forward correct ports on protocols. As I recently discovered, using IKEv2 and/or GRE further complicates things. Consider this setup:

Both routers are behind NAT/PAT firewalls without static 1-to-1 NATs configured. There are still some requirements though:

• Both firewalls must allow for protocol 50 passthrough for IPSec, or protocol 47 passthough if using GRE, which most do
• At least one side must be forwarding ports udp/500 (isakmp) and udp/4500 (nat-t) to the router’s internet-facing interface so the connection can be established
• Both routers need crypto ipsec nat-transparency udp-encapsulation enabled, which is the default setting.

Let’s look at sample configs for each scenario. These assume 1921 ISR G2 routers but iOS-XE configs should be exactly the same.

IPSec with ISAKMP / IKEv1

The is the simplest way to do it since only public IPs need to be referenced.

crypto isakmp invalid-spi-recoverycrypto isakmp disconnect-revoked-peerscrypto isakmp keepalive 10 crypto isakmp nat keepalive 900 ! Policy supporting strong encryption crypto isakmp policy 100 encr aes 256 ! 256-bit AES encryption hash sha384 ! SHA-384 hashing authentication pre-share ! Using pre-shared keys lifetime 28800 ! 28000 seconds = 8 hours group 14 ! group 14 = 2048 bit key ! Backup policy supporting weaker encryption support for older devices crypto isakmp policy 200 encr aes ! 128-bit AES encryption hash sha ! SHA-1 hashing authentication pre-share ! Using pre-shared keys lifetime 28800 ! 28000 seconds = 8 hours group 2 ! group 2 = 1024 bit key ! FYI. default values are still des, sha, rsa-sig, 86400, group 1 :-O

2) And then pre-shared keys:

! Key for site 1 router crypto keyring Site2 local-address GigabitEthernet0/0 pre-shared-key address 203.0.113.222 key 0 MySecretKey ! Key for site 2 router crypto keyring Site1 local-address GigabitEthernet0/0 pre-shared-key address 198.51.100.111 key 0 MySecretKey ! Can also use crypto isakmp key 0 MySecretKey address 1.2.3.4

3) IPSec parameters. For encryption, I like to just use 128-bit AES with either SHA-256 or SHA-1 signing with a group 2 (1024-bit) key to make the tunnel negotiation quick as possible.

! Create some IPSec Transform sets for ESP 128-bit AES crypto ipsec transform-set ESP_AES128_SHA256 esp-aes esp-sha256-hmac mode tunnel crypto ipsec transform-set ESP_AES128_SHA esp-aes esp-sha-hmac mode tunnel ! Create IPSec profile crypto ipsec profile MY_IPSEC_PROFILE set transform-set ESP_AES128_SHA256 ESP_AES128_SHA set pfs group2 ! group 2 = 1024-bit key

Optional step: since the “client” side isn’t reachable on port udp/500, the “server” side may be configured as a responder. This cuts down superfluous traffic, especially when the client is unreachable.

crypto ipsec profile IPSEC_PROFILE responder-only

5) The last step is build the tunnel interfaces. For the “client” side:

interface Tunnel1000 IP address 169.254.0.1 255.255.255.252 IP tcp adjust-mss 1379 keepalive 10 3 tunnel source GigabitEthernet0/0 tunnel mode ipsec ipv4 tunnel destination 203.0.113.222 tunnel protection ipsec profile IPSEC_PROFILE

Server side is exactly the same but with different IP addresses:

interface Tunnel1000 IP address 169.254.0.2 255.255.255.252 tunnel destination 198.51.100.111

Doing debug crypto isakmp on the server side while the tunnels come up shows the public IP address of the client. Note the client’s random source ports.

ISAKMP (0): received packet from 198.51.100.111 dport 500 sport 14972 Global (R) MM_SA_SETUP ISAKMP (1003): received packet from 198.51.100.111 dport 4500 sport 51597 Global (R) MM_KEY_EXCH ISAKMP (1003): received packet from 198.51.100.111 dport 4500 sport 51597 Global (R) MM_KEY_EXCH ISAKMP:(1003):SA has been authenticated with 198.51.100.111 ISAKMP:(1003):Detected port floating to port = 51597

We never see client’s private IP, but we do see the server side’s private IP at the end when the SA is finally built:

ISAKMP:(1003): Process initial contact, bring down existing phase 1 and 2 SA’s with local 192.168.2.222 remote 198.51.100.111 remote port 51597 ISAKMP: Trying to insert a peer 192.168.2.222/198.51.100.111/51597/, and inserted successfully

Can also see the other site’s private IP by examining the SAs once built:

Site1#show crypto isakmp peers 203.0.113.222 Peer: 203.0.113.222 Port: 4500 Local: 192.168.1.111 Phase1 ID: 192.168.2.222 Site2#show crypto isakmp peers 198.51.100.111 Peer: 198.51.100.111 Port: 51597 Local: 192.168.2.222 Phase1 ID: 192.168.1.111

IPSec with IKEv2

IKEv2 is new to me, but it was a surprise to see slightly different behavior when using NAT. Run through of the configuration:

1) Set some global IKEv2 parameters

crypto logging ikev2 crypto ikev2 nat keepalive 900crypto ikev2 dpd 10 2 periodic

3) Keys are defined in the IKEv2 keyring, which has each site’s public IP address:

crypto ikev2 keyring MY_IKEV2_KEYRING ! Use this on site 1 router peer Site2 address 203.0.113.222 pre-shared-key MySecretKey1234 ! Must be 16 chars or longer ! Use this on site 2 router peer Site1 address 198.51.100.111 pre-shared-key MySecretKey1234 ! Must be 16 chars or longer
crypto ikev2 profile MY_IKEV2_PROFILE match address local interface GigabitEthernet0/0 match identity remote address 192.168.0.0 255.255.0.0 authentication remote pre-share authentication local pre-share keyring local MY_IKEV2_KEYRING dpd 20 2 periodic

This is where is gets weird because the “remote address” parameter needs to match the internal IP address(es) of the other sides. The simple and lazy approach is use 0.0.0.0 since that will match anything. The other option is use a different profile for each peer.

5) Add IKEv2 profile to the existing IPSec profile. Note that doing so shouldn’t break IKEv1 clients as the IKEv2 stuff should just be ignored.

crypto ipsec profile MY_IPSEC_PROFILE set transform-set ESP_AES128_SHA256_TUNNEL ESP_AES128_SHA1_TUNNEL set pfs group2 set ikev2-profile MY_IKEV2_PROFILE

In the SAs, we can see our private IP, but not the other side’s:

Site1#show crypto ikev2 sa remote 203.0.113.222 Tunnel-ID Local Remote fvrf/ivrf Status 1 192.168.1.111/4500 203.0.113.222/4500 none/none READY Encr: AES-CBC, keysize: 128, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK Life/Active Time: 86400/30 sec Site2#sh crypto ikev2 sa remote 198.51.100.111 Tunnel-ID Local Remote fvrf/ivrf Status 1 192.168.2.222/4500 198.51.100.111/51597 none/none READY Encr: AES-CBC, keysize: 128, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK Life/Active Time: 86400/71 sec

BTW, if NAT-T has been disabled but is required by the other end, debug crypto ikev2 will show this:

Oct 12 19:53:08.620: IKEv2-ERROR:(SESSION NAT is found but it is not supported.: NAT-T disabled via cli Oct 12 19:53:08.620: IKEv2-ERROR:(SESSION NAT-T disabled via cli