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

    Performance regression 2.7.2 to 2.8

    Scheduled Pinned Locked Moved General pfSense Questions
    57 Posts 5 Posters 5.8k 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.
    • fatheadF
      fathead @stephenw10
      last edited by

      @stephenw10
      Firewall rule set to pass LAN subnets to 64:ff9b::c0a8:100/120
      64:ff9b::c0a8:101(pfSense it self) was the only address replying.

      tcpdump on pfSense show the wrong ip(the VIP) and not the interface IP(192.168.1.1).
      Removing all v4 VIPs from lan restores reachabilit. v4 VIPs on localhost are different some how.
      Before:

      16:52:35.520044 IP 10.0.0.1 > 192.168.1.100: ICMP echo request, id 179, seq 1, length 64

      After v4 VIPs removed:

      17:08:30.209222 IP 192.168.1.1 > 192.168.1.100: ICMP echo request, id 182, seq 10740, length 64
17:08:30.209351 IP 192.168.1.100 > 192.168.1.1: ICMP echo reply, id 182, seq 10740, length 64

      The 64:ff9b::c0a8:100/120 rule is above the 64:ff9b::/96 rule.
      NAT64 and v4 VIPs alias on wan and/or lan are not playing nicely.

      1 Reply Last reply Reply Quote 0
      • M
        marcosm Netgate
        last edited by marcosm

        The issue is that the "Automatic" NAT64 source option in the rule leaves things up to the OS itself. Hence the source tends to be the first address on the interface (e.g. 10.0.0.1). To address that issue a GUI option exists to override the source. For example:
        5bb6039e-5ddf-4b3d-85a7-4fde4e0b4b14-image.png

        fatheadF 1 Reply Last reply Reply Quote 0
        • fatheadF
          fathead @marcosm
          last edited by

          @marcosm The source has always been set to "LAN subnets".

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            It's the 'Address Family Translation' source that must be set to 'LAN address' rather than the default 'Automatic' where it's choosing the VIP.

            fatheadF 1 Reply Last reply Reply Quote 0
            • fatheadF
              fathead @stephenw10
              last edited by

              @stephenw10
              'Address Family Translation' is also set to 'LAN address'.

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                Hmm, then maybe it's not matching the test traffic somehow?

                fatheadF 1 Reply Last reply Reply Quote 0
                • fatheadF
                  fathead @stephenw10
                  last edited by

                  @stephenw10

                  Hmm, then maybe it's not matching the test traffic somehow?

                  How to see what it is matching with?

                  For testing, made a do nothing OPT1, setting v4 VIPs on loopback and OPT1 does not seem break lan to lan or lan to wan.

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    Mmm, I'd only expect the VIP to make any difference on LAN. For some reason it's choosing to use the first IP on the interface (the VIP) as the source for the translation.

                    If you run pfctl -vss you can see the states with the rules that created them.

                    Then if you run pfctl -vvsr you can see the ruleset with numbers to see what the rule is.

                    However since this is a NAT64 rule I'm not 100% sure how it will appear!

                    fatheadF 1 Reply Last reply Reply Quote 0
                    • fatheadF
                      fathead @stephenw10
                      last edited by

                      @stephenw10

                      Mmm, I'd only expect the VIP to make any difference on LAN.

                      Exactly, 64:ff9b::c0a8:100/120 is affected by ipv4 LAN VIPs.

                      pfctl -vss

                      igb1 ipv6-icmp 10.0.0.4:1 (fd22::8[1]) -> 192.168.1.100:8 (64:ff9b::c0a8:164[1])       NO_TRAFFIC:NO_TRAFFIC
   age 00:00:18, expires in 00:00:07, 4:4 pkts, 320:240 bytes, rule 117

                      pfctl -vvsr

                      @117 pass in quick on igb1 inet6 from fd22::/64 to 64:ff9b::c0a8:100/120 flags S/SA keep state (if-bound) label "USER_RULE" label "id:1748759142" ridentifier 1748759142 af-to inet from (igb1)
  [ Evaluations: 760       Packets: 52        Bytes: 3640        States: 1     ]
                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        Ok I think we see a problem here. Digging...

                        1 Reply Last reply Reply Quote 0
                        • M
                          marcosm Netgate
                          last edited by

                          Thanks for testing! A redmine has been created for this issue:
                          https://redmine.pfsense.org/issues/16250

                          A patch is available there to test with the System Patches package; make sure to reload the filter under Status > Filter Reload after applying the patch.

                          fatheadF 2 Replies Last reply Reply Quote 1
                          • fatheadF
                            fathead @marcosm
                            last edited by

                            @marcosm
                            Patch is working for this.

                            1 Reply Last reply Reply Quote 1
                            • fatheadF
                              fathead @marcosm
                              last edited by

                              @marcosm
                              So how does this work?
                              64:ff9b::/96 automatic, is the wan address always used for this?

                              igb1 ipv6-icmp 100.92.34.122:1 (fd22::8[1]) -> 192.168.1.100:8 (64:ff9b::c0a8:164[1])       NO_TRAFFIC:NO_TRAFFIC
   age 00:00:10, expires in 00:00:10, 3:3 pkts, 240:180 bytes, rule 115
@115 pass in quick on igb1 inet6 from fd22::/64 to 64:ff9b::/96 flags S/SA keep state (if-bound) label "USER_RULE: Default Allow IPv6 to IPv4 via NAT64" label "id:1748759054" ridentifier 1748759054 af-to inet from (pppoe0)
  [ Evaluations: 8186      Packets: 2840190   Bytes: 2861343252  States: 9     ]
  [ Inserted: uid 0 pid 0 State Creations: 17    ]
  [ Last Active Time: Tue Jun 10 03:09:22 2025 ]
                              1 Reply Last reply Reply Quote 0
                              • stephenw10S
                                stephenw10 Netgate Administrator
                                last edited by

                                Yes by default it uses the first address of whatever interface that traffic is leaving from. Hence the rule for LAN tried to the use the VIP there before the source was set correctly.

                                fatheadF 1 Reply Last reply Reply Quote 0
                                • fatheadF
                                  fathead @stephenw10
                                  last edited by

                                  @stephenw10
                                  Always uses the default gateway?

                                  1 Reply Last reply Reply Quote 0
                                  • stephenw10S
                                    stephenw10 Netgate Administrator
                                    last edited by

                                    It would be routed like any other traffic. So to local subnets or via the default route.

                                    I don't about policy routing, I've never tried that for NAT64. I know we don't have port forwarding for it yet.

                                    1 Reply Last reply Reply Quote 0
                                    • stephenw10S
                                      stephenw10 Netgate Administrator
                                      last edited by

                                      This post is deleted!
                                      1 Reply Last reply Reply Quote 0
                                      • stephenw10S
                                        stephenw10 Netgate Administrator
                                        last edited by

                                        Looks like route-to (policy based routing) should work with NAT64.

                                        fatheadF 1 Reply Last reply Reply Quote 0
                                        • stephenw10S
                                          stephenw10 Netgate Administrator
                                          last edited by

                                          This post is deleted!
                                          1 Reply Last reply Reply Quote 0
                                          • fatheadF
                                            fathead @stephenw10
                                            last edited by fathead

                                            @stephenw10
                                            Hmm, so does policy based routing not affect the loopback?

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