IPSec Site-to-Site ASA TUNNEL OK but no Byte RX and PHASE VPN DROP

[miky_506]

Hello everyone,

I have an urgent problem with a site-to-site VPN configuration. The channel is UP, phase 1 (IKEV1) and phase 2 (Ipsec) are OK, I can see the connection with Cisco ASDM in the Monitoring section but unfortunately, doing an IP packet tracer I get DROP in the VPN phase, although the tunnel is activated correctly.

Making a telnet to the destination internal IP does not succeed, but I see the TX bytes increases, but those RX remain at 0.

Please can you help me? what is missing? I have a Cisco ASA V.9.5 (ASA 5506)

My sh crypto isakmp sa:

fw-plabs(config)# show crypto isakmp sa

IKEv1 SAs:

Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1 IKE Peer: 62.97.2.6
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE

There are no IKEv2 SAs

MY SH CRYPTO IPSEC SA

fw-plabs(config)# show crypto ipsec sa
interface: outside
Crypto map tag: outside_map, seq num: 1, local addr: 88.63.105.66

access-list outside_cryptomap_2 extended permit ip 172.16.45.0 255.255.255 .0 10.209.21.0 255.255.255.0
local ident (addr/mask/prot/port): (172.16.45.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.209.21.0/255.255.255.0/0/0)
current_peer: 62.97.2.6

#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 5, #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
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: 88.63.105.66/0, remote crypto endpt.: 62.97.2.6/0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: CD487401
current inbound spi : 98EF46B9

inbound esp sas:
spi: 0x98EF46B9 (2565818041)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 352256, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (4374000/27745)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0xCD487401 (3444077569)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 352256, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (4373999/27745)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

thanks a lot.

Regards

Miky_506

[Marvin Rhoads]

Rx bytes / packet decaps remaining at zero despite successful Phase 1 and Phase 2 negotiation is most commonly one of two things - both at the distant end:

1. Lack of NAT exemption for the encapsulated traffic

2. Incorrect routing such that the return traffic doesn't come back via the VPN device.

Can you check those?

[miky_506]

Thanks Marvin for the post and for the fast response,

I configured the vpn site-to-site with the wizard that Cisco ASDM provides, and I remember to have selected the NAT EXEMPT check for the INSIDE interface.

For routing in the running-configuration, there's an instruction like "route outside 0.0.0.0 0.0.0.0 88.63.105.66" already set up, which is our corporate public IP with which we interface on the Internet. Do I have to add another "route outside" statement?

If you need i can post the running-configuration of the CISCO ASA.

Thank you very much for your help, I'm not an expert but I'm a beginner.

Miky_506

[Marvin Rhoads]

You're welcome.

Is the distant end and ASA also? I suspect the error may be there.

[miky_506]

Sorry what do you mean for "distant end end ASA" ?

The receiver on the other side says not to see traffic arrive, although the VPN channel is correctly active, in fact he has assured me that with a Telnet command on destination internal IP on the predetermined tcp port it should be successful. Probably the DROP VPN phase is telling me that the channel is ok, the traffic is sent but doesn't know where to go as a destination.

If that, how could I solve it? which instruction would correct the problem? By receiver side the configuration is okay, until the traffic doesn't arrive I think the problem is mine.

I copy here the packet tracer:

packet-tracer input inside tcp 172.16.45.109 11000 10.209.21$

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 88.63.105.65 using egress ifc outside

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,outside) source static network_plab network_plab destination static network_sgs network_sgs no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface outside
Untranslate 10.209.21.242/11000 to 10.209.21.242/11000

Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside,outside) source static network_plab network_plab destination static network_sgs network_sgs no-proxy-arp route-lookup
Additional Information:
Static translate 172.16.45.109/11000 to 172.16.45.109/11000

Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:

Result:
input-interface: inside
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

Thanks a lot.

Miky_506

[Marvin Rhoads]

Your route statement "route outside 0.0.0.0 0.0.0.0 88.63.105.66" should point to the next hop, not to the ASA outside address. But I'm assuming you either mis-typed that or have since fixed it as your packet-tracer shows the ASA knows the next hop is 88.63.105.65.

What is the peer (62.97.2.6) device? Can you share the relevant configuration from it?

I ask because the Phase 7 VPN result DROP often occurs when the distant end does not have an ACL in their crypto map (or equivalent configuration for non-Cisco devices) that is not a mirror image of yours.

https://www.petenetlive.com/KB/Article/0001198

[miky_506]

Thanks for the response.

Initially they asked me to natting my private network with an IP address provided by them, for their company policies, and then construct the VPN site-to-site between this IP Address and their network.

I have failed to make this transition, and I have established the VPN from my internal network (with public peer 88.63.105.66) with their internal network (their public peer for the VPN connection is 62.97.2.6)

Although I've skipped this step, they have assured me that it is possible to reach them even without natting my internal network with their IP address, but they still have to see some traffic coming by my way.

Maybe I have to do this step instead! How can I nat my internal network to another IP address? for example my network internal is 10.2.1.0 and the IP Address is 10.200.100.102, what's the correct rule to write into ASA?

If you don't understand, tell me, i will explain more detailed!

Thanks a lot

Miky_506

[Marvin Rhoads]

If you need to change your source address to something specified by the remote end then your would need to modify your NAT statement. You currently have:

nat (inside,outside) source static network_plab network_plab destination static network_sgs network_sgs no-proxy-arp route-lookup

The second "network_plab" value would need to be changed to reference a new object that you create with the designated source address they are expecting.

Again, I cannot stress enough that both ends of the VPN must have complimentary configurations. If any one value is incorrect at their end the overall VPN functionality will fail.