IPSEC no Pkts out on Cisco ASA

[juliocvanti]

Hi all, please i need a Help.

I have a IPSEC tunnel with my Cisco ASA and a Peer PFsense, VPN is UP include phase 2.

But i could not send pkts on this VPN.

My internal Network - 10.2.0.0/17, client network 172.31.2.2/32

==========================

FW--VPN-01# sho ipsec sa peer 177.154.83.34
peer address: 177.154.83.34
    Crypto map tag: outside_map0, seq num: 4, local addr: 200.243.146.20

      access-list outside_cryptomap_8 extended permit ip 10.2.0.0 255.255.128.0 host 172.31.2.2
      local ident (addr/mask/prot/port): (10.2.0.0/255.255.128.0/0/0)
      remote ident (addr/mask/prot/port): (172.31.2.2/255.255.255.255/0/0)
      current_peer: 177.154.83.34

      #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
      #pkts decaps: 2957, #pkts decrypt: 2957, #pkts verify: 2957
      #pkts compressed: 0, #pkts decompressed: 0
      #pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
      #pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
      #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
      #send errors: 0, #recv errors: 1

      local crypto endpt.: 200.243.146.20/0, remote crypto endpt.: 177.154.83.34/0
      path mtu 1500, ipsec overhead 74, media mtu 1500
      current outbound spi: C1A13463
      current inbound spi : 5B6B0EAB

    inbound esp sas:
      spi: 0x5B6B0EAB (1533742763)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, }
         slot: 0, conn_id: 9179136, crypto-map: outside_map0
         sa timing: remaining key lifetime (sec): 858
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0xFFFFFFFF 0xFFFFFFFF
    outbound esp sas:
      spi: 0xC1A13463 (3248567395)
         transform: esp-aes-256 esp-sha-hmac no compression
         in use settings ={L2L, Tunnel, PFS Group 2, }
         slot: 0, conn_id: 9179136, crypto-map: outside_map0
         sa timing: remaining key lifetime (sec): 858
         IV size: 16 bytes
         replay detection support: Y
         Anti replay bitmap:
          0x00000000 0x00000001

===========================

FW-VPN-01# packet-tracer input outside icmp 10.2.110.10 1 0 172.31.2.2

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

===============================

FW-VPN-01# sho running-config | inc 177.154.83.34
crypto map outside_map0 4 set peer 177.154.83.34
group-policy GroupPolicy_177.154.83.34 internal
group-policy GroupPolicy_177.154.83.34 attributes
tunnel-group 177.154.83.34 type ipsec-l2l
tunnel-group 177.154.83.34 general-attributes
 default-group-policy GroupPolicy_177.154.83.34
tunnel-group 177.154.83.34 ipsec-attributes

==============================

FW-VPN-01# sho running-config | inc 172.31.2.2
object network 172.31.2.2_32
 host 172.31.2.2
access-list nonat extended permit ip 10.2.0.0 255.255.128.0 host 172.31.2.2
access-list inside_access_in extended permit ip 10.2.0.0 255.255.128.0 object 172.31.2.2_32
access-list outside_cryptomap_5 extended permit ip object 10.2.0.0_17 object 172.31.2.2_32
access-list outside_cryptomap_8 extended permit ip object 10.2.0.0_17 object 172.31.2.2_32
nat (inside,any) source static 10.2.0.0_17 10.2.0.0_17 destination static 172.31.2.2_32 172.31.2.2_32 no-proxy-arp route-lookup

[pjain2]

since you have no encaps on the ASA's end, it means that the ASA is not sending the reply traffic back.

apply the following captures:

capture cap interface inside match ip host <ip in 10.2.0.0 subnet> host 172.31.2.2

capture asp type asp all

initiate traffic from the remote end to one of the host on your internal subnet and check if you see the traffic going out from the inside interface towards the host and the reply coming back; if the traffic is dropped by the ASA, you will see the traffic in the ASP captures.

if the return traffic from the host is not coming back, make sure you have a route for 172.31.2.2 host in your internal network pointing the traffic back to the ASA.

[juliocvanti]

I see the packets in.

 298: 13:58:03.678416 172.31.2.2 > 10.2.1.46: icmp: echo request
 299: 13:58:04.678324 172.31.2.2 > 10.2.1.46: icmp: echo request
 300: 13:58:05.679194 172.31.2.2 > 10.2.1.46: icmp: echo request
 301: 13:58:06.677897 172.31.2.2 > 10.2.1.46: icmp: echo request
 302: 13:58:07.678340 172.31.2.2 > 10.2.1.46: icmp: echo request
 303: 13:58:08.679576 172.31.2.2 > 10.2.1.46: icmp: echo request
 304: 13:58:09.681315 172.31.2.2 > 10.2.1.46: icmp: echo request

But, why when i test from ASA with Packet-tracer we get a drop ?

[pjain2 · Accepted solution]

so you see the packets going in through your inside interface but no reply coming  back; please check if you have a route for 172.31.2.2 host in your internal network pointing the traffic back to the ASA.

the packet tracer shows drop because you are running it from out-to-in and in that case you have to specifically allow that traffic on the outside interface acl. when the actual traffic comes in through vpn, it checks for sysopt and then the interface access-list is bypassed. but when you do a packet tracer, that simulated packet is not actually coming from vpn and hence we need to allow that in outside interface acl for packet tarcer to allow it.

[juliocvanti]

Pjain2, you are right.

Please, what rules do you mean i must have on my interface inside and outside to permit this back traffic ? Asa is not statefull connection ?

Tks by help.

Julio

[Jon Marshall]

Julio

That's not what he is saying.

The ASA is stateful and the traffic will be allowed back out to the remote end of the VPN tunnel.

But the test you ran with packet tracer was not through a VPN tunnel so it does not represent what happens with the VPN traffic.

You don't need any acls etc.

The issue seems to be the traffic is leaving the inside interface of your ASA but it is not coming back.

So what is the default gateway of 10.2.1.46 ?

If it is not the ASA then whatever device it is does it have a route for 172.31.2.2 pointing to the ASA ?

Jon

[juliocvanti]

Pjain2 was correctly.

no problem on Asa, the problem was a Bad GW on the way, so traffic no got back.

Tks a lot by help.

Julio