Block RFC1918-egress floating rules
-
I was messing around with the rules in my firewall and attempted to implement some of the guides in Netgates documentation. It looks like the rule is being allowed but then its also being immediately blocked again and the page eventually times out. Why is that?
Specifically this guide:
Preventing RFC 1918 Traffic from Exiting a WAN Interface¶It seemed pretty simple and I implemented everything as it shows in the guide but it seems like it's still having issues working correctly for me.
Allow direction OUT and IN. I added this additional rule.
Block RFC1918_local
System logs still blocking
-
the system logs allow but block again
-
you need to check the quick box.
-
@CatSpecial202 you don't need this rule
The state created when you go out would allow the return traffic.
If you want to allow talking to your modem IP of 192.168.100.1, I would really create a vip - its cleaner solution.
-
@johnpoz I originally attempted a different NAT outbound that was going to a destination that was the entire subnet of the modem. However, not using a virtual IP and it didn't work. I didn't think that inbound rule would do anything but i figured, whatever might as well try it.
I deleted that inbound rule and added all this other stuff, but it still doesn't seem to be working. The modem is at 192.168.100.1. Should I add this address in the NAT Address? I restarted my router and everything.
-
@CatSpecial202 you don't really want a reject on your wan rule to be honest.. That sends a response. And you almost never want a response to go out your wan.
I think we ran into this some time ago, where you have to set the not reply option on your allow rule to the 192.168.100.1 address in floating
Back a few versions ago - you didn't need this, but something awhile back if you don't have this checked it doesn't work.. I will see if I can dig up that older thread.
edit: here is a thread where it came up before, and at that time did a bit of digging.. But then I got side tracked, but you notice this post where I did some sniffing and different macs.. If you set checkbox to disable reply-to on your allow rule to 100.1 it should now work.
https://forum.netgate.com/post/1117003
edit2:
I just checked this again, yeah if don't have that checked it doesn't work if you have a block rfc1918 rule under it, which is really the whole point wanting to block noise from leaving the wan.. I really should find some time to figure out why exactly this fails if you don't have that checked.. most likely have to look at the actual rules that get created with that unchecked vs when checked - most likely that would make it all clear ;)But to solve your issue - I would check that box and you should be working.
Notice the little gear in my rule
That shows an advanced option set, the disable the auto reply-to rule. With that set I can access my modem web gui.
If not checked - doesn't work, if you leave it unchecked (default) and you disable the outbound block rfc1918 rule it works.. So yeah its weird..
-
@johnpoz yes, that was it. Now it works. Thank you. Why did you bring up the, "you don't really want a reject on your wan rule to be honest."? Can you not add a rule that has a reply-to on the WAN by default?
As far as I understand if you have a rule on an interface that blocks inbound RFC1918 what exactly does blocking outbound do? Blocking inbound is enough to not establish state so shouldn't that be enough?
btw. I've noticed my logs clearing up significantly.
-
@CatSpecial202 A reject is fine on a lan side rule - it sends an answer back.. But your blocking outbound.. I don't even know if it would work to be honest you would have to sniff to see..
but say you have a rule to block say ping to your wan IP from bad guys.. You would send them a reject every time they scanned a port that was blocked.
So here is a rule on my lan that rejects going to 8.8.8.8 - see how I get a RST back, when it really should of just timed out..
Might be ok since your traffic is going outbound. But it is normally not a good idea to use a reject on a wan interface unless your sure you want to actually send back something to the sender.
Ok I tested changing my block outbound rfc1918 to reject - and yup I do get back a rst.. So guess its fine inbound traffic from the internet would not trigger that rule anyway.
Just be aware you normally don't want reject on a internet facing interface - unless your sure you want to send an answer back.. Which could lead to sort of dos attack with your firewall busy answering stuff it should just drop and pay no attention too.
