Interface feature for blocking RFC1918 or custom rule?
-
To maintain segmentation between interfaces (both physical and VLANs) on my pfSense, I have created a block rule for each interface that has the respective interface as the source and RFC 1918 nets defined as the destination. I noticed on the interface pages a feature called 'block private networks and loopback addresses'. The feature adds a block rule for the interface, however it defines the source as RFC 1918 and 'any' as the destination. I am trying to discern if there is any benefit to my custom rule vs this feature, and if I should just use the interface feature to isolate my subnets?
-
The interface checkbox adds rules that block connections into that interface with an RFC1918 source address. It is intended for use on public WANs.
It sounds like you want to block RFC1918 destinations instead. An Alias and a block rule is perfect there.
I actually prefer using a reject rule instead of a block so any inside clients get a RST (connection refused) instead of just hanging.
-
Would an RST be a give away to user that a network is behind the address they are trying to resolve?
-
I am talking about connections from the inside that are hitting your block/reject RFC1918 rule.
If you reject source LAN net dest RFC1918 they will get a RST no matter what address they try that is RFC1918.
If you have enemies inside your network it is up to you to determine the threat model. The whole "stealth" thing is pretty overblown, IMHO.
-
Thank you. Good points.
-
Firewalls normally do not send RST for a port that is closed.. Hosts will quite often - windows for sure does.. Hit windows box on port that is not listening with firewall not on and you get a RST..
"have created a block rule for each interface that has the respective interface as the source and RFC 1918 nets defined as the destination."
Huh? Please post this rule.. That rule would never trigger since traffic is only evaluated inbound to an interface - did you create these rules on the floating tab picking the interface? And use outbound direction? Do you mean you created a rule on each interface with source that respective net and dest rf1918? This would yes keep your vlans from talking to each other. I have sim rules on my vlans I don't want to talk to other vlans, etc.
Be it you reject or just let pfsense drop it is up to you.. I would not reject to public internet… not so much of trying to stay "stealth" ;) With Derelict that term is nothing but a bunch of hype.. But you don't want to be sending out traffic for every stray noise packet that hits your wan ;) Be nuts to do that!!! But on lan can be helpful to see the RST come right from pfsense, vs no answer etc.
-
Thanks JohnPoz.
For example. The block rule on my LAN looks like this.
Block IPV4 * LAN net * RFC1918 nets "I have repeated this on every interface replacing the source with the respective interface. The way I understand it, the block is protecting other nets from the interface. Should I invert that logic and protect the interface from other nets? Do you recommend that I do something like this instead?
Reject IPV4 * RFC1918 nets * LAN net *
Thanks.
-
screenshots are WAY better..
your first rule is correct if on the lan net.
Your second rule would only be good if NOT on the lan net with dest of lan net, and makes no sense really unless you had downstream networks off this interface..
-
Good. Thanks. The rule has been blocking between nets so I figured I was doing something right. I just wasn't sure if there was a better way of blocking inter-lan traffic.
I will just make sure that the rule is rejecting instead of blocking in the LAN as suggested.
-
you do not have to reject - that is up to you.
