10-16-2019 11:53 AM
Hello,
We have a strange problem. We had a working Site-to-Site VPN to one of our offices which now doesn't work anymore.
We are receiving data but not sending data out.
If I do a packet tracer I get the following result :
Phase: 12
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x2aaad874b0e0, priority=70, domain=encrypt, deny=false
hits=547803, user_data=0x1656e4, cs_id=0x2aaad9fc8400, reverse, flags=0x0, protocol=0
src ip/id=10.1.0.0, mask=255.255.0.0, port=0, tag=any
dst ip/id=10.104.0.0, mask=255.255.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=outside
Al other Phases are fine except for the last one.
I have already removed the site to site connection and recreated it. Still the same issue. The tunnel is up and Active but no data is sent. Has someone seen this problem before?
Solved! Go to Solution.
10-25-2019 02:51 AM
We had to reboot the ASA. Now the connection works fine again. Thanks for the input.
10-16-2019 12:25 PM
10-17-2019 12:53 AM
Hi,
I can't ping devices on the other side of the tunnel. I can ping the public address of the tunnel.
Here a some results :
NAT rule :
60 (dmz) to (outside) source static hq-lan hq-lan destination static office-lan office-lan no-proxy-arp route-lookup
translate_hits = 51372, untranslate_hits = 51372
Source - Origin: 10.1.0.0/16, Translated: 10.1.0.0/16
Destination - Origin: 10.104.0.0/16, Translated: 10.104.0.0/16
Second packet tracer output :
ASA# packet-tracer input dmz icmp 10.1.3.198 8 0 10.104.1.1
Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 193.aaa.bbb.ccc using egress ifc outside
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (dmz,outside) source static hq-lan hq-lan destination static office-lan office-lan no-proxy-arp route-lookup
Additional Information:
NAT divert to egress interface outside
Untranslate 10.104.1.1/0 to 10.104.1.1/0
Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group dmz_access_in in interface dmz
access-list dmz_access_in extended permit icmp any any
Additional Information:
Phase: 4
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection decrement-ttl
service-policy global_policy global
Additional Information:
Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (dmz,outside) source static hq-lan hq-lan destination static office-lan office-lan no-proxy-arp route-lookup
Additional Information:
Static translate 10.1.3.198/0 to 10.1.3.198/0
Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 8
Type: SFR
Subtype:
Result: ALLOW
Config:
class-map class-default
match any
policy-map global_policy
class class-default
sfr fail-open
service-policy global_policy global
Additional Information:
Phase: 9
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
class-map inspection_default
match default-inspection-traffic
policy-map global_policy
class inspection_default
inspect icmp
service-policy global_policy global
Additional Information:
Phase: 10
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 11
Type: FLOW-EXPORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 12
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:
Result:
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Crypto ipsec sa result :
ASA# show crypto ipsec sa peer 195.www.xxx.yyy detail
peer address: 195.www.xxx.yyy
Crypto map tag: outside_map1, seq num: 2, local addr: 193.aaa.bbb.ccc
access-list outside_cryptomap_2 extended permit ip 10.1.0.0 255.255.0.0 10.104.0.0 255.255.0.0
local ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (10.104.0.0/255.255.0.0/0/0)
current_peer: 195.www.xxx.yyy
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 3087, #pkts decrypt: 3087, #pkts verify: 3087
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #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
#pkts no sa (send): 0, #pkts invalid sa (rcv): 0
#pkts encaps failed (send): 0, #pkts decaps failed (rcv): 0
#pkts invalid prot (rcv): 0, #pkts verify failed: 0
#pkts invalid identity (rcv): 0, #pkts invalid len (rcv): 0
#pkts invalid pad (rcv): 0,
#pkts invalid ip version (rcv): 0,
#pkts replay rollover (send): 0, #pkts replay rollover (rcv): 0
#pkts replay failed (rcv): 0
#pkts min mtu frag failed (send): 0, #pkts bad frag offset (rcv): 0
#pkts internal err (send): 0, #pkts internal err (rcv): 0
local crypto endpt.: 193.aaa.bbb.ccc/500, remote crypto endpt.: 195.www.xxx.yyy/500
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: 71CE28CE
current inbound spi : A3219C09
inbound esp sas:
spi: 0xA3219C09 (2736888841)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 5, IKEv2, }
slot: 0, conn_id: 101318656, crypto-map: outside_map1
sa timing: remaining key lifetime (kB/sec): (4331509/585)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0x71CE28CE (1909336270)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 5, IKEv2, }
slot: 0, conn_id: 101318656, crypto-map: outside_map1
sa timing: remaining key lifetime (kB/sec): (4285440/581)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Problem is the other side is managed by an provider with a Fortigate unit. I can't access that unit.
10-17-2019 02:01 AM
We need information from the remote side to troubleshoot further. Ther could have been a change in the remote side crypto ACL.
10-17-2019 12:09 PM
I would not rely on ping to determine that status of traffic flow across the site-to-site. I've seen many times where the ASAs are communicating, but ping doesn't respond (either one or both directions) for a variety of reasons. Are you using the GUI or CLI to troubleshoot? I would suggest accessing the ASA via ASDM, then looking at the Monitor tab for the VPN connections and see if you are populating traffic in both directions.
10-25-2019 02:51 AM
We had to reboot the ASA. Now the connection works fine again. Thanks for the input.
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