Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Port Forwarding - "Pass" Filter Rule Doesn't Limit to Selected Interface Traffic

    Scheduled Pinned Locked Moved pfBlockerNG
    10 Posts 5 Posters 1.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      Drountian
      last edited by Drountian

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

      BBcan177B 1 Reply Last reply Reply Quote 0
      • johnpozJ
        johnpoz LAYER 8 Global Moderator
        last edited by

        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.

        An intelligent man is sometimes forced to be drunk to spend time with his fools
        If you get confused: Listen to the Music Play
        Please don't Chat/PM me for help, unless mod related
        SG-4860 24.11 | Lab VMs 2.8, 24.11

        1 Reply Last reply Reply Quote 0
        • D
          Drountian
          last edited by Drountian

          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. :)
          0_1536521954110_Port Forward (when it works).png
          Associated rule (on LAN):
          0_1536521729325_The Associated Firewall Rule (when it works).png

          That said PfBlockerNG generates the port forward like this (every hour) :(

          0_1536522051689_Port Forward.PNG

          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

          0_1536522150408_Floating Rules.PNG

          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?

          johnpozJ 1 Reply Last reply Reply Quote 0
          • johnpozJ
            johnpoz LAYER 8 Global Moderator @Drountian
            last edited by johnpoz

            @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!!

            An intelligent man is sometimes forced to be drunk to spend time with his fools
            If you get confused: Listen to the Music Play
            Please don't Chat/PM me for help, unless mod related
            SG-4860 24.11 | Lab VMs 2.8, 24.11

            1 Reply Last reply Reply Quote 0
            • D
              Drountian
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • johnpozJ
                johnpoz LAYER 8 Global Moderator
                last edited by

                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!

                An intelligent man is sometimes forced to be drunk to spend time with his fools
                If you get confused: Listen to the Music Play
                Please don't Chat/PM me for help, unless mod related
                SG-4860 24.11 | Lab VMs 2.8, 24.11

                1 Reply Last reply Reply Quote 0
                • GertjanG
                  Gertjan
                  last edited by Gertjan

                  What ??

                  This :

                  0_1536573782206_bbdba882-e181-47b5-8e2a-ad2190e9a277-image.png

                  can compromise my network ?

                  Yep, guess so, having a VPN port open ... => may day ....

                  No "help me" PM's please. Use the forum, the community will thank you.
                  Edit : and where are the logs ??

                  1 Reply Last reply Reply Quote 0
                  • johnpozJ
                    johnpoz LAYER 8 Global Moderator
                    last edited by johnpoz

                    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?

                    0_1536573941572_rules.png

                    Is it that you know I allow dns to 192.168.3.10 from my w_psk network? I can see the concern ;) <rolleyes>

                    An intelligent man is sometimes forced to be drunk to spend time with his fools
                    If you get confused: Listen to the Music Play
                    Please don't Chat/PM me for help, unless mod related
                    SG-4860 24.11 | Lab VMs 2.8, 24.11

                    1 Reply Last reply Reply Quote 0
                    • DerelictD
                      Derelict LAYER 8 Netgate
                      last edited by Derelict

                      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 8443
                      

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

                      Chattanooga, Tennessee, USA
                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

                      1 Reply Last reply Reply Quote 0
                      • BBcan177B
                        BBcan177 Moderator @Drountian
                        last edited by

                        This post is deleted!
                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.