ASA: S2S tunnel is working just unidirectional - most likely caused by drop because ipsec-spoof

[swscco001]

Hello everybody,

today I want to collect some ideas for a problem with a ASA5515 running OS 9.12(4).

I build a normal IPSec S2S tunnel to a Sophos firewall and the tunnel was indicated as UP

in the ASDM logging.

Unfortunately the ASA is just receiving/decrypting ICMP packets but not sending encrypted

packets. (Rx counter is increasing, Tx counter is 0)

Because the configuration contains:

no sysopt connection permit-vpn

I found error messages for hitting the inbound ACL for the outside interface.

I added the permit statement for all ICMP types in the inbound ACL for the outside

interface and now no error messages appear in the logging anymore.

I used the PacketTracer to send a ICMP test packet:

packet-tracer input outside icmp 10.87.27.46 8 0  192.168.20.128 xml

and I got green marks for all but the packet was dropped at the end because ipsec-spoof

(see attached screen dump).

What can I do/check/test to remove this?

Any idea is very welcome!

Thanks a lot in advance!



Bye

R.

[Karsten Iwen]

Packet-tracer simulates how a packet enters the input interface. And with VPN, the encrypted packet has to enter and not the decrypted one. You can simulate the correct behavior on the CLI with the "decrypted" keyword:

packet-tracer input outside icmp 10.87.27.46 8 0  192.168.20.128 decrypted

[Sheraz.Salim]

Unfortunately the ASA is just receiving/decrypting ICMP packets but not sending encrypted

this could be a routing issue in your network. ASA received the packet from the remote side but its not sending encap to remote side. also make sure the interesting traffic is mirror on both side.

[Richard Burts]

I have experienced the symptom of ASA receiving encrypted traffic but not sending encrypted traffic. Sometimes it has turned out to be an issue with address translation and sometimes it has turned out to be an issue with routing. If you check those parts of your config and do not find an issue perhaps you could post the output of show crypto ipsec sa, and a sanitized copy of the config?

[swscco001]

Hi Richard,

thanks for the hints!

I added the output of the 'show crypto ipsec sa' and a sanitized copy of the config

to this discussion.

I don't find a mistake in the tunnel configuration and the reason why the decrypted
packets are not forwarded to the target host.

What can I still check?

Thanks a lot!



Bye
Rene

[swscco001]

Hello everybody,

thanks for your hints!!!

Unfortunately they did not leead me to the solution of the issue.

Usually a Site-to-Site tunnel does not cause such trouble.

What I did now:

1. I checked the routing between the ASA and the local target hosts:
I can ping the local target hosts from the ASA and when they
ping the remote host I see the ICMP requests arriving in the trace.

2. I checkked the NAT exemption:
The IP addresses are correct and I moved the entry up in the priority to 1.

3. Even if the ACLs for inbound traffic to the inside & outside interface contain
no DENY statement I moved the ACL entry for PERMIT the ICMP traffic between
the IP addresses to the first place.

4. I turned of the VPN filter.

The 'show crypto ipsec sa' is attached and show decrypted packet but no encrypted.

The admin at the peer (company Prisma) site started a permanent ping from IP
10.87.27.46 ---> 192.168.20.128
so there is traffic for troubleshooting.

It looks like the ASA decrypted the packets and drop the encrypted packet by any reason.

The crypto-ACL shows hitcounts because yesterway we had a permanent ping from the local site
to the remote host:

fw-gk# sh access-list outside_cryptomap_2
access-list outside_cryptomap_2; 4 elements; name hash: 0x4e1c27f3
access-list outside_cryptomap_2 line 1 extended permit ip object-group Hosts4Prisma_Informatik object Prisma_Informatik-NW (hitcnt=711) 0xe3c95511
access-list outside_cryptomap_2 line 1 extended permit ip host 192.168.20.130 10.87.27.0 255.255.255.0 (hitcnt=708) 0xb9a12ad1
access-list outside_cryptomap_2 line 1 extended permit ip host 192.168.20.128 10.87.27.0 255.255.255.0 (hitcnt=639) 0x99eb7022
access-list outside_cryptomap_2 line 1 extended permit ip host 192.168.20.131 10.87.27.0 255.255.255.0 (hitcnt=708) 0x6db88b8e
access-list outside_cryptomap_2 line 1 extended permit ip host 192.168.20.132 10.87.27.0 255.255.255.0 (hitcnt=705) 0xecb02dbe

Attached there is a sanitizes configuration of the ASA. It is prerry long so I colored the
lines red those I conside as relevant.

I don't have ideas anymore.

Perhaps you have.

Every hint is welcome!!!

[swscco001]

Hello everybody,

because I did not find a mistake in the ASA configuration I asked the admin

of the Sophos at the other site to re-initiate the tunnel and suddenly the

tunnel worked bidirectional. Don't ask me why.

Thanks for your help!

Bye

R.

[Richard Burts · Accepted solution]

Rene

Thanks for the update. Glad to know that now the tunnel is working ok in both directions. Too bad we do not know what the issue was. But the main thing is that now it is working.