Performance regression 2.7.2 to 2.8

fathead

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     ]

stephenw10

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

marcosm

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.

fathead

@marcosm
Patch is working for this.

fathead

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

stephenw10

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.

fathead

@stephenw10
Always uses the default gateway?

stephenw10

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.

stephenw10

This post is deleted!

stephenw10

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

stephenw10

This post is deleted!

fathead

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

stephenw10

No. YOu can only policy route traffic as it enters the firewall so usually from some internal subnet. Traffic from localhost is already inside the firewall. By the time it is leaving an interface and could be filtered outbound the routing decision has already been taken.