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

    Should Port Forwards work with Interface Groups?

    Scheduled Pinned Locked Moved NAT
    12 Posts 3 Posters 680 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.
    • M
      marcg
      last edited by marcg

      Should port forwards work when an Interface Group is set as the "interface" in the port forward rule? Doesn't seem to work in my case (24.11 on third-party hardware).

      I want to redirect all local v4 and v6 DNS requests to the pfSense. Following the template here, I created a port 53 DNAT to redirect traffic to 127.0.0.1 for v4 and a corresponding to ::1 for v6 on one interface, E1V15 (igc1.15). That works (example of what doesn't work next). There's no port 53 traffic to external DNS servers per tcpdump, and pfctl -vvs nat shows the following rule hits after 5 minutes of operation on a small network.

      @38 rdr on igc1.15 inet proto tcp from any to ! (self:12) port = domain -> 127.0.0.1
        [ Evaluations: 941       Packets: 0         Bytes: 0           States: 0     ]
        [ Inserted: uid 0 pid 0 State Creations: 0     ]
        [ Last Active Time: N/A ]
      @39 rdr on igc1.15 inet proto udp from any to ! (self:12) port = domain -> 127.0.0.1
        [ Evaluations: 166       Packets: 153       Bytes: 15108       States: 16    ]
        [ Inserted: uid 0 pid 0 State Creations: 73    ]
        [ Last Active Time: N/A ]
      @40 rdr on igc1.15 inet6 proto tcp from any to ! 2600:xxx:e63a:6eff:fe61:c5ee port = domain -> ::1
        [ Evaluations: 822       Packets: 0         Bytes: 0           States: 0     ]
        [ Inserted: uid 0 pid 0 State Creations: 0     ]
        [ Last Active Time: N/A ]
      @41 rdr on igc1.15 inet6 proto udp from any to ! 2600:xxx:e63a:6eff:fe61:c5ee port = domain -> ::1
        [ Evaluations: 261       Packets: 69        Bytes: 6215        States: 15    ]
        [ Inserted: uid 0 pid 0 State Creations: 69    ]
        [ Last Active Time: N/A ]
      

      I want this same behavior on three interfaces: E1V15, E1V20, E1V40. Rather than replicating the rules, I created an Interface Group containing those interfaces.

      eadd505d-42f1-49ee-90c2-84900392b186-image.png

      I then created v4 and v6 rules using the Interface Group as interface rather than an individual interface. The v4 rule looks as follows.

      45573cc0-687f-4b90-889b-a4dcfdf5e4c6-image.png

      These Interface Group based rules don't seem to work. Client DNS requests to external servers are honored and there's corresponding port 53 traffic on the WAN interface. After 5 minutes with these rules in place, it seems that the rules are being evaluated but no NAT taking place.

      @38 rdr on DNS_Redir_LANs inet proto tcp from any to ! (self:12) port = domain -> 127.0.0.1
        [ Evaluations: 812       Packets: 0         Bytes: 0           States: 0     ]
        [ Inserted: uid 0 pid 0 State Creations: 0     ]
        [ Last Active Time: N/A ]
      @39 rdr on DNS_Redir_LANs inet proto udp from any to ! (self:12) port = domain -> 127.0.0.1
        [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
        [ Inserted: uid 0 pid 0 State Creations: 0     ]
        [ Last Active Time: N/A ]
      @40 rdr on DNS_Redir_LANs inet6 proto tcp from any to ! (self:16) port = domain -> ::1
        [ Evaluations: 541       Packets: 0         Bytes: 0           States: 0     ]
        [ Inserted: uid 0 pid 0 State Creations: 0     ]
        [ Last Active Time: N/A ]
      @41 rdr on DNS_Redir_LANs inet6 proto udp from any to ! (self:16) port = domain -> ::1
        [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
        [ Inserted: uid 0 pid 0 State Creations: 0     ]
        [ Last Active Time: N/A ]
      
      
      
      Bob.DigB 1 Reply Last reply Reply Quote 0
      • Bob.DigB
        Bob.Dig LAYER 8 @marcg
        last edited by

        @marcg said in Should Port Forwards work with Interface Groups?:

        Should port forwards work when an Interface Group is set as the "interface" in the port forward rule?

        No. I think this is right in the Docs.

        M 1 Reply Last reply Reply Quote 0
        • M
          marcg @Bob.Dig
          last edited by

          @Bob-Dig said in Should Port Forwards work with Interface Groups?:

          @marcg said in Should Port Forwards work with Interface Groups?:

          Should port forwards work when an Interface Group is set as the "interface" in the port forward rule?

          No. I think this is right in the Docs.

          Thanks for the response. Where do you see that in the docs? The second sentence here says Interface groups are used to apply firewall or NAT rules to a set of interfaces on a common tab.

          I set up the Interface Group based on an earlier exchange. Perhaps I misunderstood.

          Bob.DigB 1 Reply Last reply Reply Quote 0
          • Bob.DigB
            Bob.Dig LAYER 8 @marcg
            last edited by Bob.Dig

            @marcg said in Should Port Forwards work with Interface Groups?:

            Perhaps I misunderstood.

            Oops, I misunderstood.

            Here is what is working for me. Filter rule association is pass (at the bottom).

            Screenshot 2024-12-28 at 18-17-50 pfSense.internal - Firewall NAT Port Forward Edit.png

            If it is still not working, show all of your NAT rules and firewall rules in floating and in the groups. 😉

            M 1 Reply Last reply Reply Quote 1
            • M
              marcg @Bob.Dig
              last edited by marcg

              @Bob-Dig Thanks. The trick was to change the last two settings from this, which worked fine with interface-specific rules,

              f67f4aa0-55f8-4379-bbc3-65f985130ce3-image.png

              to this.

              9b87448d-e888-48e0-bda9-18fd9519498e-image.png

              My system default NAT reflection policy is NAT+Proxy, which is incompatible with v6 per the tool tips. The Pass rule wasn't necessary since the relevant subnets all allow hosts to connect to non-management pfSense services including DNS.

              That said, there is still a weirdness. Even though I have only three interfaces in the interface group (igc1.15, .20, .40 or E1V15, E1V20, E1V40),

              d3631876-4199-4a18-b605-929d9885004b-image.png

              there are DNS redirects on every interface in the system.

              Would you issue the same command as below to see whether there are unexpected redirects on your box?

              [24.11-RELEASE][admin@pfSense.home.arpa]/root: pfctl -s nat | grep domain | sort +2
              rdr on DNS_Redir_LANs inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
              rdr on DNS_Redir_LANs inet proto udp from any to ! (self) port = domain -> 127.0.0.1
              rdr on DNS_Redir_LANs inet6 proto tcp from any to ! (self) port = domain -> ::1
              rdr on DNS_Redir_LANs inet6 proto udp from any to ! (self) port = domain -> ::1
              rdr on Tailscale inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
              rdr on Tailscale inet proto udp from any to ! (self) port = domain -> 127.0.0.1
              rdr on Tailscale inet6 proto tcp from any to ! (self) port = domain -> ::1
              rdr on Tailscale inet6 proto udp from any to ! (self) port = domain -> ::1
              rdr on WireGuard inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
              rdr on WireGuard inet proto udp from any to ! (self) port = domain -> 127.0.0.1
              rdr on WireGuard inet6 proto tcp from any to ! (self) port = domain -> ::1
              rdr on WireGuard inet6 proto udp from any to ! (self) port = domain -> ::1
              rdr on igc1 inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
              rdr on igc1 inet proto udp from any to ! (self) port = domain -> 127.0.0.1
              rdr on igc1 inet6 proto tcp from any to ! (self) port = domain -> ::1
              rdr on igc1 inet6 proto udp from any to ! (self) port = domain -> ::1
              rdr on igc1.15 inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
              rdr on igc1.15 inet proto udp from any to ! (self) port = domain -> 127.0.0.1
              rdr on igc1.15 inet6 proto tcp from any to ! (self) port = domain -> ::1
              rdr on igc1.15 inet6 proto udp from any to ! (self) port = domain -> ::1
              rdr on igc1.20 inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
              rdr on igc1.20 inet proto udp from any to ! (self) port = domain -> 127.0.0.1
              rdr on igc1.20 inet6 proto tcp from any to ! (self) port = domain -> ::1
              rdr on igc1.20 inet6 proto udp from any to ! (self) port = domain -> ::1
              rdr on igc1.40 inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
              rdr on igc1.40 inet proto udp from any to ! (self) port = domain -> 127.0.0.1
              rdr on igc1.40 inet6 proto tcp from any to ! (self) port = domain -> ::1
              rdr on igc1.40 inet6 proto udp from any to ! (self) port = domain -> ::1
              rdr on igc2 inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
              rdr on igc2 inet proto udp from any to ! (self) port = domain -> 127.0.0.1
              rdr on igc2 inet6 proto tcp from any to ! (self) port = domain -> ::1
              rdr on igc2 inet6 proto udp from any to ! (self) port = domain -> ::1
              rdr on igc3 inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
              rdr on igc3 inet proto udp from any to ! (self) port = domain -> 127.0.0.1
              rdr on igc3 inet6 proto tcp from any to ! (self) port = domain -> ::1
              rdr on igc3 inet6 proto udp from any to ! (self) port = domain -> ::1
              rdr on tun_wg0 inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
              rdr on tun_wg0 inet proto udp from any to ! (self) port = domain -> 127.0.0.1
              rdr on tun_wg0 inet6 proto tcp from any to ! (self) port = domain -> ::1
              rdr on tun_wg0 inet6 proto udp from any to ! (self) port = domain -> ::1
              rdr on tun_wg1 inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
              rdr on tun_wg1 inet proto udp from any to ! (self) port = domain -> 127.0.0.1
              rdr on tun_wg1 inet6 proto tcp from any to ! (self) port = domain -> ::1
              rdr on tun_wg1 inet6 proto udp from any to ! (self) port = domain -> ::1
              

              There are rule hits on those other interfaces, too. Here's an example for igc2, which is not in the interface group. igc2 is on a v4-only network.

              [24.11-RELEASE][admin@pfSense.home.arpa]/root: pfctl -vs nat | awk '/igc2.*domain/{found=1}found>=1{found++;print$0;if(found==4)found=0}'
              rdr on igc2 inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
                [ Evaluations: 1063      Packets: 0         Bytes: 0           States: 0     ]
                [ Inserted: uid 0 pid 0 State Creations: 0     ]
              rdr on igc2 inet proto udp from any to ! (self) port = domain -> 127.0.0.1
                [ Evaluations: 501       Packets: 536       Bytes: 47200       States: 8     ]
                [ Inserted: uid 0 pid 0 State Creations: 282   ]
              rdr on igc2 inet6 proto tcp from any to ! (self) port = domain -> ::1
                [ Evaluations: 540       Packets: 0         Bytes: 0           States: 0     ]
                [ Inserted: uid 0 pid 0 State Creations: 0     ]
              rdr on igc2 inet6 proto udp from any to ! (self) port = domain -> ::1
                [ Evaluations: 0         Packets: 0         Bytes: 0           States: 0     ]
                [ Inserted: uid 0 pid 0 State Creations: 0     ]```
              Bob.DigB 1 Reply Last reply Reply Quote 0
              • Bob.DigB
                Bob.Dig LAYER 8 @marcg
                last edited by

                @marcg said in Should Port Forwards work with Interface Groups?:

                My system default NAT reflection policy is NAT+Proxy

                This is not advised. I would change this immediately. Can you not use Split-DNS? How many subnets with clients do you have, where this is needed?

                chpalmerC 1 Reply Last reply Reply Quote 0
                • chpalmerC
                  chpalmer @Bob.Dig
                  last edited by

                  @Bob-Dig

                  Not advised by a few purists.. but Ive never seen anyone say it is not safe for some reason..

                  Triggering snowflakes one by one..
                  Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

                  Bob.DigB 1 Reply Last reply Reply Quote 0
                  • Bob.DigB
                    Bob.Dig LAYER 8 @chpalmer
                    last edited by Bob.Dig

                    @chpalmer said in Should Port Forwards work with Interface Groups?:

                    Not advised by a few purists..

                    It is just a mess, it will create port forwards on every interface with is most probably unnecessary, at least with PureNAT. NAT + Proxy is even worse I think. And it makes problems like in this example.

                    chpalmerC 1 Reply Last reply Reply Quote 0
                    • chpalmerC
                      chpalmer @Bob.Dig
                      last edited by

                      @Bob-Dig said in Should Port Forwards work with Interface Groups?:

                      it will create port forwards on every interface

                      This is the first time I have ever heard/read that.. But still not a reason to "change that immediately".. I know a few people that I work with that would drive to one of our remote sites in the middle of the night if they were told that.. 😅 (of coarse they make more overtime than I do so maybe panic is the way..??)

                      But that said I would still like to know more why so many seem to panic when someone comes along and sets things up that way.

                      Not to hijack this thread but it would be nice to see a thread on this very subject with solid reasons for and against.

                      Triggering snowflakes one by one..
                      Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

                      Bob.DigB M 2 Replies Last reply Reply Quote 0
                      • Bob.DigB
                        Bob.Dig LAYER 8 @chpalmer
                        last edited by Bob.Dig

                        @chpalmer said in Should Port Forwards work with Interface Groups?:

                        This is the first time I have ever heard/read that..

                        Lets say you make PureNAT the default... then every Port Forward will be replicated to every Interface. Lets say you have a lot of Port Forwards and a lot of Interfaces, this is just messy. At least this is what I have read. You probably can see it yourself in rules.debug.

                        1 Reply Last reply Reply Quote 0
                        • M
                          marcg @chpalmer
                          last edited by

                          @chpalmer @Bob-Dig

                          A few things.

                          • Thanks for the insights.
                          • The use case is redirecting DNS from local clients with hardwired DNS servers (IoT, etc.) to the pfSense. Split horizon wouldn't accomplish that.
                          • It's now working as expected/desired by switching NAT reflection in the rules to None. Exactly four rules, they're logging hits, no errant port 53 requests out the WAN interface. This is the setup (I'm pretty sure) I had before. Don't know why it's working now, although I did delete the interface group and NAT rules, rebooted, and recreated them.
                          [24.11-RELEASE][admin@pfSense.home.arpa]/root: pfctl -s nat | grep domain
                          rdr on DNS_Redir_LANs inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
                          rdr on DNS_Redir_LANs inet proto udp from any to ! (self) port = domain -> 127.0.0.1
                          rdr on DNS_Redir_LANs inet6 proto tcp from any to ! (self) port = domain -> ::1
                          rdr on DNS_Redir_LANs inet6 proto udp from any to ! (self) port = domain -> ::1
                          [24.11-RELEASE][admin@pfSense.home.arpa]/root: pfctl -vs nat | awk '/domain/{found=1}found>=1{found++;print$0;if(found==4)found=0}'
                          rdr on DNS_Redir_LANs inet proto tcp from any to ! (self) port = domain -> 127.0.0.1
                            [ Evaluations: 2307      Packets: 164       Bytes: 9278        States: 0     ]
                            [ Inserted: uid 0 pid 0 State Creations: 15    ]
                          rdr on DNS_Redir_LANs inet proto udp from any to ! (self) port = domain -> 127.0.0.1
                            [ Evaluations: 1067      Packets: 481       Bytes: 42413       States: 5     ]
                            [ Inserted: uid 0 pid 0 State Creations: 122   ]
                          rdr on DNS_Redir_LANs inet6 proto tcp from any to ! (self) port = domain -> ::1
                            [ Evaluations: 811       Packets: 0         Bytes: 0           States: 0     ]
                            [ Inserted: uid 0 pid 0 State Creations: 0     ]
                          rdr on DNS_Redir_LANs inet6 proto udp from any to ! (self) port = domain -> ::1
                            [ Evaluations: 370       Packets: 114       Bytes: 10182       States: 4     ]
                            [ Inserted: uid 0 pid 0 State Creations: 91    ]
                          
                          • @Bob-Dig what is your default NAT reflection policy?
                          • I need to educate myself on NAT reflection. NAT+Proxy has been the default on my system since I brought up pfSense. Have not experienced issues with it in the past, but this is the first time I've really dug into the NAT rules that are created. As mentioned, NAT+Proxy is incompatible with IPv6 per the GUI. And Pure NAT, in this episode, absolutely created additional undesirable rules.
                          Bob.DigB 1 Reply Last reply Reply Quote 0
                          • Bob.DigB
                            Bob.Dig LAYER 8 @marcg
                            last edited by

                            @marcg said in Should Port Forwards work with Interface Groups?:

                            default NAT reflection policy?

                            Disabled.

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