Packets are not being de-capsulated on the ASA end of a VPN

Question

I have an ASA that I take care of remotely. On this device, there are about 6 IPSec tunnels.

All of them work as expected. Recently I had to create one for the new office. I am having problems with this one. I can't figure out where the problem lies.

The ASA isn't decrypting packets arriving from the far end of the tunnel. In our environment, we use Fortigate and Cisco firewalls. Most of the tunnels we have are between these two vendors and they all work, except this one!

Info: Toronto = Fortigate (192.168.185 network) London = ASA 9.x (10.101.0.0 network)

If I ping from Toronto to London it will fail. If I put a capture on the VPN interface to London I see the packets egressing. So they are being sent out onto the tunnel.

If I ping from London to Toronto, it will too fail. But, in Toronto if I do a capture on the host that I am pinging I can see the pings:

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 17:48:47.938568 IP 10.101.0.199 > 192.168.185.120: ICMP echo request, id 51263, seq 36, length 64 17:48:47.938595 IP
192.168.185.120 > 10.101.0.199: ICMP echo reply, id 51263, seq 36, length 64

But on the London host we don't see these replies.


On the ASA it indicates that it is encrypting outbound packets but not inbound:

LON-NET-FW01(config)# show cry ipsec sa peer 2x.1x.2x.13x
peer address: 2x.1x.2x.13x
    Crypto map tag: crypto-outside, seq num: 5, local addr: 8x.1x.4x.9x

      access-list TUN-LONGS-TORQQ extended permit ip 10.101.0.0 255.255.255.0 192.168.185.0 255.255.255.0
      local ident (addr/mask/prot/port): (10.101.0.0/255.255.255.0/0/0)
      remote ident (addr/mask/prot/port): (192.168.185.0/255.255.255.0/0/0)

      #pkts encaps: 1072, #pkts encrypt: 1072, #pkts digest: 1072
      #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 1072, #pkts comp failed: 0, #pkts decomp failed: 0

===snip=== (both networks are listed but only one shown here for length)

Some bits of the config:

object-group network DHX-QQ-NETWORKS
 network-object 10.180.0.0 255.255.252.0
 network-object 192.168.185.0 255.255.255.0


LON-NET-FW01(config)# show run nat | inc QQ
nat (inside,outside) source static LONGS-101NET LONGS-101NET destination static DHX-QQ-NETWORKS DHX-QQ-NETWORKS route-lookup

show nat:

10 (inside) to (outside) source static LONGS-101NET LONGS-101NET  destination static DHX-QQ-NETWORKS DHX-QQ-NETWORKS route-lookup
    translate_hits = 410, untranslate_hits = 410

run-access-list:

access-list TUN-LONGS-TORQQ remark Tunnel to TOR Service and Desktop networks
access-list TUN-LONGS-TORQQ extended permit ip object-group LONGS-101NET object-group DHX-QQ-NETWORKS

LON-NET-FW01(config)# show access-list TUN-LONGS-TORQQ
access-list TUN-LONGS-TORQQ; 2 elements; name hash: 0xfa13240a
access-list TUN-LONGS-TORQQ line 1 remark VPN to TOR SRV and Desktop networks
access-list TUN-LONGS-TORQQ line 2 extended permit ip object-group LONGS-101NET object-group DHX-QQ-NETWORKS (hitcnt=7) 0x8d68f010
  access-list TUN-LONGS-TORQQ line 2 extended permit ip 10.101.0.0 255.255.255.0 10.180.0.0 255.255.252.0 (hitcnt=3) 0x4a18a364
  access-list TUN-LONGS-TORQQ line 2 extended permit ip 10.101.0.0 255.255.255.0 192.168.185.0 255.255.255.0 (hitcnt=15) 0xd9e13e75




crytomap:
crypto map crypto-outside 5 match address TUN-LONGS-TORQQ
crypto map crypto-outside 5 set pfs
crypto map crypto-outside 5 set peer 2x.1x.2x.1x
crypto map crypto-outside 5 set ikev1 transform-set ESP-3DES-SHA
crypto map crypto-outside 5 set reverse-route


LON-NET-FW01(config)# show run tunnel-group 2x.1x.2x.1x
tunnel-group 2x.1x.2x.1x type ipsec-l2l
tunnel-group 2x.1x.2x.1x ipec-attributes
  ikev1 pre-shared-key *********



Routing table:

LON-NET-FW01(config)# show route

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, + - replicated route
Gateway of last resort is 8x.1x.4x.8x to network 0.0.0.0

