Easy vpn drops due the ISP IP address change

[tom.dewaele]

I am doing some tests with Cisco Easy VPN between 2 IOS routers.

The VPN server is behind static NAT (done by a checkpoint firewall) and it has a fixed IP.

The Easy VPN client runs on a residential xDSL internet connection. It's behind a NAT router provided by the ISP.

The internet router has a dynamic public IP adres, and it changes every 36 hours (ISP does that, can't change it).

The easy vpn works fine. Both devices detect the NAT, and enable NAT-transparancy. The link comes up and works OK.

The issue I have, is that when the xDSL router changes it's public IP address, the IPSEC link drops and can't get back online.

It seems that the change in public IP address prevents the client to re-establish the VPN.

When I reload the vpn client router, the VPN comes back up.

Has anyone encountered this and is there any way I can avoid this problem ?

[Javier Portuguez · Accepted solution]

Hi Tom,

I have duplicated this issue in my lab, and instead of reloading the EzVPN client, you could simply remove the command "crypto ipsec client ezvpn YOUR_EZVPN"  from the outside interface and it should do it.

Now, since it makes no sense to do this manually every time it fails, I would suggest:

- Configured IP SLA and track reachability across the tunnel.

- With a "track" object you can define whether it fails or not.

- If it fails, then, remove and re-add the ezvpn command from the outside.

- For this you could use EEM.

Please check this out:

ip sla monitor 10

type echo protocol ipIcmpEcho 172.16.10.1 source-interface FastEthernet0/1

ip sla monitor schedule 10 life forever start-time now

!

track 10 rtr 10 reachability

!

event manager applet EzVPN_DOWN

     event syslog pattern "%TRACKING-5-STATE: 10 rtr 10 reachability Down->Up"

          action 1.0 cli command "enable"

          action 1.1 cli command "configure terminal"

          action 1.2 cli command "interface f0/0"

          action 1.3 cli command "no crypto ipsec client ezvpn YOUR_EZVPN"

          action 1.4 cli command "crypto ipsec client ezvpn YOUR_EZVPN"

          action 1.5 cli command "end"

Where:

FastEthernet0/1 ---> Inside interface

FastEthernet0/0 ---> Outside interface

172.16.10.1 ---------> Remote IP reachable through the EzVPN tunnel, when up and running.

So basically, when the SLA reports the failure (most likely because the tunnel is down) the Router removes the EzVPN command and puts it back in.

HTH.

Portu.

Please rate any helpful posts

Message was edited by: Javier Portuguez

[tom.dewaele]

Hello Javier,

Many thanks for your testing and answer !!!

There is a minor error in your example: Down->Up should be Up->Down

I've put your idea into action.

At first it didn't work. The applet executed the commands but the VPN stayed down.

After a bit of troubleshoot, I found the problem.

I am testing on a xDSL link at work, with a cisco router acting as the "ISP NAT router" I spoke of.

It does natting, and has the Cisco IOS firewall running.

The latter was preveting the reconnection. The connection is monitored by the IOS FW, which means it's using source/destination port/IP to identify the connection.

However, since neither the destination or source IP changes, and source/dest ports are both 4500, it does not see it as a new connection and seems to reject it. At least that's what I think.

When I cleared the IOS FW sessions, the VPN came back up.

I tried switching to cTCP. That works since it's using a random source port, unlike NAT-T which uses udp/4500 as source AND destination ports. cTCP also seems less impacted by the change in public IP address.

But I've done testing with cTCP and I did have issues, I just don't seem to be able to reproduce them right now (It re-established even without the workaround applet).

I am going to leave the router in test, using both your workaround solution and cTCP and see if I can get the VPN stable for a longer time.

I have another test router at home and I will test the NAT-T with your workaround there. That router is behind a ISP provided router. It might be less sensitive to the udp/4500 connection identification.

Fingers crossed...

[Javier Portuguez]

Tom,

You are very welcome.

Good to know you found my error, I did not notice that I actually copied that wrong pattern (it was for a different test).

Let's give it a try and keep me posted.

Portu.

Please rate any helpful posts

[Marvin Ruiz]

Really useful information Javier, Thanks a lot.