cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
571
Views
0
Helpful
2
Replies

S2S VPN Issue

Mokhalil82
Level 4
Level 4

Hi 

I have a site to site VPN with a customer. We have a ASA5585 on our end but they have a non-cisco router. The VPN itself is up. But when I send traffic, the encrypts increment but the decrypts do not. Is it most likely an issue on the other end as I cannot see any issues on my side. Is there anything else I could check. They have confirmed they have no access rules blocking the traffic etc

Here is the output for the crypto

FW1/sec/act# sh crypto ipsec sa peer xx.xx.xx.xx
peer address: xx.xx.xx.xx
Crypto map tag: outside_map, seq num: 27, local addr: xx.xx.xx.xx

access-list THEIR_VPN extended permit ip 10.152.18.0 255.255.255.0 10.170.43.0 255.255.255.0
local ident (addr/mask/prot/port): (10.152.18.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.170.43.0/255.255.255.0/0/0)
current_peer: XX.XX.XX.XX


#pkts encaps: 839, #pkts encrypt: 839, #pkts digest: 839
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 839, #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.: XX.XX.XX.XX/0, remote crypto endpt.: XX.XX.XX.XX/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: 8696965B
current inbound spi : F3B978BB

inbound esp sas:
spi: 0xF3B978BB (4089018555)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 166649856, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (4374000/1390)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0x8696965B (2258015835)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 166649856, crypto-map: outside_map
sa timing: remaining key lifetime (kB/sec): (4373982/1385)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

Thanks

1 Accepted Solution

Accepted Solutions

The crypto output indicates that you are encrypting and sending traffic to this peer but that they are not sending any encrypted traffic to you. This would most likely be some issue on their side. I have seen symptoms like this that were the result of a mismatch in configs between the two peers, or that were the result of an issue with nat/nat exemption for traffic through the VPN, or that were the result of flaws in the routing logic that did not send traffic to your subnets to their VPN interface.

HTH

Rick

HTH

Rick

View solution in original post

2 Replies 2

Mokhalil82
Level 4
Level 4

Just to add the packet trace

FW1/sec/act# packet-tracer input inside tcp 10.152.18.200 8080 10.170.43.5 $

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

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

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 10.170.43.0 255.255.255.0 outside

Phase: 4
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (any,any) source static obj-10.0.0.0 obj-10.0.0.0 destination static obj-10.170.0.0 obj-10.170.0.0 no-proxy-arp description ** allow inside access 10.170.0.0**
Additional Information:
NAT divert to egress interface outside
Untranslate 10.170.43.5/8080 to 10.170.43.5/8080

Phase: 5
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group inside_inbound in interface inside
access-list inside_inbound extended permit ip any 10.170.0.0 255.255.0.0
Additional Information:

Phase: 6
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (any,any) source static obj-10.0.0.0 obj-10.0.0.0 destination static obj-10.170.0.0 obj-10.170.0.0 no-proxy-arp description ** F0651991 allow inside access 10.170.0.0**
Additional Information:
Static translate 10.152.18.200/8080 to 10.152.18.200/8080

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

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

Phase: 9
Type: IDS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: FLOW-EXPORT
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 12
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:

Phase: 13
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_outbound out interface outside
access-list outside_outbound extended permit ip 10.152.18.0 255.255.255.0 any
Additional Information:

Phase: 14
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (any,any) source static obj-10.0.0.0 obj-10.0.0.0 destination static obj-10.170.0.0 obj-10.170.0.0 no-proxy-arp description ** allow inside access 10.170.0.0**
Additional Information:

Phase: 15
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

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

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

Phase: 18
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 2204851, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

The crypto output indicates that you are encrypting and sending traffic to this peer but that they are not sending any encrypted traffic to you. This would most likely be some issue on their side. I have seen symptoms like this that were the result of a mismatch in configs between the two peers, or that were the result of an issue with nat/nat exemption for traffic through the VPN, or that were the result of flaws in the routing logic that did not send traffic to your subnets to their VPN interface.

HTH

Rick

HTH

Rick