S*       0.0.0.0 0.0.0.0 [1/0] via 8x.1x.4x.8x, outside
D EX     10.3.0.0 255.255.0.0
           [170/25605376] via 172.16.101.2, 02:15:21, transit
S        10.3.2.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
S        10.10.10.0 255.255.255.0 [1/0] via 10.101.0.2, inside
C        10.45.16.0 255.255.255.0 is directly connected, lync_dmz
L        10.45.16.1 255.255.255.255 is directly connected, lync_dmz
C        10.101.0.0 255.255.255.0 is directly connected, inside
L        10.101.0.1 255.255.255.255 is directly connected, inside
S        10.112.0.0 255.240.0.0 [250/0] via 8x.1x.4x.8x, outside
D        10.112.0.0 255.255.255.0
           [90/25608448] via 172.16.101.2, 02:15:22, transit
D EX     10.113.0.0 255.255.255.0
           [170/25603072] via 172.16.101.2, 02:15:21, transit
D EX     10.114.0.0 255.255.255.0
           [170/25605376] via 172.16.101.2, 02:15:21, transit
D EX     10.115.0.0 255.255.255.0
           [170/25605376] via 172.16.101.2, 02:15:22, transit
D EX     10.116.0.0 255.255.255.0
           [170/25605376] via 172.16.101.2, 02:15:22, transit
D EX     10.117.0.0 255.255.255.0
           [170/25603072] via 172.16.101.2, 02:15:22, transit
S        10.118.0.0 255.255.0.0 [1/0] via 8x.1x.4x.8x, outside
S        10.118.0.0 255.255.255.0 [250/0] via 8x.1x.4x.8x, outside
S        10.180.0.0 255.255.252.0 [1/0] via 8x.1x.4x.8x, outside
S        10.230.4.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
S        10.255.255.1 255.255.255.255 [1/0] via 8x.1x.4x.8x, outside
C        85.133.42.88 255.255.255.248 is directly connected, outside
L        85.133.42.92 255.255.255.255 is directly connected, outside
S        172.16.5.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
D EX     172.16.11.0 255.255.255.0
           [170/25602816] via 172.16.101.2, 02:15:24, transit
D EX     172.16.12.0 255.255.255.0
           [170/25613056] via 172.16.101.2, 02:15:23, transit
D        172.16.21.0 255.255.255.0
           [90/25607936] via 172.16.101.2, 02:15:24, transit
C        172.16.101.0 255.255.255.128 is directly connected, transit
L        172.16.101.1 255.255.255.255 is directly connected, transit
C        172.16.101.128 255.255.255.128 is directly connected, dmz
L        172.16.101.129 255.255.255.255 is directly connected, dmz
D        172.16.112.0 255.255.255.128
           [90/25608192] via 172.16.101.2, 02:15:23, transit
S        172.16.118.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
D        172.19.101.1 255.255.255.255
           [90/130816] via 172.16.101.2, 02:15:24, transit
D        172.19.112.1 255.255.255.255
           [90/25735936] via 172.16.101.2, 02:15:23, transit
D EX     172.19.113.1 255.255.255.255
           [170/25730816] via 172.16.101.2, 02:15:22, transit
D EX     172.19.114.1 255.255.255.255
           [170/25730816] via 172.16.101.2, 02:15:22, transit
D EX     172.19.115.1 255.255.255.255
           [170/25730816] via 172.16.101.2, 02:15:22, transit
D EX     172.19.116.1 255.255.255.255
           [170/25730816] via 172.16.101.2, 02:15:22, transit
D EX     172.19.117.1 255.255.255.255
           [170/25730816] via 172.16.101.2, 02:15:22, transit
S        192.168.2.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
D EX     192.168.5.0 255.255.255.0
           [170/25603072] via 172.16.101.2, 02:15:22, transit
D EX     192.168.7.0 255.255.255.0
           [170/25605376] via 172.16.101.2, 02:15:22, transit
D EX     192.168.9.0 255.255.255.0
           [170/25605376] via 172.16.101.2, 02:15:22, transit
S        192.168.130.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
S        192.168.170.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside
S        192.168.185.0 255.255.255.0 [1/0] via 8x.1x.4x.8x, outside

I have configured 5 or 6 other tunnels on this device,  most to foritnet devices, and they all work as expected:


