×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

S2S VPN and NAT

Unanswered Question
Nov 5th, 2014
User Badges:
  • Purple, 4500 points or more

All,

I have a 2900 that's terminating to the main site which has an ASA. The vpn tunnels work fine, but there's a change that we need to make. I was requested to configure nat on the branch router. The branch does some things over the web that are business-related, and if the vpn tunnel goes down, they wouldn't have internet access since I was sending everything over the tunnel.

So, of course after configuring nat, I'm now effectively split tunneling which isn't what I was wanting to do. Has anyone had any experience, if it's even possible, to still send everything over the tunnel even though nat is configured on the router? I can only deny the networks over the tunnel from being natted, but I can't do a "deny all" from being natted because that would defeat the purpose.

One solution that I've thought of is to write an eem script to remove a "deny all" line in nat, so when the vpn tunnel were to go down, the line would be removed and then everything could be natted. Any ideas?

Thanks,

John

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Karsten Iwen Wed, 11/05/2014 - 06:37
User Badges:
  • Purple, 4500 points or more
  • Cisco Designated VIP,

    2017 Firewalling, VPN

Not sure if I really understand your problem, but you could add the translated address to VPN-definition. As NAT is done before VPN, the packet would first get a new (public) ip, then this packet has to match your crypto-ACL and gets sent over the tunnel.

But when the tunnel is down, the traffic would still match the VPN-definition and would be dropped instead of being sent in clear. One workaround for that could be the "optional ipsec" configuration where traffic is sent in clear instead of being dropped when the tunnel can not be established. That's probably also not what you want.

Another options:

If you could place a router on the Head-end, you could use virtual tunnel interfaces. With these you can configure NAT on the Internet-interface but work without NAT on the VPN-tunnel. The routing will control if the traffic goes directly to the internet or over the tunnel.

John Blakley Wed, 11/05/2014 - 07:05
User Badges:
  • Purple, 4500 points or more

Thanks Karsten. The issue is that I have this vpn tunnel to our corporate office. They have a cable connection that has its own public address, but not part of our mpls network. Currently they traverse the tunnel for everything including internet, so I don't have nat configured on the router. The idea was that if the vpn tunnel were to go down, they wouldn't get internet access due to nat not being configured on the router.

Once I configure nat on the router, I can deny destinations over the tunnel from being natted, but anything that doesn't match that would go outside of the tunnel and then be natted. That means they're now seen as they're own public address.

So here's where the problem comes in. The way that they're designed now, I have a static nat on our corporate firewall that forwards traffic to a server in their subnet over the tunnel. When I configured nat to test this concept, I was unable to successfully telnet to that address/port. The traffic would get there, but because it was sourced from something outside of the tunnel, the return traffic went out of their public interface natted, so I never received the return traffic.

access-list 100 deny ip 10.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
access-list 100 permit ip 10.20.20.0 0.0.0.255 any

The above acl, as you know, is standard for anything vpn related. What my question mainly is is how can we still have the above functionality for all traffic by sending everything, including internet, over the vpn tunnel, but be able to nat when the vpn tunnel is down?

My first thought is add a line to the acl above "deny ip 10.20.20.0 0.0.0.255 any", and then write an eem script to remove this line should the tunnel go down. I agree that VTIs would be a better solution, but unfortunately that's not something that I'm going to be able to do in this scenario.

Thanks!

John

Karsten Iwen Wed, 11/05/2014 - 07:46
User Badges:
  • Purple, 4500 points or more
  • Cisco Designated VIP,

    2017 Firewalling, VPN

ok, some more brainstorming ...

  1. Is you main intention to make that server work even when the tunnel is down? Then you could configure two addresses on the server. The additional address is used to access the server with the static NAT on the central firewall and this address is exempted from NAT. The main address is used with NAT on the router to give internet access.
  2. If you migrate the tunnel to EasyVPN and configure the router as an EasyVPN-remote device, then the router could gets the NAT-config from the Headend device. I never used it that way but if you want to investigate that way, here is the config-guide:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_esyvpn/configuration/15-mt/sec-easy-vpn-15-mt-book/sec-easy-vpn-rem.html#GUID-40E16F04-6000-4FC4-B9D1-2809F42292A5

John Blakley Wed, 11/05/2014 - 07:55
User Badges:
  • Purple, 4500 points or more

Thanks Karsten. I had thought about changing the A record to point to their public address instead of the one that I'm using for them....I think I'm putting a pin in this until I get more information from management as to what they want to do.

Thanks!

John

David_Che Wed, 11/05/2014 - 07:11
User Badges:

I agree with the second option that use virtual tunnel interface, after ipsec tunnel is established, configure routing protocol on this tunnel, advertise one default route from HUB to spoke, then configure one floating default route with MD=250

ip route 0.0.0.0 0.0.0.0 tunnel   110 (routing protocol is ospf) 

ip route 0.0.0.0 0.0.0.0 internet-face physical interface 250 (this is static route)

when the tunnel is up, all traffic are delivered by ipsec tunnel, when is tunnel is down, all the traffic will be NATed.

Actions

This Discussion