Solved: Site to site VPN up but no traffic

nomis8831 · ‎07-31-2020

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 · ‎08-05-2020

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.

View solution in original post

nomis8831 · ‎08-12-2020

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.

View solution in original post

Rob Ingram · ‎07-31-2020

Hi,
Have you defined a NAT exemption rule on the ASA, to ensure traffic over the VPN is not unintentially NATTED? Provide your ASA configuration and the output of "show nat detail".

Can you provide the full output of "show crypto ipsec sa" from the ASA.

HTH

nomis8831 · ‎07-31-2020

Hi Rob,
thanks for responding I have attached the output of the requested commands.

Simon

Rob Ingram · ‎07-31-2020

Your NAT rule seems ok. You’ve successfully established multiple IPSec SAs, however no traffic is encrypted or decrypted.

How are you testing?

Is routing setup correctly?

Is the ASA the default gateway for the devices connected behind it?

What about the configuration of the other device?

nomis8831 · ‎07-31-2020

How are you testing?

Ping from the inside interface of the ASA to the inside interface of the Smoothwall and then the other way the inside interface of the Smoothwall to internal DC on VLAN16 at the main site.

Is routing setup correctly?

I assume so is there a way to check from the console.

Is the ASA the default gateway for the devices connected behind it?

Yes, all internal VLANs point (Depending on VLAN it is always X.X.0.1) to the Catylist Core switch then that has a final route on the inside interface of the ASA (172.16.0.8).

What about the configuration of the other device?

don't have console access for here but I have attached a screenshot

Simon

Rob Ingram · ‎07-31-2020

Don't test from the ASA, you won't be sourcing traffic from the correct address as defined in the crypto ACL. Send a test ping from your core switch, define the source as the different VLAN - the destination should be a device (PC or switch etc) behind the smoothwall, not the smoothwall itself.

In your screenshot of the smoothwall, you've got DH Group 5 - but your DH group listed in your initial post says DH group 2. Ensure these match.

3DES and MD5 are weak, once you've got the tunnel up and working, consider using AES and SHA1, ideally SHA256.

nomis8831 · ‎07-31-2020

Ok just tried from the internal DC (172.16.010) to a Printer on the remote site 172.19.171.240), but still noting, soz been messing around since the original configuration data, have yet to change it back but noted on the weakness ta.

What bugging me is everything I can see indicate it should be working, we also have another site2site VPN that I created using the ASDM wizard and that is working fine, stupid question I can have multiple Site2Site VPNs coming in on the same outside interface (1.1.1.1), that has a /28 subnet but I tried to use one of the other IPs but it would not bring up the tunnel.

Simon

Rob Ingram · ‎07-31-2020

Did the encap|decap counters increase when you run the new test?

You can only establish a VPN to the IP address assigned to the outside interface. The sequence number distinguishes between different VPN peers

nomis8831 · ‎07-31-2020

ok so it's not that :(, the only thing I don't have access to is the Meraki router supplied by the ISP but they have said that there is no traffic shaping but that was only from the call centre and not the tech team.

Rob Ingram · ‎07-31-2020

You wouldn’t have established the IPSec SAs if the ISP were blocking anything. Take a packet capture to confirm bi-diectional traffic.

Check the smooth wall configuration (Nat), check the ipsec sa counters increase when you test. The fact that the ASA wasn’t encrypting traffic, nothing was being matched...hence why I want to know if the Ping from the DC increased the counters.

nomis8831 · ‎07-31-2020

Hi Rob do you mean the Counters on the ASA or the Smoothwall, if Smoothwall, ill have to respond after the weekend as I will need the supplied help as it is using Libreswan VPN software under the hood and I'm not sure how to get what you're looking for.

As for package capture from the ASA (wizard not how to do it from the command line) screenshot attached.

Simon

Rob Ingram · ‎07-31-2020

These counters need to increase:-

Result of the command: show crypto ipsec sa
interface: Outside
Crypto map tag: Outside_map, seq num: 3, local addr: 1.1.1.1

