ipsec-tunnel-flow DROP

[spencerallsop]

Hi there

I'm trying to use a VPN connection that's been working on an ASA for months on ASA9.1(2). I've upgraded to ASA9.1(6)11 and it's stopped working.

These are remote ASA5505s making an IPSEC-RA connection to a headend 5520. I can roll back and forward from 9.1(2) and 9.1(6)11 and whilst the configuration doesn't change, the VPN starts working on 9.1(2)

The vpn connects, but there are no packets sent or received..

I get this from packet tracer...

Result of the command: "packet-tracer input teeessyou tcp 192.168.190.2 5000 192.168.195.1 80 detail"

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xae1308e8, priority=1, domain=permit, deny=false
    hits=622, user_data=0x0, cs_id=0x0, l3_type=0x8
    src mac=0000.0000.0000, mask=0000.0000.0000
    dst mac=0000.0000.0000, mask=0100.0000.0000
    input_ifc=teeessyou, output_ifc=any

Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (teeessyou,outside) source static any any destination static teeessyou_ENCODERS teeessyou_ENCODERS
Additional Information:
NAT divert to egress interface outside
Untranslate 192.168.195.1/80 to 192.168.195.1/80

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group teeessyou_access_in in interface teeessyou
access-list teeessyou_access_in extended permit ip any any
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xae24d310, priority=13, domain=permit, deny=false
    hits=622, user_data=0xab6b23c0, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
    dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
    input_ifc=teeessyou, output_ifc=any

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (teeessyou,outside) source static any any destination static teeessyou_ENCODERS teeessyou_ENCODERS
Additional Information:
Static translate 192.168.190.2/5000 to 192.168.190.2/5000
 Forward Flow based lookup yields rule:
 in  id=0xae1ea5a8, priority=6, domain=nat, deny=false
    hits=622, user_data=0xae1e9c58, cs_id=0x0, flags=0x0, protocol=0
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
    dst ip/id=192.168.192.0, mask=255.255.224.0, port=0, tag=0, dscp=0x0
    input_ifc=teeessyou, output_ifc=outside

Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xa9678858, priority=1, domain=nat-per-session, deny=true
    hits=105, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
    dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
    input_ifc=any, output_ifc=any

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0xae136910, priority=0, domain=inspect-ip-options, deny=true
    hits=622, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
    dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
    input_ifc=teeessyou, output_ifc=any

Phase: 7
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0xaeec4328, priority=70, domain=encrypt, deny=false
    hits=65, user_data=0xb7dc, cs_id=0x0, reverse, flags=0x0, protocol=0
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
    dst ip/id=192.168.195.0, mask=255.255.255.0, port=0, tag=0, dscp=0x0
    input_ifc=any, output_ifc=outside

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (teeessyou,outside) source static any any destination static teeessyou_ENCODERS teeessyou_ENCODERS
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0xae1eae48, priority=6, domain=nat-reverse, deny=false
    hits=129, user_data=0xae1e9d10, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
    src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
    dst ip/id=192.168.192.0, mask=255.255.224.0, port=0, tag=0, dscp=0x0
    input_ifc=teeessyou, output_ifc=outside

Phase: 9
Type: VPN
Subtype: ipsec-tunnel-flow
Result: DROP
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 in  id=0xaea9f6b0, priority=69, domain=ipsec-tunnel-flow, deny=false
    hits=129, user_data=0x0, cs_id=0xaea999c0, reverse, flags=0x0, protocol=0
    src ip/id=192.168.192.0, mask=255.255.224.0, port=0, tag=0
    dst ip/id=192.168.190.0, mask=255.255.255.0, port=0, tag=0, dscp=0x0
    input_ifc=outside, output_ifc=any

[Philip D'Ath]

Try jumping to something a bit more modern like 9.2(4).  You could also try upgrading the remote ends, but this should not usually be needed.

[spencerallsop]

I'd love to, but I'm limited to my 5520, therefore at 9.1(x). 9.2+ isn't supported on this platform

[Philip D'Ath]

Bummer.  I see there is a 9.1(7) interim release available.

[David Castro F. · Accepted solution]

Hello Spencerallsop,

I would recommend you to add the "no-proxy-arp" keyword at the end of NAT statement, so the ASA won't try to respond ARP requests for the destination traffic(VPN interesting traffic), also this last phase 9 usually shows dropped due to a VPN filter defined in a group policy sometimes, make sure you dont have a VPN filter in a group policy affecting this tunnel, so you will need to do the following:

1. Remove the NAT statement:

   - no nat (teeessyou,outside) source static any any destination static teeessyou_ENCODERS teeessyou_ENCODERS

2. Correct the NAT statement with the "no-proxy-arp" keyword:

  -  nat (teeessyou,outside) source static any any destination static teeessyou_ENCODERS teeessyou_ENCODERS no-proxy-arp

3. Clear the VPN ISA SA:

   - clear crypto ikev1 sa <Peer IP address>

4. Run the packet tracer to verify the L2L has come up,

To be honest I would not recommend you to move to 9.1.7, since it has some issues with ARP entries, and it affects AnyConnect SSL somehow, which still is under investigation, 

Actually this bug affects 9.1.7 (may affect your environment):

- https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuy28710

Please dont forget to rate and mark as correct this post, keep me posted!

Regards,

David Castro,

[spencerallsop]

I think the take away message here is keep away from 9.1.7. I've rolled back to a previous version, as mentioned before, and everything works. I've even dropped back to a patched version from the 9.0 releases, and the ASAs just don't connect. 

I suspect that the 'fix' for the IKE vulnerability has actually broken some other stuff, apart from the ARP bug that we've seen.

I've reported to TAC through my vendor support - and interestingly, this was a known issue, but no workaround or fix was offered.

We sit and wait.