Bug #11814
closedUnexpected pf round-robin for rdr
0%
Description
What causes the generation of multiple round-robin rdr rules, one for each interface when I have a straight forward firewall/nat/port-forward entry? For example if I create a rule on on my first openvpn tunnel (ovpns1):
<nat>
<rule>
<source>
<any></any>
</source>
<destination>
<address>10.4.0.100</address>
<port>22</port>
</destination>
<ipprotocol>inet</ipprotocol>
<protocol>tcp</protocol>
<target>172.16.0.2</target>
<local-port>22</local-port>
<interface>opt2</interface>
<descr><![CDATA[test rdr]]></descr>
<associated-rule-id>nat_607c5ae2abe685.31088551</associated-rule-id>
<updated>
<time>1618762466</time>
<username><![CDATA[admin@fd:1965::2 (Local Database)]]></username>
</updated>
<created>
<time>1618762466</time>
<username><![CDATA[admin@fd:1965::2 (Local Database)]]></username>
</created>
</rule>
</nat>
Results in this pf config:
rdr on ovpns1 inet proto tcp from any to 10.4.0.100 port = ssh -> 172.16.0.2
rdr on mvneta0.4091 inet proto tcp from any to 10.4.0.100 port = ssh -> 172.16.0.2
rdr on mvneta0.4092 inet proto tcp from any to 10.4.0.100 port = ssh -> 172.16.0.2
rdr on mvneta0.1000 inet proto tcp from any to 10.4.0.100 port = ssh -> 172.16.0.2
rdr on mvneta0.1010 inet proto tcp from any to 10.4.0.100 port = ssh -> 172.16.0.2
rdr on mvneta0.1020 inet proto tcp from any to 10.4.0.100 port = ssh -> 172.16.0.2
rdr on mvneta0.2001 inet proto tcp from any to 10.4.0.100 port = ssh -> 172.16.0.2
rdr on openvpn inet proto tcp from any to 10.4.0.100 port = ssh -> 172.16.0.2
I can see an interface entry for <opt2> that has <if>ovpns2</if> so why don't I get a single rule with that interface? Has my config become corrupt?
I would prefer not to post my config but I can share it offline.
Updated by Craig Leres over 3 years ago
Ok, after playing with a spare box for a few hours I see now that round-robin for the extra interfaces are due to having "nat reflection mode for port forwards" set to "pure nat" in system/advanced/firewall&nat. And given that I hadn't changed "nat reflect" in any rdr rules I added, this eliminated the rdr+round-robin rules for un-associated interfaces.
This looks like an interesting feature but not specifically useful for me.
Updated by Jim Pingle over 3 years ago
- Status changed from New to Not a Bug
That's expected behavior. It isn't round-robin. They are separate rules which catch inbound traffic on the other interfaces.
If it were round-robin it would have multiple destinations in a single rule.