How to block all forwarded traffic on OPT1?
-
Is there a way to modify the rule so that "default to all" will only apply for traffic that is leaving on the WAN interface?
-
Block what you don't want then pass what you want.
Many people make an alias of local networks and/or rfc1918 addresses and block anything with a destination to those aliases then pass everything else.
There is, unfortunately, not a Local Networks self-generated alias like there is for This Firewall (self).
-
Is there a way to modify the rule so that "default to all" will only apply for traffic that is leaving on the WAN interface?
Firewall rules are parsed on traffic as it enters the interface, not when it leaves. Only if it passes via rule does it leave the interface for its destination. If you don't want anyone on LAN to talk to OPT1, you could either add a block rule at the top or modify the default allow rule so that the destination is !OPT1. I prefer to leave default rules alone and would just add a block rule between LAN network and OPT1 network. Easier to read and understand, too.
-
Thanks for the answers so far. I don't mean to be a nuisance by continuously bumping my thread, but I'm trying to learn a thing or two about pfSense and FreeBSD since this is the only time I ever worked with it.
Is there any specific reason why the packets aren't also filtered on an outgoing interface? Because I read a few papers about pf, and it seems that it is capable of dropping outgoing packets too.
pass quick in on re1 inet proto tcp from any to (re1) port = https flags S/SA keep state label "WebGUI in"
pass quick out on re1 inet proto tcp from (re1) port = https to 192.168.2.0/24 label "WebGUI out"
block drop out log quick on re1 inet from any label "Do not allow any IPv4 traffic"
block drop out log quick on re1 inet6 from any label "Do not allow any IPv4 traffic"Perhaps some rules like these would do the trick? I'm not yet sure, if I can create raw pf rules like this in pfSense WebGUI (or somewhere else, and they don't get overwritten).
Also, why is there an additional rule for port 500 (besides the wildcart rule) generated by the automatic outbound NAT?
I found my answer to this question. It's because the outbound NAT rules are displayed incorrectly in the pfSense WebGUI. For example, take a look at the outbound nat picture in my earlier post. It shows that there are two automatic rules (one for all destination ports * and the other for port 500).
This is not the actual case. What's really going on according to pfctl is this:
TRANSLATION RULES:
no nat proto carp all
nat-anchor "natearly/" all
nat-anchor "natrules/" all
nat on re2 inet from 127.0.0.0/8 to any port = isakmp -> (re2) round-robin static-port
nat on re2 inet from 192.168.1.0/24 to any port = isakmp -> (re2) round-robin static-port
nat on re2 inet from 192.168.2.1 to any port = isakmp -> (re2) round-robin static-port
nat on re2 inet from 127.0.0.0/8 to any -> (re2) port 1024:65535 round-robin
nat on re2 inet from 192.168.1.0/24 to any -> (re2) port 1024:65535 round-robin
nat on re2 inet from 192.168.2.1 to any -> (re2) port 1024:65535 round-robin
no rdr proto carp all
rdr-anchor "relayd/" all
rdr-anchor "tftp-proxy/" all
rdr-anchor "miniupnpd" allThe port range is not a full range as it excludes privileged ports. This is why there needs to be an additional rule for port 500.
EDIT: Fixed mistake about firewall/nat confusion.
-
Is there any specific reason why the packets aren't also filtered on an outgoing interface?
Only way to block outgoing is floating rules. Why are you shooting yourself in the foot goes beyond me. Do not let the traffic in.
-
Only way to block outgoing is floating rules.
Yeah, thanks. I just noticed the floating rules box also offers in/out choice.
Why are you shooting yourself in the foot goes beyond me. Do not let the traffic in.
I'm still learning the firewall. Thanks for the tip though.
EDIT: Perhaps something like this would be more appropriate. I'll see, if I can program these in somehow… bbl
block drop in log quick inet from any to 192.168.2.0/24 label "Block traffic to OPT1 (IPv4)"
block drop in log quick inet6 from any to ?????????????? label "Block traffic to OPT1 (IPv6)"
pass in on re1 inet from 192.168.2.0/24 to 192.168.2.1 port = https label "Allow WebGUI access"
block drop in log on re1 inet from any to any label "Block all traffic from OPT1 (IPv4)"
block drop in log on re1 inet6 from any to any label "Block all traffic from OPT1 (IPv4)" -
I found my answer to this question. It's because the outbound NAT rules are displayed incorrectly in the pfSense WebGUI. For example, take a look at the outbound nat picture in my earlier post. It shows that there are two automatic rules (one for IPv4, another for IPv6) for all ports (*).
No, nothing is incorrect. You are saying you're looking at the outbound NAT image when you're really looking at the firewall rules image. There is no IPv6 in the NAT page, nor is NAT used in IPv6 by anyone sane.
pfSense does things a specific way, and that is to block traffic BEFORE IT ENTERS THE FIREWALL. The entire GUI is designed around this concept because it's the most secure way to deal with your traffic. Block it at the source.
Yes, you can use floating rules to block in the outbound direction but why let the traffic into the firewall in the first place. Your scenario is really easy:
LAN:
Reject IPv4 any source LAN net dest OPT1 net
Pass IPv4 any source LAN net dest anyOPT1:
Pass IPv4 TCP source OPT1 net dest This Firewall (self) port 22,80,443
(default deny any any rule)You don't have to worry about the NAT rules being present for OPT1. Those will only be used for traffic going OUT the NAT interface (WAN). Since you're blocking the traffic at OPT1 they will not be used.
-
Err, sorry! What I meant to say was that there are two rules for three networks (127.0.0.0/8, 192.168.1.0/24 and 192.168.2.0/24). Don't know why I typed IPv6… One rule is shown to be for all destination ports (*), and it's this one that is displayed incorrectly. The correct port range should be displayed as 1024:65535, not *.
Thanks for the correction.
-
No, it's *. If you change the destination ports to 1024:65535 you won't get NAT for outbound connections to anything on low ports and will break them.
-
I don't understand this part. Did I read the pf rules wrong?
If all ports are NAT-ted then why is there an additional rule (3 of them actually) for port 500 (isakmp) present?nat on re2 inet from 127.0.0.0/8 to any port = isakmp -> (re2) round-robin static-port
nat on re2 inet from 192.168.1.0/24 to any port = isakmp -> (re2) round-robin static-port
nat on re2 inet from 192.168.2.1 to any port = isakmp -> (re2) round-robin static-port
nat on re2 inet from 127.0.0.0/8 to any -> (re2) port 1024:65535 round-robin
nat on re2 inet from 192.168.1.0/24 to any -> (re2) port 1024:65535 round-robin
nat on re2 inet from 192.168.2.1 to any -> (re2) port 1024:65535 round-robin -
The ISAKMP protocol works better in most cases if the source port is static.
If you want complete control over your outbound NAT rules, switch to manual outbound and save and you'll see exactly what's there.
Those 1024:65535 entries are not the source ports. Look again, they're after the -> not before. Those are the ports pf can use dynamically as the source port of the NAT/PAT connection on the outside (the inside global port).
-
Ah, thank you very much for explaining. This had me confused for a while.
-
this might help…
