Anti-Spoofing and VPN Traffic

[Marcel_Gramalla]

Hi CheckMates,

I wanted to do a cleanup of our current Firewall (R77.30) topology and enable Anti-Spoofing in Prevent mode for all interfaces (yes, it was in Detect mode before...).

I checked all routes and defined the topology based on self created groups for all interfaces containing multiple networks. 

The strange thing is that I get Anti-Spoofing logs for outgoing VPN traffic. We have one "company backbone" Interface (eth3) where all traffic to 10.0.0.0/8 is routed and our Internet Interface is eth0. Our Clients are coming from eth4.

In my logs I can see the following:

 

For every connection I see a Anti-Spoofing entry coming from eth0 and afterwards the correct VPN message coming from eth4. Strangely enough with fw monitor I can see the traffic coming from eth4:i and eth4:I (which is correct) leaving eth3:o and then finally leaving eth0:o:

I was wondering if you have any idea what's wrong with this setup.

[Danny]

Check your interface topology with my One-Liner for Address Spoofing Troubleshooting and compare it with your VPN topology by using my One-liner to show VPN topology on gateways.

From your description it seems that your VPN encryption domains and internal networks definitions are for the same 10.x networks which is causing the spoofing logs.

[Maarten_Sjouw · Accepted solution]

What is the mistake made the most times with Anti Spoofing and VPN's?
You add a route for 10.0.0.0/8 towards the internal network, even though you only use 10.10.*-10.50.* and you have a VPN with a remote network 10.60.1.0/24, according to the route it lives on the inside of your gateway. When you copy the routing, or in R80.20+ you set the spoofing based on the routing table, you have that network as an internal interface network.
But in fact it lives on the Internet side of the gateway, what you need to do is either get your routing setup properly and if you don't want to do that just add a new group, containing all remote VPN networks, in the 'Do not check for anti-spoofing' option of the internet facing interface.

The reason you see eth3 and then eth0 is due to the fact your main 10.0.0.0/8 route is on eth3 but the VPN is actually routing the traffic out, the Return traffic is dropped by anti spoofing.

[Marcel_Gramalla]

Thank you for the quick response. That's exactly our setup right now. The best way would be to clean up the routing table I guess. 

It's more work than just excluding the VPNs in Anti-Spoofing but I think it's worth the effort.

[Maarten_Sjouw]

Some of our customers with hundreds of networks and no proper IP plan have the exact same issue. And no this is really not something you want to build for those type of customers, just use the exception method works fine on those customers.

[Timothy_Hall]

Having supernetted RFC1918 routes (for example 10.0.0.0/8) on the firewall using a core router as the next hop, and that same core router having a default route pointing back to the firewall can also cause what I call a "Core Router Supernet Loop" in my book when traffic is sent to a nonexistent/unused network in that supernetted RFC1918 space.  Any traffic such as this (that is not NATted) will loop 255 times between the firewall and core router until the TTL decrements to zero and the packet is finally discarded.  Very nasty when hundreds or thousands of these types of packets are being generated every second by a worm or NMS probing and they all get looped 255 times...

[Maarten_Sjouw]

That is just 1 one the many reasons why we actually want to use dynamic routing for these type of customers.

[stefanodg]

Hello Maarten,

I have the same situation and i thought about adding a static route specifically for the 10.60.1.0/24 network to the external interface, but I’m encountering the same anti-spoofing issue.

Do you know why the firewall is not analyzing the static route, while only the exception works?

Thank you in advance!