1801 to 1841 VPN is up but can't PING either end

[justincanino]

hi there,

i've just connected my 1801 router to a remote 1841 router via a IPsec VPN and i have the two routers with an active crypto session details are as follows

1801 (Office End)

192.168.200.0/24

Static WAN IP

ip access-list extended VPN1-TRAFFIC
 permit ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
!
access-list 100 remark -=[Define NAT Service]=-
access-list 100 deny   ip 192.168.200.0 0.0.0.255 192.168.100.0 0.0.0.255
access-list 100 permit ip 192.168.200.0 0.0.0.255 any
access-list 100 remark

1841 (Remote End)

3G dynamic IP

ip nat inside source list 100 interface Dialer0 overload
ip route 0.0.0.0 0.0.0.0 Dialer0
!
ip access-list extended VPN-TRAFFIC
 permit ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
!
access-list 100 remark -=[Define NAT Service]=-
access-list 100 deny   ip 192.168.100.0 0.0.0.255 192.168.200.0 0.0.0.255
access-list 100 permit ip 192.168.100.0 0.0.0.255 any
access-list 100 remark
dialer-list 1 protocol ip permit

-------------------

Both end have internet access but i can't Ping from Router to Router over the VPN

if anyone has any idea what might be causing it please let me know

thanks in advance

Justin Canino

[ghostinthenet]

Based on the ACLs provided, I'm guessing that you're using a traditional policy-based IPSec VPN here.

Assuming that the VPN itself is correctly configured, you can't ping router to router because your source address isn't covered by the VPN definition. Unless told to do otherwise, the router will use the IP address closest to the destination as its source address for ping, telnet, ssh, &c. In this case, that address will be the WAN address, which isn't in the VPN ACLs.

Try pinging the other router using a source interface that is within the VPN definition and see if you have better results.

When using routers rather than security appliances, it's often better to use VTIs rather than crypto maps. These eliminate the need to define NAT exceptions or source and destination networks. They will also allow the routers to communicate with each other across the VPN without special considerations about where the traffic is sourced from.

[justincanino]

Hi Jody,

thanks for your reply ok i've just tried pinging from router to router as you suggested

From remote end

Router#ping 192.168.200.254 source fastEthernet 0/1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.200.254, timeout is 2 seconds:
Packet sent with a source address of 192.168.100.10
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 708/785/1008 ms

From Office end

Router#ping 192.168.100.10 source vlan 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.200.254

---------------

Now that has worked once but when i try again it wont PING

ok i'll have to read up on VTI's - sounds like a more reliable configuration

thanks once again

[justincanino]

it's working again i can PING router to router just had my net drop out at the same time .. what are the chances of that happening ..

[ghostinthenet]

It's surprising how often those sorts of coincidences happen. :)

I'm sure you'll find the VTI approach to be much cleaner.

If you've found any of this helpful, please remember to rate responses and mark one of them as correct.

[justincanino]

since your mentioned about VTI i've been looking into it and found that it can only be used if both ends use a static IP address my problem is one end of my link has a dynamic IP address. i'll keep reading and see what else i can find

thanks

[ghostinthenet]

There are a number of ways to use VTI with dynamic IP addresses. For your application, have a look at EZVPN with Dynamic VTI here:

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-ipsec/prod_white_paper0900aecd803645b5.html

[justincanino]

Thanks for that i think that was something i was looking at this morning i'll give that a try today and see how it goes for me

[justincanino]

The one thing i've noticed it once there is no traffic on the VPN the tunnel drops even though the "show crypto sessions" shows both ends are up-active .. but once i tear down the remote end of the VPN and reconnect i can PING once again .. and if i run a constant PING end to end it'll stay up without a problem.

i have the lifetime set to 86400 seconds (1 day) so i would think that the VPN isn't timing out

any thoughts ?

[ghostinthenet]

IPSec tunnels are interesting in that they're not really session-based in the way that PPTP and L2TP are. They're essentially just an agreed-upon set of rules for encrypting certain traffic, so they go up and down on as needed. Your 86,400 second lifetime is only for the key exchange piece of the connection. The actual IPSec security association lifetime defaults to one hour. If there is a mismatch on either end in timeout values, this can cause the tunnel to renegotiate more often.

When the tunnel "goes down" do you find that connectivity drops completely until you clear it and allow it to renegotiate?

[justincanino]

yes thats correct i have to console into the remote router and run a clear crypto session and then PING from the remote end to the office end and the connection re-establishes again. I've setup NTP on the remote end to look to the office router for updates thinking that traffic would be enough to keep the tunnel alive but hasn't been so - so thinking i might try a PING across the link to keep the traffic flow.

[ghostinthenet]

You can also run ISAKMP keepalives for this purpose.

Try configuring "crypto isakmp keepalive 30 periodic" on both ends to see if that keeps things working for you.

[justincanino]

thanks i'll give that a crack