LON-NET-FW01(config)# show cry ipsec sa | inc access-list
      access-list TUN-LONQCS-LONGS extended permit ip 10.101.0.0 255.255.0.0 10.118.0.0 255.255.0.0
      access-list TUN-LONDON-LOSANGELES extended permit ip 10.101.0.0 255.255.255.0 172.16.5.0 255.255.255.0
      access-list TUN-LONDON-LOSANGELES-CoreNet extended permit ip 10.101.0.0 255.255.255.0 192.168.130.0 255.255.255.0
      access-list TUN-LONDON-VAN01 extended permit ip 10.101.0.0 255.255.255.0 192.168.170.0 255.255.255.0
      access-list TUN-LONGS-TORQQ extended permit ip 10.101.0.0 255.255.255.0 192.168.185.0 255.255.255.0
      access-list TUN-LONGS-TORQQ extended permit ip 10.101.0.0 255.255.255.0 10.180.0.0 255.255.252.0
      access-list TUN-LONGS-LON extended permit ip 10.101.0.0 255.255.0.0 10.112.0.0 255.255.0.0

This could be a routing issue. Does Toronto know how to route to London? — Ron Trunk, Commented Aug 25, 2016 at 1:00
It's probably an access list issue. The ACL's specify what traffic (subnets) is tunneled/encrypted. — Ronnie Smith, Commented Aug 25, 2016 at 2:53
If I put a do a capture on the VPN interface to London I see the packets egressing : do you mean you see IPsec packets from 2x.1x.2x.13x to 8x.1x.4x.9x ? And if you capture on the ASA on its outside interface (with an acl filtering the capture to traffic from the peer) do you see IPsec packets from 2x.1x.2x.13x to 8x.1x.4x.9x ? — hertitu, Commented Aug 25, 2016 at 5:54
BTW I don't think this is related to the problem but in your other tunnel's config you sometimes have 10.101.0.0/16 instead of /24. As long as the relevant peer has the same in its config (but reversed) then that's ok of course. — hertitu, Commented Aug 25, 2016 at 5:55
Do you still need help with this or did you solve it? If you did then please add an answer so others may learn from it. — hertitu, Commented Sep 6, 2016 at 14:48

josh13564 · Accepted Answer · 2016-08-26 03:00:39Z

I would say the London side of the tunnel is fine because it is encrypting packets. However, the ASA may be set to not bypass interface ACLs for VPN traffic. You will know this if no sysopt connection permit-vpn is specified in the running configuration. You can fix this by either negating this command or allowing the vpn traffic though the inbound ACL on the outside interface.

Since the firewalls are different vendors it makes things a little more complicated. I would suspect that the traffic from the Fortigate destined for London is being NAT'd to the outside interface or the phase 2 ACL doesn't match 100% between sites. If you you are getting recv errors on the phase 2 ipsec sa then this may be the case.

I don't have much experience with Fortigates but I did some research and your policies should look something like this.

config vpn ipsec phase1

edit “asa”
        set interface "?"
        set ?
        set proposal ?
        set remote-gw x.x.x.x
        set psksecret ENC *******
    next
config vpn ipsec phase2
    edit “asa 191.168.185.0/24"
        set phase1name “asa”
        set proposal 3des-md5
        set dhgrp 2
        set dst-subnet 10.101.0.0 255.255.255.0
        set keylifeseconds ?
        set src-subnet 192.168.185.0 255.255.255.0
    next
    edit “asa 10.180.0.0/24"
        set phase1name “asa”
        set proposal 3des-md5
        set dhgrp 2
        set dst-subnet 10.101.0.0 255.255.255.0
        set keylifeseconds ?
        set src-subnet 10.180.0.0 255.255.255.0

In the firewall policies for the tunnel, make sure set natoutbound enable is not in the configuration. Otherwise it will NAT the VPN traffic.

Josh

PatStat · Accepted Answer · 2017-12-21 15:22:16Z

-1

Had a similar issue once with the same two vendors firewalls.

It ended up being a PFS default mismatch. The default on the ASA (mine, group 2)did not match that on the Fortigate, if I remember correctly.

answered Dec 21, 2017 at 15:22

PatStat

11 bronze badge

Add a comment |

Stack Exchange Network

Packets are not being de-capsulated on the ASA end of a VPN

2 Answers 2

Your Answer

Not the answer you're looking for? Browse other questions tagged
cisco
cisco-asa
vpn
or ask your own question.

Hot Network Questions

Packets are not being de-capsulated on the ASA end of a VPN

2 Answers 2

Your Answer

Sign up or log in

Post as a guest

Not the answer you're looking for? Browse other questions tagged ciscocisco-asavpn or ask your own question.

Related

Hot Network Questions

Not the answer you're looking for? Browse other questions tagged
cisco
cisco-asa
vpn
or ask your own question.