Port Forwarding - "Pass" Filter Rule Doesn't Limit to Selected Interface Traffic
-
Hi,
New here, but I've noticed something strange. I'm going to try to be clear, but I don't know if this is a reproducible issue, and I hope someone can verify it for me.
First of all, I am no network expert, so maybe I'm missing something fundamental, maybe nothing is wrong at all. But here's what's happening.
I have been trying to get pfBlockerNG's DNSBL setup. I have looked at several guides, and...long story short, it works. The problem is that it auto generates two port forwards LAN side (it does so every hour with cron). This would normally be fine but these port forwards are LAN port-forwards with the automatic "pass" traffic rule selected. This "pass" is passing all traffic, not just traffic from the LAN interface. I know because when I change the rule to an associated firewall rule (not the simple "pass" option), this non-LAN passing stops. Note I have unchecked the box to make PfBlockerNG create a floating rule (e.g. there is no such rule), and it's just set up to be on the LAN.
So does any traffic on any interface match the forward even though it's on the LAN? That doesn't sound right to me.
I haven't tested from the WAN side, but from my other local network interface, WLAN, the traffic goes through with the auto "pass" rule selected for the port forward, even though it doesn't when there is a discrete associated firewall rule.
As I understand it this is not supposed to happen. Port forwards are only supposed to work for the interface they're on right?
I am using pfBlockerNG, but I think the issue is likely unrelated, so I posted this here, hope that's okay.
Any help would be greatly appreciated, this feels like it could be a security hole, but I might be overreacting. Again, thanks to anyone who could help me with trying to reproduce (if it's a problem at all).
-
Rules only work on the interface they are on..
Whatever you think is happening is something else.. Your going to actually show your rules on your different interfaces and what traffic you think is happening. Along with with rules that are on your floating if you want some help in figuring out what is going on.
-
Hi, thanks for responding, I have many rules that I have slowly and carefully built up , they have worked fine, and still seem to. I doubt these rules are the problem. Displaying screenshots of a complete firewall config on a public forum is something I'm ideologically adverse to, I'd rather not tell everyone with an internet connection precisely what I do an don't do on the internet (this is largely the story my firewall rules would tell.)
That said, I can give you a few screenshots that perhaps make things clearer?
When I generate a rule like the following screenshot (I believe this is the default behavior for pfSense when creating a new port forward manually) everything works as you'd expect. I can access the 10.10.10.1 virtual ip from the LAN, but not from the WLAN. This is desirable, I want the portforward to only allow traffic from one place - the LAN.
(I realize there should be two rules, one for each of these portforwards, but this was not required for testing, as I only needed to access the https part of the server)
Anyway, the following works the way I want it to. :)
Associated rule (on LAN):
That said PfBlockerNG generates the port forward like this (every hour) :(
With this setup I CAN access the server from my other (local) network, the WLAN. This is undesirable.
No harm in showing you floating rules
I can tell you that there are NO rules from the WLAN side that allow this traffic. (It gets blocked when I don't have the "Pass" option selected on the portforward configuration.) That is to say when I generate a rule for the LAN side (instead of using the pass option on the port forward). It gets blocked by the default deny rule because the traffic is seen by the firewall as being on TCP port 8443 which has no associated rule on the WLAN interface.
I HAVE looked in the state table and verified that this is an actual connection that was established (not a cached copy of the website from some dirty configuration).
Is it potentially because the NAT address is 127.0.0.1? Does that address allow the "pass" option to generate a hidden rule that works for all of the interfaces? Maybe it doesn't make a rule at all but just messes with the firmware somehow. Anyway, this behavior of allowing traffic from a different interface to forward through the LAN portforward seems sketchy to me, but maybe I don't know how it's supposed to work, I would be extremely appreciative of those with more knowledge informing me if I misunderstand how portforwards work, but I thought the idea was that if you have a portforward on the LAN interface, then the traffic should look like this.
traffic(on port x) ----> [LAN interface] ----> portforward(for port x) ---> [some other interface] (e.g. the loopback)
but what seems to be happening when I have the portforward set up to pass traffic through it is not only the above, but also.
traffic(on port x) ----> [WLAN interface] ----> portforward(for port x) ----> [some other interface] (e.g. the loopback)
Why?
-
@drountian said in Port Forwarding - "Pass" Filter Rule Doesn't Limit to Selected Interface Traffic:
Displaying screenshots of a complete firewall config on a public forum is something I'm ideologically adverse to
What exactly do you think would be in the rule that would give away any sort of info that would be compromising?
Good luck with your problem... That nobody can help you with if your not going to give the information needed to help..
Is it potentially because the NAT address is 127.0.0.1? Does that address allow the "pass" option to generate a hidden rule that works for all of the interfaces?
NO!!
-
While there would be minimal inherent risk with sharing all the rules I am a very private person and I would prefer not to.
Since that seems to disincline you from attempting further assistance I will simply do without this feature for now.
Despite this, I must add that I posted this not only to receive help but also to help the community, if others find that this is a problem I hope they will find this thread, possibly add more info, possibly they will be a more trusted member/someone with more expertise who can verify the problem as an actual bug occurring (or not and what the cause is). Until that time I will simply avoid using PfBlockerNG.
I would prefer that this thread NOT be marked as resolved, but I'm sure the mods like johnpoz know better than myself whether or not to mark it as such under these conditions.
-
Helping the community would be solving your issue - since if they feel they have the same issue they could find the solution. Asking for help, then not posting the required information because your worried some lan rules are going to compromise your security is just a waste of everyone's time..
Good luck!
-
What ??
This :
can compromise my network ?
Yep, guess so, having a VPN port open ... => may day ....
-
We don't even need to see his wan... We would need to see his lan side rules.
OMG... here are 2 of my most restrictive lan side interfaces rules... What is there that could compromise anything?
Is it that you know I allow dns to 192.168.3.10 from my w_psk network? I can see the concern ;) <rolleyes>
-
Really hard, if not impossible, to help you without seeing your firewall rules on WLAN.
But there is something to this. It is the combination of both the pass NAT rule and NAT reflection (which is also enabled on the port forward installed by the package).
# NAT Inbound Redirects rdr pass on re0 proto tcp from any to 10.10.10.1 port 80 -> 127.0.0.1 port 8081 # Reflection redirect rdr pass on { re2 enc0 openvpn } proto tcp from any to 10.10.10.1 port 80 -> 127.0.0.1 port 8081 rdr pass on re0 proto tcp from any to 10.10.10.1 port 443 -> 127.0.0.1 port 8443 # Reflection redirect rdr pass on { re2 enc0 openvpn } proto tcp from any to 10.10.10.1 port 443 -> 127.0.0.1 port 8443re0 is LAN, re2 is OPT1
OPT1 has no rules on it. Can access 10.10.10.1 on 80 and 443. Because the traffic is passed by the port forward.
The ruleset is just doing what it has been told to do.
This is not a NAT issue but a pfBlockerNG issue. Moving there.
-
This post is deleted!
