Port forward rules ignoring interface
Slugger last edited by
Running v2.4.4p3. I setup pfBlockerNG and so I wanted to force all of my vlans to use pfsense for dns via port forwarding, except one. The p2p vlan policy routes all traffic thru a vpn and so I have it setup to use the vpn provider's dns servers instead and I don't want to change that. This vlan also can't access any other vlan, which is why I ran into this problem.
Here are my port forward rules:
After I created these rules, my P2P vlan lost internet connectivity. Well, it lost the ability to resolve dns. I enabled some logging on some firewall rules on the P2P interface and found this:
The dns servers for that host are external IPs for the vpn service's dns servers and they're being rewritten to the LAN's IP but the P2P vlan can't talk to any other vlan. If I disable the LAN port forward rule then I get the same blocked logs but for the MGMT IP, etc. Basically, whatever rule is at the top of the port forward rules is what the address gets rewritten as. I'm expecting dns queries from the P2P vlan not to be rewritten at all as they shouldn't be matching any of these rules (based on the interface alone).
Additional testing has proven that the first rule matches for any interface. I just didn't notice immediately after setting this up because LAN (my day to day vlan) happened to be the first rule and the MGMT vlan can go to any other vlan so the fact that it was being redirected to the LAN address didn't matter. But dns queries from the GUEST and IOT interfaces not destined for pfsense are also being redirected to the LAN address instead of their proper vlan addresses and these vlans can't talk to LAN either so they're being blocked.
I feel like I'm misunderstanding how to set this up properly since googling the issue basically found nothing similar and if this were a pfsense bug many others would have hit it long before me and reported it here, I'm sure. So can someone explain what I'm doing wrong? :)
Slugger last edited by
After rereading this and reviewing
/tmp/rules.debug, it seemed I had the NAT reflection enabled on these rules and those generated reflection rules is what was matching unexpectedly and why it was always matching the top rule in the list. Once I disabled NAT reflection on these specific rules, everything started working as expected.