Site to site VPN up but no traffic

[nomis8831]

Hi, can anyone help, we have a site to site VPN setup between a Cisco ASA 5510 and a Smoothwall S14, looking at the Cisco ASDM it states the tunnel is up but I'm unable to ping anything from either side.

I have tried creating the VPN manually and with the site to site wizard but get the same result.

I have tried with the Smoothwall as the Initiator and the Cisco as the responder and the reverse of this but still, get the same the tunnel is up but no connection between sites.

We have a site 2 site tunnel from another site (Site 2) and that one works, I have attempted to explain in topology and attached.

I have used the following to configure the VPN:

Name: Smoothwall VPN to ASA
Local Public IP: 2.2.2.2
Remote Public IP: 1.1.1.1
Local Network: 172.19.171.0/24
Remote Network: 172.16.0.0/21 10.52.0.0/21 10.75.0.0/21 10.59.0.0/21 172.18.0.0/21 172.19.0.0/21
Auth Method: Pre Shared Key
Preshared Key: foobar
Authentication type:ESP
Phase 1 Algo: AES128
Phase 1 Hash: MD5
DeadPeerDetection: Enabled
IKE v1
Phase 2 Algo: AES128
Phase 2 Hash: MD5
Phase 1/2 DH Group: 2
Phase 1 Key Lifetime: 60 mins
Phase 2 Key Lifetime: 30 mins
PFS Enabled

Name: VPN ASA to SW
Local Public IP: 1.1.1.1
Remote Public IP: 2.2.2.2
Local Network: 172.16.0.0/21 10.52.0.0/21 10.75.0.0/21 10.59.0.0/21 172.18.0.0/21 172.19.0.0/21
Remote Network: 172.19.171.0/24
Auth Method: Pre Shared Key
Preshared Key: foobar
Authentication type:ESP
Phase 1 Algo: AES128
Phase 1 Hash: MD5
DeadPeerDetection: Enabled
IKE v1
Phase 2 Algo: AES128
Phase 2 Hash: MD5
Phase 1/2 DH Group: 2
Phase 1 Key Lifetime: 60 mins
Phase 2 Key Lifetime: 30 mins
PFS Enabled

Thanks

[Rob Ingram]

Well it certainly looks like 172.19.171.1 is routed to the ASA, but this doesn't appear to be sent over the tunnel (no encaps). Can you just provide your full configuration

[nomis8831]

Hi Rob,

here is the config, any questions let me know.

EDIT: I also forgot to say that the working VPN (3.3.3.3) with an internal IP range 10.201.0.0/16 is also not in the routing list.

I assume that the 172.19.171.0/24 and the one above is sent to the ASA by the "Gateway of last resort is 172.16.0.8 to network 0.0.0.0".

Simon

[nomis8831]

UPDATE:  the data is now being encapsulated, after a reboot of the ASA,  I assume that means that the data is going via the VPN now.  I have also reduced the amount of VLAN we are using to limit the log information.

The #pkts encaps, #pkts encrypt, #pkts digest all now increase as we ping the internal NIC of the remote system

show crypto ipsec sa peer 2.2.2.2
peer address: 2.2.2.2
Crypto map tag: Outside_map, seq num: 3, local addr: 1.1.1.1

access-list Outside_cryptomap_3 extended permit ip 172.16.0.0 255.255.248.0 172.19.171.0 255.255.255.0
local ident (addr/mask/prot/port): (VLAN_Server_LAN/255.255.248.0/0/0)
remote ident (addr/mask/prot/port): (172.19.171.0/255.255.255.0/0/0)
current_peer: 2.2.2.2

#pkts encaps: 178, #pkts encrypt: 178, #pkts digest: 178
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0

[Rob Ingram · Accepted solution]

If your encaps are increasing but not receiving traffic (decaps) then the issue probably exists on the other end (smoothwall). Double check the crypto ACL that defines interesting traffic and ensure traffic is not NATTED on the smoothwall.

[nomis8831 · Accepted solution]

Hi Rob,

let's start off with, Thank you very much for your help on this and yep you called it it was the other end.

So after a long time talking to the call handler at BT we finally got to speak with someone in the tech team, who said that the external IP we were using for the remote site was incorrect and instead we were to use the external IP of the Meraki box as this would nat the traffic to the Smoothwall external IP.

So we configured the ASA VPN peer address to 2.9.9.9 (Meraki IP) but instead of 2.2.2.2 (Smoothwall IP), and tunnel started and traffic was flowing without issue.

The tech team said that this is a common issue with the way the Meraki is set up, it will create the tunnel but as the packets are encrypted it sees them as non-related and drops them unless you use the Meraki IP address, it's a shame we did not get to speak to the tech team a week earlier as were told then by the call handler that nothing was being done.

Again thanks again for your help.