Error IPSEC-SPOOF when trying to receive traffic through vpn

[taherNet]

Hello,

I successfully configured a new VPN site-to-site between our Cisco FTD and a remote site that uses FortiGate.

The issue is that we are not enabled to send traffic through this tunnel; all the ACPs and NAT Exemptions from our side are correctly configured.

show crypto ipsec sa :

#pkts encaps: 16, #pkts encrypt: 16, #pkts digest: 16
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0.

When initiating traffic using the packet tracer from our side it shows ALLOW, but from the outside, it shows DROP, below the error.

Result: drop
Input Interface:
Outside(vrfid:0)
Input Status:
up
Input Line Status:
up
Output Interface:
DMZ(vrfid:0)
Output Status:
up
Output Line Status:
up
Action:
drop
Time Taken:
284899 ns
Drop Reason:
(ipsec-spoof) IPSEC Spoof detected
Drop Detail:
Drop-location: frame 0x000000aaad150fb8 flow (NA)/NA.

How can we troubleshoot this error?

[Kasun Bandara]

@taherNet hi, normally spoofing occurs when device receive unexpected traffic from unexpected interface. since this is related to VPN, i think its good to check your routing table and for routing loops. also try real testing due to 'packet trace' not suitable to test VPN traffic.

also according to the output, your firewall not receiving the traffic from other side peer. check if that side peer sending traffic properly to the IPsec tunnel.

[Aref Alsouqi]

Having zero decaps would suggest that you are not receiving any VPN traffic back from the FortiGate side. This could be caused for a different set of reasons such as a block access list entry in the middle between the FTD and the FortiGate, a wrong NAT rule on the FortiGate side, a wrong VPN config on the FortiGate side, routing issues on the FortiGate side etc. I would highly recommend working on resolving this issue with the FortiGate admins, if you see the traffic coming from your FTD, then they need to trying to find out the root cause on their side. However, if they won't be able to capture any traffic coming from your FTD, then the issue could potentially be related to a block of this traffic at somewhere along the path, or a routing issue at somewhere before the traffic make it to the FortiGate firewall.

[taherNet]

Hello, thank you for the reply. 

When trying to initiate a ping from our side it doesn't work but we see traffic coming from our FTD (#pkts encaps increase), on the other hand, the Fortigate admin confirms he didn't see any traffic originating from any of our protected networks.

Below is a packet capture of a test ping initiated from our side:

13: 21:39:18.123986 172.29.1.20 > 10.12.11.130 icmp: echo request
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Elapsed time: 23457 ns
Config:
Additional Information:
MAC Access list

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

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Elapsed time: 17060 ns
Config:
nat (Outside,DMZ) source static BPM BPM destination static DMZ-MEE-GW DMZ-MEE-GW
Additional Information:
NAT divert to egress interface Outside(vrfid:0)
Untranslate 10.12.11.130/0 to 10.12.11.130/0

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Elapsed time: 7506 ns
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip ifc DMZ object DMZ-MEE-GW ifc Outside object-group FMC_INLINE_dst_rule_268443665 rule-id 268443665
access-list CSM_FW_ACL_ remark rule-id 268443665: ACCESS POLICY: ACCES-FMC-FTD - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268443665: L7 RULE: MEE_OUT_VPN_BPM
object-group network FMC_INLINE_dst_rule_268443665
description: Auto Generated by FMC from dst of UnifiedNGFWRule# 28 (ACCES-FMC-FTD/mandatory)
network-object object BPM_2
network-object object BPM_3
network-object object BPM_1
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached

Phase: 5
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Elapsed time: 7506 ns
Config:
class-map class-default
match any
policy-map global_policy
class class-default
set connection advanced-options UM_STATIC_TCP_MAP
service-policy global_policy global
Additional Information:

Phase: 6
Type: NAT
Subtype:
Result: ALLOW
Elapsed time: 7506 ns
Config:
nat (Outside,DMZ) source static BPM BPM destination static DMZ-MEE-GW DMZ-MEE-GW
Additional Information:
Static translate 172.29.1.20/1 to 172.29.1.20/1

Phase: 7
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 7506 ns
Config:
Additional Information:

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 7506 ns
Config:
Additional Information:

Phase: 9
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Elapsed time: 37532 ns
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
Elapsed time: 6824 ns
Config:
Additional Information:

