ā03-01-2017 04:03 AM - edited ā03-08-2019 09:33 AM
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
Solved! Go to Solution.
ā03-01-2017 05:33 AM
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
ā03-01-2017 04:06 AM
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
ā03-01-2017 05:33 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide