Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nat port forward redirect rule redirects all internal interface traffic, even if it's an unselected interface in the rule #7884

Closed
2 tasks done
Unspec7 opened this issue Sep 23, 2024 · 1 comment
Labels
support Community support

Comments

@Unspec7
Copy link

Unspec7 commented Sep 23, 2024

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

Describe the bug

I have a firewall group called CommonDNS that enforces my pihole DNS. It includes the LAN, and VLAN's MGMT, USER, and IOT. I have a GUEST VLAN that is not pi-hole enforced to ensure the privacy of my guests, and GUEST just uses quad9.

The CommonDNS is enforced by a RDR rule that redirects any port 53 traffic that isn't sent to my pihole to get redirected to my pihole, operating on the CommonDNS group. However, when CommonDNS is selected, even GUEST network is caught by the redirect rule. Selecting USER as the only interface to get RDR'd also results in GUEST being RDR'd.

My network is set up so that LAN is on its own line, and VLAN's on their own dedicated trunk from my switch to igb2. igb0 is WAN, igb1 is LAN, and ign3 is unused for the time being.

To Reproduce

Steps to reproduce the behavior:

  1. Create RDR rule
  2. Create multiple VLAN interfaces
  3. Create RDR rule and only select one interface
  4. View logs and observe that all VLAN interfaces are now being redirected, rather than just what was selected

Expected behavior

Only redirect traffic for selected interfaces

Describe alternatives you considered

No possible alternatives available

Screenshots

image

image

image

Software version:

OPNsense 24.7.4_1
Intel i5 8500

@AdSchellevis AdSchellevis added the support Community support label Sep 23, 2024
@Unspec7
Copy link
Author

Unspec7 commented Oct 6, 2024

Closing this in favor of #7952, the actual root cause of the issue.

@Unspec7 Unspec7 closed this as completed Oct 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
support Community support
Development

No branches or pull requests

2 participants