Phase: 11
Type: VPN
Subtype: encrypt
Result: ALLOW
Elapsed time: 16207 ns
Config:
Additional Information:

Phase: 12
Type: NAT
Subtype: rpf-check
Result: ALLOW
Elapsed time: 4265 ns
Config:
nat (Outside,DMZ) source static BPM BPM destination static DMZ-MEE-GW DMZ-MEE-GW
Additional Information:

Phase: 13
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Elapsed time: 58857 ns
Config:
Additional Information:

Phase: 14
Type: NAT
Subtype: per-session
Result: ALLOW
Elapsed time: 4265 ns
Config:
Additional Information:

Phase: 15
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Elapsed time: 853 ns
Config:
Additional Information:

Phase: 16
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Elapsed time: 49474 ns
Config:
Additional Information:
New flow created with id 835202884, packet dispatched to next module

Phase: 17
Type: EXTERNAL-INSPECT
Subtype:
Result: ALLOW
Elapsed time: 11942 ns
Config:
Additional Information:
Application: 'SNORT Inspect'

Phase: 18
Type: SNORT
Subtype: appid
Result: ALLOW
Elapsed time: 7820 ns
Config:
Additional Information:
service: ICMP(3501), client: (0), payload: (0), misc: (0)

Phase: 19
Type: SNORT
Subtype: firewall
Result: ALLOW
Elapsed time: 28268 ns
Config:
Network 0, Inspection 0, Detection 0, Rule ID 268443665
Additional Information:
Starting rule matching, zone 3 -> 2, geo 0 -> 0, vlan 0, src sgt: 0, src sgt type: unknown, dst sgt: 0, dst sgt type: unknown, user 9999997, no url or host, no xff
Matched rule ids 268443665 - Allow

Result:
input-interface: DMZ(vrfid:0)
input-status: up
input-line-status: up
output-interface: Outside(vrfid:0)
output-status: up
output-line-status: up
Action: allow
Time Taken: 327811 ns

[Aref Alsouqi]

If the FortiGate admins said they don't see nothing coming from your protected networks then I think we would need to confirm that your FTD is actually sending the traffic down the tunnel. From your packet tracer output it seems so. One thing I've noticed from the packet tracer output you shared is that the identity NAT rule seems to have the interfaces flipped around, instead of (DMZ,outside) you seem to have it created as (outside,DMZ), I'm not sure if this would affect anything tbh and I can't remember if this is the way how the firewall presents it. Could you please try to change it to (DMZ,outside) and reset the tunnel and see if that makes any difference?

[taherNet]

This is the output of crypto ipsec sa after changing the nat rule:

#pkts encaps: 1392, #pkts encrypt: 1392, #pkts digest: 1392
#pkts decaps: 1254, #pkts decrypt: 1254, #pkts verify: 1254
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 1392, #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

Still, the ping doesn't work.

[MHM Cisco World]

Friend it not cisco issue it forti FW issue

It have ACL that drop packet.

Make admin in remote site check ACL.

MHM

[Aref Alsouqi · Accepted solution]

It looks much better. If ping is not working it could potentially be that the destination host you are trying to ping has a local firewall and it is not allowing ICMP traffic, or, maybe the FortiGate firewall is configured not to allow ping. I would check this with the FortiGate admins and would also ask them if they can now see the protected traffic coming from your FTD. A side from ping, could you please try to access a remote resource or an application over the VPN and see if it works?

[taherNet]

Hello Aref,

We have tried this configuration with another site that also uses Fortigate as an edge FW, but the IPSEC-SPOOF reason remains when using packet tracer to simulate remote traffic.

[Aref Alsouqi]

Hello. Sorry I might be missing something here. The IPsec spoof error was not showing on the last packet tracer which was issued after you adjusted the identity NAT rule. Where do you still see it? did you check accessing any resources in the remote site that are sitting behind the FortiGate device?

[taherNet]

Hello sir,

As a conclusion of this matter, it seems that it was an issue on the FortiGate side, for the IPSEC-SPOOF error it looks to be a normal behavior when trying to initiate traffic from the OUTSIDE to our LAN as I tested it in a site-to-site VPN between our main sites.

[Aref Alsouqi]

Thanks for the update. If you are referring to the packet tracer then yes because when you try to simulate the VPN traffic from the outside interface to inside, this simulation doesn't trigger the VPN tunnel as when you do it from inside to outside, and the firewall in this case sees some RFC1918 IPs coming from outside.