Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Marcel_Gramalla
Advisor
Jump to solution

Anti-Spoofing and VPN Traffic

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:

anti_spoofing.PNG 

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:

fw_monitor.PNG

 

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

0 Kudos
1 Solution

Accepted Solutions
Maarten_Sjouw
Champion
Champion

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.

Regards, Maarten

View solution in original post

6 Replies
Danny
Champion Champion
Champion

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
Champion
Champion

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.

Regards, Maarten
Marcel_Gramalla
Advisor

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.

 

 

 

0 Kudos
Maarten_Sjouw
Champion
Champion
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.
Regards, Maarten
Timothy_Hall
Champion
Champion

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...

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Maarten_Sjouw
Champion
Champion
That is just 1 one the many reasons why we actually want to use dynamic routing for these type of customers.
Regards, Maarten
0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events