Site to Site Tunnel - Traffic just flowing in one direction.

[daniel.gomez]

Greetings to everyone,

I have configured an IPSec (Site-to-Site) tunnel between an ASA5510 and a Linux Sytem connection a Network A with a Network B in the following way:

* Diagram:

                                                           #---------------IPSec-----------------#

private network (A) ---- Linux Router (GW1) -------- WAN -------- (GW2) ASA5510 ---- public network (B)

* Results:

I have checked the IPSec Tunnel on the linux Router and both Phase 1 and Phase 2 are UP. ASDM shows also an IPSec connection with the correct parameters (GW, Local Network, Left Network etc.).

If I have correctly understand it "show crypto iskmp sa", "show crypto ikev1 sa" and  "show crypto ipsec sa"  show also that the connection is correct and UP.

*Now comes the interesting thing:

If I ping from Network A to Network B, the icmp echo request go thorugh the tunnel and I can see the Rx bytes on the cisco ASA going UP.

If I ping from Network B to Network A, I do not see any Tx Bytes on the Tunnel. The Linux router does not also see any packets going through the tunnel.

When I ping from Network B to Network A, the Firewall Logs ICMP Denies. That means that the traffic from B to A, I do not know why, is not matching the corresponding Tunnel ACL, the icmp packets are being routed to the default gateway instead through the tunnel and they are then matching a less specific droping rule on the main firewall. 

*Configurations:

I have specially configured a Crypto Map that matches the Networks in Both directions.

There exists an ACL that permits the traffic in both directions.

There exist a NAT rules that permits traffic between both networks without being NATed, in order for both networks to transmit through the tunnels freely.

* Ideas ?

crypto map?

NAT?

ACL?

interface level security?

Thanks in advance.

[rkumar5 · Accepted solution]

Hi Gomez,

Please try the packet tracer command

Pac in in icmp 8 0 detailed

the output of this command would show where is the packet getting dropped

Please send the output of the above command

HTH!!

Regards

Raj Kumar

[daniel.gomez]

Hi Guys,

Thank you all for your help. The packet was being dropped on the "implicit rule", that means that the packet was not finding an ACL to match.

I checked the ACLs that the VPN Wizard generates by itself when used to configure an IPSec connection, and the ACLs where correct and "before" the implicit rule . (They are called by default outside_cryptomap_"number")

It seems that since I am not using "sysopt connection permit-vpn" I have to add the same ACLs to the "Local Network" interface (VPN_LAN).

Since there was inbound ACLs related to the VPN_LAN interface, the firewall jumped directly to the "implicit rule".

So the result is that I have two times the same rules first inbound on the VPN_LAN and second on the default outside_cryptomap ACLs.

Greetings,

Daniel

[Rudy Sanjoko]

Hi,

You are saying that the echo requests from the linux go through the tunnel, but what about the echo replies from the ASA? It looks to me that the icmp is not allowed to pass on the ASA. You can enable it by adding inspect icmp command on the global service policy. This is if you haven't done it yet.

If ASA not allowing icmp is not the case, then please follow Raj's instruction to troubleshoot the issue further.

HTH,

[daniel.gomez]

Hi Rudy,

I have not configured the inspect icmp on the "global service policy", I thought this command is just usefull for non-vpn connections.

Do the individual vpn-policies inherit from the "global service policy"?

That would be a good explanation to why some reply-packets are being dropped just for some vpn-connections and for other not.

Greetings,

Daniel

[Rudy Sanjoko]

Hi Daniel,

If you configure sysopt, the vpn traffic will only bypass the interface acl where the vpn is terminated. The gsp is still applied to that vpn traffic. By default if you don't specify the vpn policy, it will inherit them from the default group policy. This policy is the one that you normally see as "DfltGrpPolicy" inside the ASA.

That would be a good explanation to why some reply-packets are being dropped just for some vpn-connections and for other not.

Having that said, regarding your above statement I would check your access-list configuration, cryptomap and icmp permit/deny command to understand more on above matter. Because I believe it shouldn't just dropping packets for some vpn and for other not.

HTH,

[Artem Tkachov]

Hi Gomes,

I have 2 comments here:

1. What is the version on ASA. Since, version pre 8.3 and post 8.3 are slightly different in packet processing.

2. Good point from Raj, you can check you packet processing steps with packet-tracer and understand why your icmp is denied.

So, please share with us outputs from packet-tracer as well as from "sh ver".

Thank you.

[shine pothen]

Please try to run the packet capture  and paste the output as Raj said .

this will give us clear understanding where the packet is dropping or not allowed.

"packet-tracer input inside icmp Network A any host ip 8 0 Network B any host"

Potha

[daniel.gomez]

In short:

Configuring IPsec or SSL VPN to Bypass ACLs

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/vpnsysop.html