Site to Site VPN problem

[Colin Higgins]

I have an old Cisco 1750 router with the VPN module in it with a site-to-site IPSec VPN to a Cisco ASA

There are three tunnels on this router, and two are working. The third tunnel is configured exactly like the other two, but does not seem to be passing traffic. On the remote ASA, if I do a packet-trace input command, everything checks out: the proper ACL/crypto-map is referenced, NAT exemptions are done, and VPN policy cleared. Everything says OK.

If I ping through the remote ASA, I see the traffic going through the tunnel to the remote 1750 router, but nothing comes back. If I do a show crypto isakmp sa I see the tunnel is up. Packets are being encapsulated, but not de-encapsulated.

If I try to open the tunnel from the 1750 router by referencing an interface within the crypto-map range (interface vlan1 192.168.20.1), the tunnel does not come up. I am not sure I can do this, but it is a remote site, and I have few other ways to test.

The tunnel shows up on the 1750, but nothing is being encapsulated/encrypted.

Nothing is being Natted on the 1750 (even though there are nat statements on the inside and outside)

Here is the edited config

crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key <hidden> address <hidden> no-xauth
crypto isakmp key <hidden> address <hidden> no-xauth
crypto isakmp key <hidden> address <hidden> no-xauth
no crypto isakmp ccm
!

ip access-list extended ATS-TRAFFIC-CA
permit ip 192.168.20.0 0.0.0.255 172.25.91.64 0.0.0.31
ip access-list extended ATS-TRAFFIC-DR
permit ip 192.168.20.0 0.0.0.255 172.29.91.64 0.0.0.31
!
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
!
crypto map ACME 1 ipsec-isakmp
set peer <hidden>
set transform-set ESP-3DES-SHA
match address 101
crypto map ACME 2 ipsec-isakmp
set peer <hidden>
set transform-set ESP-3DES-SHA
match address ATS-TRAFFIC-DR
crypto map IGOR_TW 3 ipsec-isakmp
set peer <hidden>
set transform-set ESP-3DES-SHA
match address ATS-TRAFFIC-CA
!
!
!
interface FastEthernet0
ip address <outside address hidden>
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
crypto map IGOR_TW
!
interface FastEthernet1
!
interface FastEthernet2
!
interface FastEthernet3
!
interface FastEthernet4
!
interface Vlan1
ip address 192.168.20.1 255.255.255.0

so the first two tunnels work, but the third does not. I am out of ideas.

[rizwanr74]

Hi Colin,

I see, you have two separate crypto instances have been created as shown in the red and green fronts.

crypto map ACME 1 ipsec-isakmp
set peer <hidden>
set transform-set ESP-3DES-SHA
match address 101

crypto map ACME 2 ipsec-isakmp
set peer <hidden>
set transform-set ESP-3DES-SHA
match address ATS-TRAFFIC-DR

crypto map IGOR_TW 3 ipsec-isakmp
set peer <hidden>
set transform-set ESP-3DES-SHA
match address ATS-TRAFFIC-CA

Whereas I see only this particularity crypto instance is assigned to Interface "FastEthernet0"

interface FastEthernet0
ip address <outside address hidden>
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
crypto map IGOR_TW

Do you have different interface where other crypto instance is being terminated on?

[Colin Higgins]

sorry, that was a typo. the third entry is

crypto map ACME 3 ipsec-isakmp
set peer <hidden>
set transform-set ESP-3DES-SHA
match address ATS-TRAFFIC-CA

and the map on the interface is ACME

I was replacing the name IGOR_TW with ACME

[Jon Marshall]

Are you doing NAT exemption on the VPN traffic.

If so have you done it for the tunnel that isn't working ?

Jon

[Colin Higgins]

Actually, I just too the NAT out of the picture altogether (removed ip nat inside, and ip nat outside for the interfaces

this router only does VPN, so no need for the NAT

Still not working for the third tunnel. When I do a ping from the remote end, the tunnel comes up, but no traffic comes back. The debug says Phase 2 completed.

I cleared the session, re-entered the key, and checked ACLs on both sides.

[rizwanr74]

Are you able to post the trouble tunnel configuration piece?

[Colin Higgins]

I am seeing some weird errors on the 1750 router side

ISAKMP:(0:112:HW:2):deleting node 2089010888 error FALSE reason "Informational (in) state 1

and

*Sep 26 15:09:54.479: ISAKMP:(0:112:HW:2):purging node

[rizwanr74]

It is not easy to trouble shoot with log messages, log messages could means many things.

[Colin Higgins]

well I did some deep debugging, and the ASA successfully sets up the tunnel, with the correct encryption domains (I thought maybe it was an issue with the ACLs, but everything looks perfect in the debugs). The errors above were probably when I was clearing the session during troubleshooting.

Nevertheless, I can't ping through the tunnel. The other two tunnels don't have this issue. I've never seen this before.

[johnlloyd_13 · Accepted solution]

hi colin,

are the two peers able to ping each other's WAN/public IPs?

please provide sanitized config from your ASA for the 3rd VPN tunnel.

kindly do a LAN-to-LAN IP ping and post the debugs (from any peer), i.e. from 1750:

ping 172.25.91.65 source 192.168.20.1

debug crypto isakmp
debug crypto ipsec

[Colin Higgins]

hey John:

both devices can ping each other's WAN/outside interfaces.

I can get you the debugs in the morning.

This is very strange, as when the ASA detects the interesting traffic, it initiates tunnel setup, and according to what I saw in the logs, it completes (goes ACTIVE). I see packets getting encapsulated/encrypted outbound, but nothing is coming back.

It's like the return traffic is getting black-holed. Could the ISP be blocking ESP? (it is on a protected government network)

[johnlloyd_13]

hi,

i would need the snippet of your ASA config and debug output to see what's really going on. i suspect the crypto ACL aren't matched or properly configured. i haven't seen ISP blocking VPN traffic although i've heard china ISPs have started to do so.

[Colin Higgins]

OK, this gets even stranger

After checking the ACLs and configs, I built two packet captures: one on the ASA, and one on the Router for icmp echo and echo-reply between hosts 172.25.91.67 and 192.168.20.20.

I see the traffic go through the ASA as the tunnel is set up without errors.

On the router, I see the tunnel come up and the icmp echo requests arrive and hit 192.168.20.20

The replies are sent back out through the tunnel by the router

But the packets are never received by the ASA -they are "lost in transit" somewhere. So return traffic vanishes.

[Colin Higgins]

Problem solved:

The ISP was blocking ESP (protocol 50), but was allowing 500 through. The tunnel would set up, but no traffic could go through it.

[rizwanr74]

Ok, which instance of ACME instance you are having issue with, please post that configuration piece alone.

thanks.