One to One and Port Forwarding
-
I recently updated from a prior version to 2.6.0. Now it seems the One to One nat is taking precedence over the port forwarding.
The update seemed to go well- this is a production firewall in a data center. We have many clients (VoIP telephones) accessing various natted hosts (VoIP PBX instances,) and that continues to work fine.
The Web Gui is accessible for all of these hosts via Nginx reverse proxy. Still working great.
We have a 1:1 Nat for most of the UDP traffic, but also a couple of TCP port forwarding rules for that IP address. The port 80 rule still works fine. The port 4445 rule does not.
The State Table shows 4445 connections to the 1:1 Nat IP, and not to the specified forward IP. So it's as if there is no TCP 4445 forwarding rule. But the rule is there...
I'm afraid I haven't articulated this well- it's late, and I'm bleary-eyed from studying logs, reading through the forums, etc. I guess I must have something mis-configured. Puzzling though, as it worked prior to the update...
Any ideas?
Thanks!
Peter
-
@fortel What is it running on. Doesn't sound too logical that it is working for some ports but not for others.
-
@bob-dig
Bob,PfSense is running on some generic device... dual core Celeron CPU, 4 Ethernet ports configured as Wan, Lan, Opt1, and Opt 2.
The software was working perfectly on version 2.4.3. I updated to 2.6.0 as I wanted to employ PfBlockerNG. I've created an Alias URL rule to allow connections from select areas within North America. And still have the original ruleset allowing certain ports / port ranges, and some NAT forwarding rules.
Since I'm not seeing any issues about this in my searching, I am convinced I just have a mis-configured firewall. But nothing stands out, and everything was working prior to the update.
Only now, the TCP 4445 forwarding appears to be wonky.
I'll keep studying it.
Thanks!
Peter
-
UPDATE: Issue Resolved
So, as mentioned above, I'd updated PfSense to 2.6.0 to take advantage of PfBlockerNG.
Since that update, I found that one of the existing firewall rules was no longer working. Any re-apply or update to the rule had no effect. I tried clearing the firewall state tables which didn't resolve the issue. I tried a filter reload, and no effect.
It appeared that ANY new firewall rule wasn't taking effect. I tried adding a new 1:1 NAT rule and that would never connect.
So I disabled PfBlockerNG and immediately all of the rules were now working. I could access the service on TCP 4445, etc.
I then re-enabled PfBlockerNG, and access through the various rules, including any new rule, was working.
So it appears that, with PfBlockerNG, making edits to the firewall rules (and who knows what else,) requires disabling, and then re-enabling PfBlockerNG before they will take effect.
Many hours to figure this out!!
Now I know.
Peter
-
@fortel So you have 1:1 set up on an IP, and also a port forward on the same IP?
https://docs.netgate.com/pfsense/en/latest/nat/process-order.html does not specify an order between the two.
Can you not just forward 1-4444 and 4446-65535?
-
@steveits said in One to One and Port Forwarding:
https://docs.netgate.com/pfsense/en/latest/nat/process-order.html
Thanks for the link, Steve. I'd read an earlier document that stated the port forward rule would take precedence over 1:1 NAT. It may be the hardware I'm currently using which is causining the problem. Normally, we have a modified Watchguard Firebox in the rack. But we threw in a quick substitute / commodity device running PfSense until we install a new Netgate hardware device. (Have it at home, testing.)
The rules were set up roughly 13 years ago, and were simply transferred to new hardware as it was periodically refreshed. The one-to-one nat was set up initially, along with a port forward to another host IP for HTTP / Nginx. Later, we needed to add 4445 forwarded to Nginx, along with the existing port 80 forwarding. It just always worked, for many years.
Then, the other day, we updated to the current version of PfSense, solely to get PfBlockerNG. That's when I found the TCP4445 forwarding was no longer working.
But everything works great, after disabling, then re-enabling PfBlockerNG. Just toggling that feature off and on and all of the rules are working. Before that toggle discovery, ANY new rules applied to PfSense were not taking effect- I spent hours testing this by adding a rule to test, adding a new one-to-one IP, etc. Nothing was workng. I tried all the usual nudges including clearing the states, applying the filter reload, etc. Spent Hours.
Toggling the PfBlockerNG was the solution, for me, on my hardware. Rules are applied immediately after doing that. Works great now!!
Thanks again,
Peter
-
@fortel Thrre have been a couple posts lately where a pfB rule wasn’t being loaded (e.g. fw table size set too small causing out of memory error) causing other rules to not load. There is a fw rule troubleshooting doc, IIRC try Diagnostics/Filter reload or similar, if it happens again.
Edit: minimum 2million recommend for pfB.
-
I think that's exactly what I was up against. This is a production machine, and I didn't want to experiment too much.
I'll be installing the Netgate hardware during one of the upcoming long holiday weekends, and expect that will go well. PfSense has always been bulletproof. The hardware, on the other hand (my hardware- not Netgate's) has had occasional issues.
Thanks again, Steve!!
Peter
