10-25-2017 02:55 AM - edited 03-12-2019 04:39 AM
Dear all,
I have a issue with a vpn between ASA and Fortigate fw. The VPN is up correctly but i am unable to ping the inside ip address at remote peer (fortigate). From fortigate the external vendor has leave a continuaty ping also but he not receive any reply. The strange thing is that the packet are decapsulated but if I do a packet capture on ASA from inside IP fortigate 192.168.50.0 to my network 10.0.62.0 255.255.254.0 I don't see any packets.
Below some show commands:
(config)# sh crypto ipsec sa peer x.x.x.x
peer address: x.x.x.x
Crypto map tag: novellara_map, seq num: 40, local addr: 10.222.3.254
access-list VPN-SABAR extended permit ip 10.0.62.0 255.255.254.0 192.168.50.0 255.255.255.0
local ident (addr/mask/prot/port): (10.0.62.0/255.255.254.0/0/0)
remote ident (addr/mask/prot/port): (192.168.50.0/255.255.255.0/0/0)
current_peer: x.x.x.x
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 362, #pkts decrypt: 362, #pkts verify: 362
#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
#send errors: 0, #recv errors: 0
local crypto endpt.: 10.222.3.254/4500, remote crypto endpt.: x.x.x.x/4500
path mtu 1500, ipsec overhead 82, media mtu 1500
current outbound spi: 3AF84546
current inbound spi : B4198019
inbound esp sas:
spi: 0xB4198019 (3021570073)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, NAT-T-Encaps, PFS Group 5, }
slot: 0, conn_id: 1212416, crypto-map: novellara_map
sa timing: remaining key lifetime (sec): 1784
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0x3AF84546 (989349190)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, NAT-T-Encaps, PFS Group 5, }
slot: 0, conn_id: 1212416, crypto-map: novellara_map
sa timing: remaining key lifetime (sec): 1782
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
3 IKE Peer: x.x.x.x
Type : L2L Role : responder
Rekey : no State : MM_ACTIVE
Solved! Go to Solution.
10-25-2017 05:56 AM
10-25-2017 05:12 AM
10-25-2017 05:42 AM
Hi, this is the output of packet tracert command. I can't share the running config beacause privacy of our customer.
packet-tracer input inside icmp 10.0.63.46 8 0 192.168.50.1
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 0.0.0.0 0.0.0.0 outside
Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group entrante->inside in interface inside
access-list entrante->inside extended permit ip any any
Additional Information:
Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 6
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: 7
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 8
Type: NAT-EXEMPT
Subtype:
Result: ALLOW
Config:
match ip inside 10.0.62.0 255.255.254.0 outside any
NAT exempt
translate_hits = 1449949, untranslate_hits = 329131
Additional Information:
Phase: 9
Type: VPN
Subtype: encrypt
Result: ALLOW
Config:
Additional Information:
Phase: 10
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
Phase: 11
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 12
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 4384711, 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
10-25-2017 05:56 AM
10-26-2017 12:44 AM
10-25-2017 06:41 AM
Hello @pugliededaniele88,
As per you initial comment, the traffic from the other side is reaching your ASA but you don´t see it if you do a packet capture on your inside interface on your ASA, that means the ASA is decrypting the traffic but for some reason it is dopping it :), what you need to do is the following:
1. Apply the capture for ASP drops: "capture asp type asp-drop all" to see the capture "show cap asp"
2. You can clear the ASP drop reasons in order to see if you are matching one: "clear asp drop"
3. Look for the traffic on the other side and verify if the ASA is really dropping the packets: "show cap asp | in 192.168.50.x"
4. If the traffic appears, that means the ASA is dropping the packets and you should see something like this:
ASA# show capture asp-drop
2 packets captured
1: 04:12:10.428093 192.168.10.10.34327 > 10.94.0.51.15868: S
2669456341:2669456341(0) win 4128 <mss 536> Drop-reason: (acl-drop)
Flow is denied by configured rule
2: 04:12:12.427330 192.168.10.10.34327 > 10.94.0.51.15868: S
2669456341:2669456341(0) win 4128 <mss 536> Drop-reason: (acl-drop)
Flow is denied by configured rule
2 packets shown
For reference: https://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/show_asp_drop/show_asp_drop.html
HTH
Gio
10-25-2017 07:51 AM
Hi, with a capture i see that:
# sh capture VPN | i 192.168.50
4: 14:04:54.300872 10.0.63.46 > 192.168.50.104: icmp: echo request
8: 14:04:59.308455 10.0.63.46 > 192.168.50.104: icmp: echo request
11: 14:05:04.300506 10.0.63.46 > 192.168.50.104: icmp: echo request
12: 14:05:09.308165 10.0.63.46 > 192.168.50.104: icmp: echo request
24: 14:05:14.300277 10.0.63.46 > 192.168.50.104: icmp: echo request
25: 14:05:19.307875 10.0.63.46 > 192.168.50.104: icmp: echo request
26: 14:05:24.299789 10.0.63.46 > 192.168.50.104: icmp: echo request
27: 14:05:29.307677 10.0.63.46 > 192.168.50.104: icmp: echo request
29: 14:05:34.299575 10.0.63.46 > 192.168.50.104: icmp: echo request
35: 14:05:39.307311 10.0.63.46 > 192.168.50.104: icmp: echo request
37: 14:05:44.299194 10.0.63.46 > 192.168.50.104: icmp: echo request
40: 14:05:49.307006 10.0.63.46 > 192.168.50.104: icmp: echo request
42: 14:05:54.298919 10.0.63.46 > 192.168.50.104: icmp: echo request
43: 14:05:59.306594 10.0.63.46 > 192.168.50.104: icmp: echo request
46: 14:06:04.298507 10.0.63.46 > 192.168.50.104: icmp: echo request
47: 14:06:09.306228 10.0.63.46 > 192.168.50.104: icmp: echo request
52: 14:06:14.298202 10.0.63.46 > 192.168.50.104: icmp: echo request
57: 14:06:19.305755 10.0.63.46 > 192.168.50.104: icmp: echo request
62: 14:06:24.297912 10.0.63.46 > 192.168.50.104: icmp: echo request
63: 14:06:29.305480 10.0.63.46 > 192.168.50.104: icmp: echo request
69: 14:06:34.297576 10.0.63.46 > 192.168.50.104: icmp: echo request
70: 14:06:39.305129 10.0.63.46 > 192.168.50.104: icmp: echo request
83: 14:06:44.297180 10.0.63.46 > 192.168.50.104: icmp: echo request
84: 14:06:49.305556 10.0.63.46 > 192.168.50.104: icmp: echo request
85: 14:06:54.296890 10.0.63.46 > 192.168.50.104: icmp: echo request
anyway the packet is received from fortigate I asked access on fortigate firewall. So I think that the issue can be caused by a routing problem on the fortigate.
whit the command show cap asp | in 192.168.50.x I don't see any match.
10-25-2017 02:08 PM
10-26-2017 01:01 AM
yes the counters increment !
10-26-2017 05:12 AM
10-26-2017 05:16 AM
The other side is a fortigate and is it managed from another vendors. So the case is closed by me :)
10-26-2017 05:17 AM
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