IPSEC VPN, VRF, NAT Banging head against the wall!!

millworx

Ughh. Reaching out for some help from the community on something that has been frustrating me all week! So I have multiple partners connecting into my ASR using policy based IPSEC VPN's. All those partners are dynamically NATed on my end. What I need to do is force the crypto traffic to the firewall, but have been unlucky in setting the next hop I've tried using route-maps in my ip nat statements which match the addresses and sets ip next hop. But nat ignores the next hop statement. It also ignores it if the route-map is applied to the interface directly, which is odd because NAT order of operations states routing / pbr takes place first prior to NAT when going from inside -> outside. This would not be a problem if I could use NVI with the ip nat enable command, but ASR's run IOS XE which does not support them, just old school nat.

So I tried to come up with another option since PBR isn't forcing the traffic to the firewall. I tried setting the interface into a VRF so I can set a static default for the VRF pointing to the firewall. Well.... This is where I am at now. The IPSEC tunnel comes up no problem when I try to pass traffic, but NAT is not working at all. And I'm wondering where my error is! Any suggestions guys? I attached my topology I'm playing with and my configs thus far. Please point out the error of my ways! This would be so much easier if it wasn't an ASR.



#####################################
PARTNER END CONFIG
#####################################
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key key123 address 10.33.69.242
!
!
crypto ipsec transform-set generic_tunnel_set esp-3des esp-sha-hmac
!
crypto map site_to_site 120 ipsec-isakmp
description TO COMPANYXYZ
set peer 10.33.69.242
set transform-set generic_tunnel_set
match address companyxyz-crypto
!
!
!
!
interface Loopback0
ip address 9.0.0.1 255.255.255.0
!
interface GigabitEthernet0/1
ip address 10.33.69.241 255.255.255.248
duplex auto
speed auto
media-type rj45
crypto map site_to_site
!
ip route 111.111.111.50 255.255.255.255 GigabitEthernet0/1
!
!
ip access-list extended companyxyz-crypto
permit ip 9.0.0.0 0.0.0.255 host 111.111.111.50
!
!

##################################
ASR1004
##################################
crypto keyring interconnect vrf interconnect
pre-shared-key address 10.33.69.241 key key123
!
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
!
crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
crypto isakmp profile partner1
vrf interconnect
keyring interconnect
match identity address 10.33.69.241 255.255.255.255
!
crypto ipsec transform-set generic_tunnel_set esp-3des esp-sha-hmac
!
!
crypto map site_to_site 120 ipsec-isakmp
set peer 10.33.69.241
set transform-set generic_tunnel_set
set isakmp-profile partner1
match address partner1-us-crypto
!
!
!
interface GigabitEthernet0/0/0
description outside VLAN to firewall
ip address 10.33.84.163 255.255.255.224
ip nat outside
speed 1000
no negotiation auto
cdp enable
!
interface GigabitEthernet0/1/7
description IPSEC VPN Terminations
ip vrf forwarding interconnect
ip address 10.33.69.242 255.255.255.248
ip nat inside
negotiation auto
crypto map site_to_site
!
ip route vrf interconnect 0.0.0.0 0.0.0.0 GigabitEthernet0/0/0 10.33.84.164 global
ip route vrf interconnect 9.0.0.0 255.255.255.0 GigabitEthernet0/1/7 10.33.69.241
!
ip access-list extended partner1
permit ip 9.0.0.0 0.0.0.255 host 111.111.111.50
ip access-list extended partner1-us-crypto
permit ip host 111.111.111.50 9.0.0.0 0.0.0.255
!
ip nat pool partner1-us-nat 172.30.10.9 172.30.10.10 netmask 255.255.255.252
ip nat inside source route-map TO_FW pool partner1-us-nat vrf interconnect overload
!
route-map TO_FW permit 10
match ip address partner1

cisco_trooper

The route-map in the nat statement won't perform PBR. PBR will have to be applied to an interface. Define a new ACL to use to identify the traffic flow you desire to route via PBR, but use the mapped address instead of the real address. Set your next hop to your firewall. We'll have to double check the order of operations of NAT/Routing/PBR/Crypto. These things sometimes vary, which is annoying, but such is life.

Routerronin

Nat and Ipsec go together like active volcanoes and ancient ruins, everytime I try to combine the two, things cease to go my way. This has been an issue for my gre tunnels so I will stay tuned to this thread to hear about some interesting solutions.

fredrikjj

Routerronin wrote: »

Nat and Ipsec go together like active volcanoes and ancient ruins, everytime I try to combine the two, things cease to go my way. This has been an issue for my gre tunnels so I will stay tuned to this thread to hear about some interesting solutions.

The solution is to exclude the internal ip addresses from the NAT translation if they are going over the IPsec tunnel.

In the NAT ACL you would add deny ip <source private ip range> <destination private IP range>. The result is that internet traffic will be translated, but traffic destined for the IPsec WAN link will go into that process with the private IP intact.

If you don't do this NAT will translate the IPs before the IPsec does its work and it'll get the wrong input.

Routerronin

fredrikjj wrote: »

The solution is to exclude the internal ip addresses from the NAT translation if they are going over the IPsec tunnel.

In the NAT ACL you would add deny ip <source private ip range> <destination private IP range>. The result is that internet traffic will be translated, but traffic destined for the IPsec WAN link will go into that process with the private IP intact.

If you don't do this NAT will translate the IPs before the IPsec does its work and it'll get the wrong input.

Thanks Fred, will have to lab this asap.