ISR 4331 NAT configuration issue for IPSec VPN tunnel

[freeman6351]

Hello Everyone!

I need to establish a site to site/L2L VPN tunnel over a network segment that does not permit ESP or AH protocol traffic. EZVPN or other VPN server/client options will not work in this use case as we need direct LAN to LAN connectivity. After some research I do not believe Cisco IOS-XE has an option to force using NAT-T with UDP 4500 encaps and NAT-T is only used when NAT is automatically discovered between VPN public peers from comparing source/destination IP hashes. There is no NAT configured between the VPN endpoints and adding another router with NAT configured between the 2 VPN end points is also not an option.

Below is a basic diagram of the topology involved.

I have been attempting to configure a Cisco 4331 (REMOTE1) router as a VPN endpoint that will NAT the site to site VPN tunnel negotiation traffic by using a loopback interface set with ip nat inside as the VPN crypto source interface. I can get the VPN tunnel UP-ACTIVE and both endpoints will encaps/encrypt data over the tunnel using UDP 4500, but neither endpoint will decaps/decrypt any data. I have also verified when either router encaps data over the VPN tunnel that UDP 4500 packets are received at the remote end. I'd prefer to avoid changing the configuration on the HQ 4331 router if possible as there are existing VPN tunnels on the 172.19.1.2 interface I don't want to disturb. 

I suspect REMOTE1 router may not be denying and permitting the correct traffic for NAT overload or perhaps my configuration approach will not work in general, but any guidance or configuration advice would be greatly appreciated!

I have attached the sanitized configurations of the 2 Cisco 4331 VPN endpoints along with some additional troubleshooting output (show crypto isakmp sa detail; show crypto ipsec sa detail; show ip nat translations). 

Thanks in advance!

Chris

[Georg Pauwen]

Hello,

I don't see how you can build an IPSec VPN without ESP and/or AH. How is the ISP 'blocking' these ? Either way, is a simple GRE tunnel an option ?

[freeman6351]

Hi Georg,

When NAT Transversal feature is used on an IPSec VPN, ESP and AH packets are wrapped/encapsulated into a UDP 4500 packet so they can pass through NAT interfaces between the VPN peers. Is the GRE tunnel option similar to what Paul is suggesting below with a static VTI IPSec VPN?

[Georg Pauwen]

Hello,

either 'traditional' crypto maps and VTI still uses ESP and/or AH. To be honest, I am not sure I fully understand the issue. Do you know for a fact that the ISP is blocking ESP/AH, or do you suspect the ISP blocks it because the VPN does not work ?

[freeman6351]

Hi Georg,

The "Provider Network" in the diagram is not an ISP in this case and is a simplification of the real network topology involved. Right now there is a logical IP layer link established between HQ router VPN Peer IP 172.19.1.2 and REMOTE1 router VPN peer IP 10.170.241.238. Part of the network between these two IP addresses is outside of my control, but the outside party has confirmed for a fact via packet captures that ESP traffic is being dropped intentionally due to their security policies which can't be changed. 

I agree that 'traditional' crypto maps and VTI use ESP and/or AH protocol for encrypted IPSec data payload when there is no NAT between the VPN peers. If there is NAT occurring between 2 IPSec VPN endpoints and both endpoints support NAT Transversal (NAT-T) the ESP/AH traffic is wrapped in a UDP 4500 packet before being sent which I believe will solve my problem with ESP being blocked. This article may have additional info Cisco IOS-XE NAT-T .

Other router OEMs have a configuration option to force using NAT-T for IPSec even if no NAT is detected between VPN peers. Cisco NAT-T can only be auto negotiated or disabled to my knowledge so I'm trying to find a way to add NAT between the two PBR IPSec VPN peers I have access to in the attached configurations.

[paul driver]

Hello
Instead of a crypto map, try utilizing a virtual tunnel interface ( VTI static) with a ipsec profile.- review here

[freeman6351]

Hi @paul driver 

Is it possible for the REMOTE1 router to be configured with a static VTI IPSec interface and the HQ router keep the existing PBR crypto map on 172.19.1.2?

I suspect from reviewing the provided link on VTIs, that both VPN peers would need to be configured with a static VTI IPSec interface.

The HQ router PBR IPSec crypto map 172.19.1.2 interface is used as a hub to many other spoke VPN tunnels outside of the one being discussed and don't think changing the PBR IPSec VPN on the HQ router will be a feasible option. Adding some very simple routing protocol configuration on the HQ and REMOTE1 routers may be possible, but would be concerned on possible impacts to other VPN tunnels/endpoint routing on the HQ VPN hub endpoint.

I'm really hoping to find a NAT or routing configuration change that would work with the site to site PBR IPSec VPN tunnel in the attached configurations. I also tested moving the ISAKMP source interface, crypto map, and NAT to attempt to source VPN traffic from LAN G0/0/1 on the REMOTE1 router instead of interface Loopback0, but did not help.

If I can't find any other suggestions, I may try to setup a simple VTI bench test with one VPN peer VTI set as ip nat inside, permit the ISAKMP UDP 500 negotiation traffic to be NATed, see if IPSec tunnel establishes with NAT-T to send encrypted traffic to the remote VTI peer via UDP 4500, and if tunnel will actually encrypt and decrypt at both VTI VPN interfaces. If that works out, I may be able to add a sub interface on the HQ router G0/0/2 dedicated to VTI IPSec tunnels.

Thanks,

Chris F.