VPN ASA - Fortigate

[pugliededaniele88]

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

[Francesco Molino]

Hi

Can you share your config on ASA?
Otherwise, can you do a packet-tracer with the following command:
- packet-tracer input inside icmp 10.0.62.1 8 0 192.168.50.1

I put "inside" on the command as I assumed your interface name on ASA for your internal network is inside. If the name is different, then change the word inside by the correct ASA internal nameif you've configured.

[pugliededaniele88]

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

[Francesco Molino · Accepted solution]

When you send ping from your site to remote site, do you see encaps packets?

Just to be sure that packets on your site are going through the VPN, can you follow this doc I made and save all outputs in a text file please?
https://supportforums.cisco.com/t5/security-documents/asa-how-to-troubleshoot-vpn-l2l-ensure-traffic-is-passing/ta-p/3166082

[pugliededaniele88]

@Francesco Molino

Hi,

yes the packet are encrypted correctly...

[GioGonza]

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

https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118097-configure-asa-00.html

HTH

Gio

[pugliededaniele88]

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.

[Francesco Molino]

OK I don't get your outputs based in the link i forwarded but this output shows that packets are sent from asa to your destination host but not proving that traffic is going to the right vpn.
And when doing so you should see encaps packets on your asa, do you sees those packets incrementing?

[pugliededaniele88]

yes the counters increment !

[Francesco Molino]

Ok then, you'll need to troubleshoot on the other side to see if incoming packets are being dropped or not.
When you'll have access share your outputs and we'll be able to figure it out,

[pugliededaniele88]

The other side is a fortigate and is it managed from another vendors. So the case is closed by me :)

[Francesco Molino]

Ok happy having been able to help you