Port forward on one interface incorrectly triggers forward on another
-
Lets see these rule(s) you created... Lets see how you came to that conclusion.. Did you do a ! rule for this forward? Do you have some vips setup? It is a known issue that vips and ! rules can cause issues with how the rules get created.
Lets see your actual rules - you can view the actual rules order..
https://docs.netgate.com/pfsense/en/latest/firewall/viewing-the-full-pf-ruleset.html -
Please post your rules. Everything you have done to effect this scheme.
-
@Derelict said in Port forward on one interface incorrectly triggers forward on another:
Please post your rules. Everything you have done to effect this scheme.
Was my initial post too difficult to read and replicate?
Firewall rule for LAN interface:
Permit TCP/UDP source LAN net dest LAN address port 123Firewall rule for MGMT interface:
Permit TCP/UDP source MGMT net dest MGMT address port 123Port forward:
Interface LAN dest ! LAN address port NTP redirect [LAN gateway IP] port NTPEnabling this port forward changes the destination of NTP traffic on MGMT interface to the gateway IP address for LAN interface and the traffic is then blocked by the firewall, which shows this change in destination IP address.
Questions? Anyone successfully replicate?
-
@KnowledgeAddict024 said in Port forward on one interface incorrectly triggers forward on another:
Was my initial post too difficult to read and replicate?
Dude.. attitude is everything.. Everyone here that has been helping for literally years of their life sees newer users try and come here and prove that this product has errors.. errors that nobody else besides them can find.
We have tried to duplicate thousands (combined) of problems that people coming here have claimed with 99.9% of the time finding out that it is truly the loose nut behind the wheel.
If you were to combine the hours and hours of free tech support that forums users give here and equate it to cost Im pretty sure that Bill Gates himself would quiver at the cost.
If you come here with attitude.. your getting it right back at ya.
No. Nobody has had the exact problem you have had.. that at least has been correctly displayed here and proven to be a problem. Yes is it a lot to ask that someone volunteering for free on a forum take their time to try and duplicate your issue.. though most here probably will and if they can't duplicate it will stay silent as to not corrupt the issue.. just in case they did it wrong..
-
Post your actual rules. Not what you think you did but what you actually did.
-
You need to SHOW what you did, not say you did X... Users ALL the TIME!!! State they did X, but then when they actually show what they did it ends up being something long the lines Y+Z=Q/7
Post up the actual rules, I gave you the link how to do that... Are you running VIPs? How hard is a screenshot?
As stated I would be more than happy to try and duplicate what your doing..
Off the top of my head guess, is you handed client on the mgmt network the NTP of your lan IP... If your seeing blocks on the mgmt interface..
And lets ask again - do you have any VIPS.. Bang Rules (!) and vips don't like to play nice.
-
@chpalmer said in Port forward on one interface incorrectly triggers forward on another:
@KnowledgeAddict024 said in Port forward on one interface incorrectly triggers forward on another:
Was my initial post too difficult to read and replicate?
Dude.. attitude is everything..
Uh oh! It's the forum nanny again!
If you come here with attitude.. your getting it right back at ya.
Why do you think you've been getting it from me, dude? You jumped to conclusions about my post in the other guy's topic and made a fool of yourself. Just gonna come here and keep it up?
When did I ask if anyone has had the exact problem I've had? Are you even reading my posts?
I can tell you're one of those easily triggered people by the way you respond. You don't even read the words typed, just assume you are getting attitude and take immediate offense on behalf of all. Way to go, keyboard warrior.
@chpalmer said in Port forward on one interface incorrectly triggers forward on another:
Yes is it a lot to ask that someone volunteering for free on a forum take their time to try and duplicate your issue.. though most here probably will and if they can't duplicate it will stay silent as to not corrupt the issue.. just in case they did it wrong..
So let me get this straight. You're saying that most on this forum probably will volunteer their time to duplicate the issue despite it being a lot to ask; and once they have undertaken such a monumental task, instead of reporting feedback from all their time spent, you think they will just stay silent? OK dude. If you say so.
The thing is, I never asked for anyone to take time and duplicate this issue. I asked IF anyone has. Big difference. Again, don't jump to conclusions. You're right about the free tech support though. In reality, Netgate is (and all of you reading this are) also getting free tech support from me right now. I'm not here looking for help. I'm here TO help. Nobody has to help solve the issue if they don't want to. I'm just here to report a problem I found for the coders to fix (you're welcome, btw.) Help fix it, or don't. No sweat off my balls either way. But if you're not going to contribute anything toward resolving the issue and are just here to white-knight for the poor defenseless users and mods who can't speak up for themselves, then maybe you should create a separate forum topic to rant in or something so as not to clog up this topic with useless nonsense. Wouldn't want to be discussing things in the wrong topic, now would we?
-
@johnpoz said in Port forward on one interface incorrectly triggers forward on another:
You need to SHOW what you did, not say you did X... Users ALL the TIME!!! State they did X, but then when they actually show what they did it ends up being something long the lines Y+Z=Q/7
No doubt that is the case. Most users are incompetent.
Post up the actual rules, I gave you the link how to do that...
pfctl -sr
pass in quick on vtnet1 inet proto tcp from [LAN net]/24 to [LAN interface IP] port = ntp flags S/SA keep state label "USER_RULE: Allow access to NTP server on LAN"
pass in quick on vtnet1 inet proto udp from [LAN net]/24 to [LAN interface IP] port = ntp keep state label "USER_RULE: Allow access to NTP server on LAN"pass in quick on vtnet2 inet proto udp from <MGMT_servers> to [MGMT interface IP] port = ntp keep state label "USER_RULE: Allow MGMT servers access to local NTP"
pfctl -sn
no nat on vtnet1 inet proto tcp from (vtnet1) to [LAN interface IP] port = ntp
no nat on vtnet1 inet proto udp from (vtnet1) to [LAN interface IP] port = ntp
nat on vtnet1 inet proto tcp from [LAN net]/24 to [LAN interface IP] port = ntp -> [LAN interface IP] port 1024:65535
nat on vtnet1 inet proto udp from [LAN net]/24 to [LAN interface IP] port = ntp -> [LAN interface IP] port 1024:65535rdr on vtnet1 inet proto tcp from any to ! [LAN interface IP] port = ntp -> [LAN interface IP]
rdr on vtnet1 inet proto udp from any to ! [LAN interface IP] port = ntp -> [LAN interface IP]
rdr on vtnet2 inet proto tcp from any to ! [LAN interface IP] port = ntp -> [LAN interface IP]
rdr on vtnet2 inet proto udp from any to ! [LAN interface IP] port = ntp -> [LAN interface IP]
rdr on vtnet3 inet proto tcp from any to ! [LAN interface IP] port = ntp -> [LAN interface IP]
rdr on vtnet3 inet proto udp from any to ! [LAN interface IP] port = ntp -> [LAN interface IP]No, you cannot have the full output. As you can see, vtnet2 and vtnet3 (my DMZ net) are also getting redirect rules created by a port forward that should only be for vtnet1 (aka LAN.)
Are you running VIPs?
The only VIP is for pfb DNSBL to redirect advertising traffic to.
How hard is a screenshot?
Mildly annoying. What would you like a shot of?
As stated I would be more than happy to try and duplicate what your doing..
Off the top of my head guess, is you handed client on the mgmt network the NTP of your lan IP... If your seeing blocks on the mgmt interface..
Blocks only appear when port forward rule is active. If I disable it, the blocks stop because the destination IP of NTP packets coming into MGMT is no longer being modified from [MGMT interface IP] to [LAN interface IP] by the port forward which triggers the firewall alert.
And lets ask again - do you have any VIPS.. Bang Rules (!) and vips don't like to play nice.
No.
-
@KnowledgeAddict024 said in Port forward on one interface incorrectly triggers forward on another:
The only VIP is for pfb DNSBL to redirect advertising traffic to.
So you do have VIPs... VIPs and ! rule not play together nice
rdr on vtnet2 inet proto tcp from any to ! [LAN interface IP] port = ntp -> [LAN interface IP]
rdr on vtnet2 inet proto udp from any to ! [LAN interface IP] port = ntp -> [LAN interface IP]
rdr on vtnet3 inet proto tcp from any to ! [LAN interface IP] port = ntp -> [LAN interface IP]
rdr on vtnet3 inet proto udp from any to ! [LAN interface IP] port = ntp -> [LAN interface IP]So you created those rules!! Sorry but I just created a port forward on my lan.. And it doesn't create those. Or any other rules on any other interfaces.
Here are all my -sn
[2.4.4-RELEASE][admin@sg4860.local.lan]/root: pfctl -sn no nat proto carp all nat-anchor "natearly/*" all nat-anchor "natrules/*" all nat on ovpnc3 inet from 192.168.9.0/24 to any -> 172.27.240.2 port 1024:65535 nat on igb1 inet from <tonatsubnets> to any port = isakmp -> 64.53.x.x static-port nat on igb1 inet6 from <tonatsubnets> to any port = isakmp -> (igb1) round-robin static-port nat on igb1 inet from <tonatsubnets> to any -> 64.53.x.x port 1024:65535 nat on igb1 inet6 from <tonatsubnets> to any -> (igb1) port 1024:65535 round-robin no rdr proto carp all rdr-anchor "relayd/*" all rdr-anchor "tftp-proxy/*" all rdr on igb0 inet proto udp from any to ! 192.168.9.253 port = ntp -> 192.168.9.253 rdr on igb1 inet proto udp from <pfB_NAmerica_v4> to 64.53.x.x port = ntp -> 192.168.3.32 rdr on igb1 inet proto tcp from <pfB_AllowPfb_v4> to 64.53.x.x port = 23040 -> 192.168.9.10 port 32400 rdr-anchor "miniupnpd" all [2.4.4-RELEASE][admin@sg4860.local.lan]/root:No extra nats created there.. igb0 is my lan..
Why do you have those non nats and then nats to ALL ports?
Without you showing us what you have actually setup.. There is no way for us to help you figure out what you did wrong!
But sorry creating a port forward on LAN does not create port forwards on other interfaces... As you can clearly see from my screenshots and rule output above.
BTW - NTP never going to use tcp... So having that set in your rule is pointless nonsense..
You have pfblocker auto creating rules for you? Maybe it is doing that?
I changed the port forward to be udp/tcp - just to see if that could do it... And nope.. same thing.. Rule create where I created it..
[2.4.4-RELEASE][admin@sg4860.local.lan]/root: pfctl -sn no nat proto carp all nat-anchor "natearly/*" all nat-anchor "natrules/*" all nat on ovpnc3 inet from 192.168.9.0/24 to any -> 172.27.240.2 port 1024:65535 nat on igb1 inet from <tonatsubnets> to any port = isakmp -> 64.53.x.x static-port nat on igb1 inet6 from <tonatsubnets> to any port = isakmp -> (igb1) round-robin static-port nat on igb1 inet from <tonatsubnets> to any -> 64.53.x.x port 1024:65535 nat on igb1 inet6 from <tonatsubnets> to any -> (igb1) port 1024:65535 round-robin no rdr proto carp all rdr-anchor "relayd/*" all rdr-anchor "tftp-proxy/*" all rdr on igb0 inet proto tcp from 192.168.9.0/24 to ! 192.168.9.253 port = ntp -> 192.168.9.253 rdr on igb0 inet proto udp from 192.168.9.0/24 to ! 192.168.9.253 port = ntp -> 192.168.9.253 rdr on igb1 inet proto udp from <pfB_NAmerica_v4> to 64.53.x.x port = ntp -> 192.168.3.32 rdr on igb1 inet proto tcp from <pfB_AllowPfb_v4> to 64.53.x.x port = 23040 -> 192.168.9.10 port 32400 rdr-anchor "miniupnpd" all [2.4.4-RELEASE][admin@sg4860.local.lan]/root: -
First off, before I get going, I owe you, @chpalmer and everyone else on this forum a huge apology. I don't know what got into me last week. I woke up the next morning after creating this topic and realized how much of a jerk I was the night before. I've been thinking about it all week. Maybe it had something to do with the 11-hour days I've been putting in the past few weeks or because I was up so late when I was posting. I'm usually not such an arrogant bastard; but for some reason that night I let my ego get the best of me. I was that incompetent a-hole user who incorrectly assumes he is right and everyone else is wrong; and I am so sorry. It's tough sometimes to see your own faults until you screw up and express them in front of your own eyes. Unfortunately this can be hurtful to others. I know I've got some work to do on myself, starting with choosing my words much more carefully. No doubt you guys have a few choice words for me, and I deserve all of them and more. The pride and arrogance displayed in my previous comments are inexcusable; and I hope those I've hurt or offended will find it in their hearts to forgive me.
-
So here's where I need to learn to always assume I still could be an idiot (like in this case) despite being so sure in my head that I'm absolutely right. I had left pure NAT reflection mode enabled in System -> Advanced -> Firewall & NAT from a while ago when I was testing access to an external-facing web server on DMZ net from the LAN network. When I created the port forward described above, the section on NAT reflection was set to "Use system default," which caused the creation of those redirects on the other interfaces because pfSense thought I wanted all NTP traffic reflected to the LAN address. Setting the port forward's NAT reflection section to "Disable" solved the issue.
-
Water under the bridge man. Hope I was not offensive myself!
Long days and no weekend sucks! Did 1600 feet of cat6 in a warehouse up high Saturday.. My loving wife told me to suck it up Sunday..
-
@KnowledgeAddict024 said in Port forward on one interface incorrectly triggers forward on another:
the section on NAT reflection was set to "Use system default," which caused the creation of those redirects on the other interfaces because pfSense thought I wanted all NTP traffic reflected to the LAN address. Setting the port forward's NAT reflection section to "Disable" solved the issue.
And I learned something new tonight. Thanks!
-
While using
pfctlto view your rule set can be a valuable tool, looking at/tmp/rules.debugcan be much more straightforward. You would also have the benefits of things like comments that would immediately show you that you were looking at NAT Reflection rules.
