View Single Post
  #2   (View Single Post)  
Old 30th September 2016
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,975
Default

There's no logical or in PF rule syntax. But match rules are sticky, and it is possible that there is an error in how static-port "stickiness" is applied.

You might try something that avoids any logical "not" structures, to test if there is a stickiness problem. The general NAT rule we all use includes a logical not-egress. We use the not-egress form because we want to NAT traffic from non-egress network interfaces:
Code:
match out on egress from !(egress) nat-to (egress)
This substitute avoids the logical not structure:
Code:
internal_interfaces="{em2 vr3}"
match out on egress from $internal_interfaces nat-to (egress)
That will be expanded to two general-case match rules, one for each interface.
Then we can add the specific use-case for static ports:
Code:
internal_interfaces="{em2 vr3}"
match out on egress from $internal_interfaces nat-to (egress)
match out on egress from {$xbox $ps4} nat-to (egress) static-port
That will expand to two match rules with static-port applied. If it doesn't work, you will have clear indication that dynamic port stickiness might not be overridden in a subsequent match rule. The next test would be to use pass rules with nat-to, rather than match rules, as they are not sticky. If you get different results with pass, you will have something you can discuss with Project developers on misc@, or perhaps bugs@.

I have never used static-port, and just use rdr-to to pass specific ports to devices on the local networks through NAT.
Reply With Quote