Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
AlexandruD
Contributor

route based VPN antispoofing

Hello,

I have the following issue caused by the antispoofing mehcanism. (SMS is R81.20, SMB GWs are R81.10.08)

Two IPsec VPN peers (centrally managed SMB appliances) are connected via route based VPN, over an MPLS interconnection between the two.
The only routes associated with the MPLS connected interfaces (LAN7 on both peers), are the needed static routes in order for the peers to reach each other over the MPLS interconnection. The first peer's relevant VTI is vpnt3, and the second one's is vpnt2.
The logs show the following behavior, where the second peer is blocking icmp ping requests packets send by the first peer (source and destination IP addresses are of other internal interfaces of the peers):

origin is first peer - VPN blade - Encrypt action - vpnt3 outoging - src 172.17.0.1 - dst 172.18.0.1 - specific rule id matched
origin is second peer - VPN blade - Decrypt action - vpnt2 incoming - src 172.17.0.1 - dst 172.18.0.1 - specific rule id matched
origin is second peer - Firewall blade - Drop action - LAN7 incoming - src 172.17.0.1 - dst 172.18.0.1 - message info "Address spoofing"

On both peers, antispoofing is configured to be calculated by the gateway, based on its routing table. Routes to direct traffic via the route based VPN are generated via OSPF, which is running on the VTI interfaces inbetween the peers.
Now, I would disable antispoofing all toghether, as I find it unnecessary and annoying, the way it's performed by CP, but the resultant warning messages are just as annoying.

Does anyone know a solution for this, or perhaps knows hwo to disable antispoofing and the warning messages as well?

Thank you

0 Kudos
5 Replies
Bob_Zimmerman
Authority
Authority

Sounds like you have a routing loop. Traffic decrypted from a route-based VPN only shows up on the VTI. It never arrives on any real Ethernet interface. The ARM boxes definitely have some different behaviors, but I wouldn't expect this to be one of them. I would run a packet capture on LAN7 to see what's going on.

0 Kudos
the_rock
Legend
Legend

I agree with Bob here, just run captures and have a look. Can you send a screenshot of the topology? Please blur out any sensitive info.

Best,

Andy

0 Kudos
AlexandruD
Contributor

No route loops, nothing of interest on LAN7, but ESP traffic. For some reason it is UDP encapsulated (with no NAT applied).

0 Kudos
the_rock
Legend
Legend

Have a look at below, see if its helpful

Andy

https://support.checkpoint.com/results/sk/sk115276

0 Kudos
AlexandruD
Contributor

Thanks! But I'v checked and found no issues.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Wed 01 May 2024 @ 02:00 PM (EDT)

    South US: HTTPS Inspection Best Practices

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82

    Thu 25 Apr 2024 @ 11:00 AM (SGT)

    APAC: CPX 2024 Recap

    Tue 30 Apr 2024 @ 03:00 PM (CDT)

    EMEA: CPX 2024 Recap

    Wed 01 May 2024 @ 02:00 PM (EDT)

    South US: HTTPS Inspection Best Practices

    Thu 02 May 2024 @ 11:00 AM (SGT)

    APAC: What's new in R82
    CheckMates Events