access-list Outside_cryptomap_3 extended permit ip 10.52.0.0 255.255.248.0 172.19.171.0 255.255.255.0 
local ident (addr/mask/prot/port): (VLAN_WIRED_ICT/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: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

nomis8831 · ‎07-31-2020

So pining from the DC ion VLAN16 (172.16.0.10/21) to 172.19.171.1, with about 1 min apart, no change,

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: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

Rob Ingram · ‎07-31-2020

No encaps. Provide the routing table of your switch and ASA.

nomis8831 · ‎07-31-2020

Hi Rob, is this what you are looking for?
for context the sanitized addresses
1.1.1.2 gateway of the outside interface

1.1.1.0 Network address

ASA Route

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 1.1.1.2 to network 0.0.0.0

O VLAN_Network_Management 255.255.248.0
[110/11] via 172.16.0.3, 43:17:49, Inside
C VLAN_Server_LAN 255.255.248.0 is directly connected, Inside
O 172.19.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:49, Inside
O 172.18.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:49, Inside
O VLAN_Legacy_Admin 255.255.0.0 [110/11] via 172.16.0.3, 43:17:49, Inside
O VLAN_Legacy_Curriculum 255.255.0.0
[110/11] via 172.16.0.3, 43:17:49, Inside
O 10.10.9.0 255.255.255.0 [110/11] via 172.16.0.3, 43:17:49, Inside
O 10.10.10.0 255.255.255.0 [110/11] via 172.16.0.3, 43:17:49, Inside
O E2 10.250.250.0 255.255.255.248 [110/20] via 172.16.0.2, 43:17:49, Inside
O 10.20.16.0 255.255.255.0 [110/11] via 172.16.0.3, 43:17:49, Inside
O 10.10.14.0 255.255.255.0 [110/11] via 172.16.0.3, 43:17:49, Inside
O E2 10.20.14.0 255.255.255.0 [110/20] via 172.16.0.2, 43:17:49, Inside
O 10.20.12.0 255.255.255.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O 10.20.10.0 255.255.255.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O 10.20.11.0 255.255.255.0 [110/11] via 172.16.0.3, 43:17:54, Inside
S 10.30.1.0 255.255.255.0 [1/0] via 172.16.0.2, Inside
S 10.30.2.0 255.255.255.0 [1/0] via 172.16.0.2, Inside
O 10.20.9.0 255.255.255.0 [110/11] via 172.16.0.3, 43:17:54, Inside
S 10.101.0.65 255.255.255.255 [1/0] via 1.1.1.2, Outside
O 10.59.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O VLAN_Wireless_ICT 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O 10.63.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O VLAN_Wired_Unauth 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O VLAN_Wired_Staff 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O VLAN_WIRED_Student 255.255.248.0
[110/11] via 172.16.0.3, 43:17:54, Inside
O VLAN_WIRED_ICT 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O VLAN_Wired_Admin 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O 10.74.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O Security_VLAN 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O 10.72.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O 10.73.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O 10.66.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O VLAN_Wireless_BCOT-ZONE 255.255.248.0
[110/11] via 172.16.0.3, 43:17:54, Inside
O 10.64.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O 10.65.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O 10.71.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O 10.68.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O 10.69.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
O 10.107.0.0 255.255.248.0 [110/11] via 172.16.0.3, 43:17:54, Inside
C 1.1.1.0 255.255.255.240 is directly connected, Outside
S* 0.0.0.0 0.0.0.0 [1/0] via 1.1.1.2, Outside

Core switch

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override

Gateway of last resort is 172.16.0.8 to network 0.0.0.0

S* 0.0.0.0/0 [1/0] via 172.16.0.8
10.0.0.0/8 is variably subnetted, 65 subnets, 4 masks
C 10.10.9.0/24 is directly connected, Vlan1009
L 10.10.9.1/32 is directly connected, Vlan1009
L 10.10.9.9/32 is directly connected, Vlan1009
C 10.10.10.0/24 is directly connected, Vlan1010
L 10.10.10.10/32 is directly connected, Vlan1010
S 10.10.13.0/24 [1/0] via 10.250.250.2
C 10.10.14.0/24 is directly connected, Vlan1014
L 10.10.14.1/32 is directly connected, Vlan1014
C 10.20.9.0/24 is directly connected, Vlan2009
L 10.20.9.1/32 is directly connected, Vlan2009
C 10.20.10.0/24 is directly connected, Vlan2010
L 10.20.10.1/32 is directly connected, Vlan2010
L 10.20.10.10/32 is directly connected, Vlan2010
C 10.20.11.0/24 is directly connected, Vlan2011
L 10.20.11.1/32 is directly connected, Vlan2011
C 10.20.12.0/24 is directly connected, Vlan2012
L 10.20.12.1/32 is directly connected, Vlan2012
C 10.20.14.0/24 is directly connected, Vlan2014
L 10.20.14.1/32 is directly connected, Vlan2014
O 10.20.16.0/24 [110/2] via 172.16.0.3, 1d19h, Vlan16
S 10.30.1.0/24 [1/0] via 10.250.250.2
S 10.30.2.0/24 [1/0] via 10.250.250.2
C 10.51.0.0/21 is directly connected, Vlan51
L 10.51.0.2/32 is directly connected, Vlan51
C 10.52.0.0/21 is directly connected, Vlan52
L 10.52.0.2/32 is directly connected, Vlan52
C 10.53.0.0/21 is directly connected, Vlan53
L 10.53.0.2/32 is directly connected, Vlan53
C 10.54.0.0/21 is directly connected, Vlan54
L 10.54.0.2/32 is directly connected, Vlan54
C 10.55.0.0/21 is directly connected, Vlan55
L 10.55.0.2/32 is directly connected, Vlan55
C 10.59.0.0/21 is directly connected, Vlan59
L 10.59.0.2/32 is directly connected, Vlan59
C 10.62.0.0/21 is directly connected, Vlan62
L 10.62.0.2/32 is directly connected, Vlan62
C 10.63.0.0/21 is directly connected, Vlan63
L 10.63.0.2/32 is directly connected, Vlan63
C 10.64.0.0/21 is directly connected, Vlan64
L 10.64.0.2/32 is directly connected, Vlan64
C 10.65.0.0/21 is directly connected, Vlan65
L 10.65.0.2/32 is directly connected, Vlan65
C 10.66.0.0/21 is directly connected, Vlan66
L 10.66.0.2/32 is directly connected, Vlan66
C 10.67.0.0/21 is directly connected, Vlan67
L 10.67.0.2/32 is directly connected, Vlan67
C 10.68.0.0/21 is directly connected, Vlan68
L 10.68.0.2/32 is directly connected, Vlan68
C 10.69.0.0/21 is directly connected, Vlan69
L 10.69.0.2/32 is directly connected, Vlan69
C 10.71.0.0/21 is directly connected, Vlan71
L 10.71.0.2/32 is directly connected, Vlan71
C 10.72.0.0/21 is directly connected, Vlan72
L 10.72.0.2/32 is directly connected, Vlan72
C 10.73.0.0/21 is directly connected, Vlan73
L 10.73.0.2/32 is directly connected, Vlan73
C 10.74.0.0/21 is directly connected, Vlan74
L 10.74.0.2/32 is directly connected, Vlan74
C 10.75.0.0/21 is directly connected, Vlan75
L 10.75.0.2/32 is directly connected, Vlan75
O E2 10.101.0.65/32 [110/20] via 172.16.0.8, 00:16:14, Vlan16
C 10.107.0.0/21 is directly connected, Vlan107
L 10.107.0.2/32 is directly connected, Vlan107
C 10.250.250.0/29 is directly connected, Vlan250
L 10.250.250.1/32 is directly connected, Vlan250
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.0.0/21 is directly connected, Vlan16
L 172.16.0.2/32 is directly connected, Vlan16
172.17.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.17.0.0/21 is directly connected, Vlan17
L 172.17.0.2/32 is directly connected, Vlan17
172.18.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.18.0.0/21 is directly connected, Vlan18
L 172.18.0.2/32 is directly connected, Vlan18
172.19.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.19.0.0/21 is directly connected, Vlan19
L 172.19.0.2/32 is directly connected, Vlan19
172.21.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.21.0.0/16 is directly connected, Vlan21
L 172.21.255.254/32 is directly connected, Vlan21
172.22.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.22.0.0/16 is directly connected, Vlan22
L 172.22.255.254/32 is directly connected, Vlan22