New NAT rules not working
-
Hello,
I'm on 2.0.2-RELEASE.
I have a set of previous NAT rules that are working fine, but since yesterday, I'm trying to have some new rules to work.
I've even removed another rules that were working fine before, had them re-added and they don't work either.
Every time I add a NAT port-forward, a firewall rule is also created, so this should be OK, I even tried to create the firewall rule by hand with the same results, no NAT working for new rules, and I can’t play around with old ones since they are productive and working OK.
WAN TCP xxx.xxx.xxx.xxx * WAN_ address 22 192.168.1.xxx 22
It’s an ssh inbound rule, any idea what could be wrong or where to check?
I did reboot the firewall last night just in case, no luck.
Thanks!
-
Either a rule higher up already forwards 22 that matches the same source/destination, or the rules aren't actually reloading. Check Status > Filter Reload and see if something is gumming up the filter reload process.
-
Actually there is no other rule that matches same source/destination, and rules 'seems' to reload fine, even rebooted the server just in case.
Other rules, for the same destination/other-port, different source, works fine.
Recreating rules that use to work, make them to stop working.
I'm very confused about this, Status->System logs->Firewall don't even show the connection attempt from the WAN side.
NAT port-forwarding is heavily used by us, and for everybody I guess, I'm in the need to fix this ASAP.
BTW, thanks for taking the time for replying back.
-
If you never see it in the logs (pass or block), and the rules are set to log, then your provider upstream may be filtering that port before it reaches you.
A packet capture while you attempt a connection would indicate that for certain. If you run a capture and never see a connect for port 22, then it never reaches the firewall. Even if the connection is blocked, it would show in a packet capture.
-
I do see it in the logs, being blocked, but can understand why, both NAT and Firewall rules are in place allowing the traffic to pass.
-
If it's in the logs with that, it means that the rule did not match the traffic.
Without seeing the exact rule and the exact log message, it's impossible to speculate further.
-
Jimp, I've attached some more stuff, this very same rule for SSH used to work fine, now it just doesn't, and there is no log of connection attempt on 192.168.1.12 now.
-
Follow the procedures here:
http://doc.pfsense.org/index.php/Port_Forward_TroubleshootingIt always boils down to one of those… the packet capture and logs would be more helpful to see.
You can also check the state table (Diag > States) to see if the connection shows up there. Your firewall rule is not set to log, so a successful connection wouldn't show in the logs.
-
I've attached the screenshot for:
block Mar 28 12:36:35 WAN_FIBER 50.17.118.102:60588 192.168.1.12:22 TCP:S
I've already followed the link you posted with no luck so far .
From Diag->States nothing shows up for port 22 from 50.17.118.102.
Please let me know if I can get more logs or any other sort of information to track this down
Thanks!
-
That implies that your NAT rule matched but the firewall rule did not, since it shows the translated address in the log entry.
Even though it says "default deny" - have you tried disabling the "block bogon networks" rule on WAN_FIBER to see if it gets through?
Other than that, we'd need to see /tmp/rules.debug to see if the actual rule does match up with what the GUI shows.
-
Thanks jimp, kind of stuck here, this is all I've got from rules.debug:
rdr on xl0 proto { tcp udp } from 50.17.118.102 to 190.16.xxx.xxx -> 192.168.1.12
Which seems OK to me, but nothing else. I'm pretty sure there is nothing in front of the pfsense that could be blocking the traffic, actually this rule stopped working after I deleted it and had it re-created.
Anything else I can try or provide to track this down?
-
There should also be a "pass" line that corresponds to the same source and target IP/port.
The rdr is only the NAT portion of the forward, the firewall rule should be there also.
-
You are right, the "pass in" it is supposed to be there but is not, even though it's in the GUI.
I've tried again re-creating the rule, it appears both in the GUI (NAT/FW) but then only the rdr shows up in the rules.debug, something isn't working really well here.
-
This is kind of weird: while looking at rules.debug, found very ancient rules that aren't any longer on the GUI and were deleted long time ago.
In the other hand, newer rules weren't also there but the NAT part only, not the associated FW rule.
I've managed to accomplish what I needed ASAP by modifying the rules.debug file and reloading the configuration, which of course isn't reflected in the Web GUI.
Definitely there is something wrong with this, and I need to fix it, there is no way we can trust we see from the GUI, and having to do the changes via the CLI is kind of annoying.
Any ideas/help are more than welcome!
Thanks!
-
Rules do not work via the webConfigurator, they do work if I apply them by changing and reloading rules.debug which isn't the best way for doing this.
Now of course, webConfigurator and rules.debug do not match.
Even new rules from webConfigurator do not get created on rules.debug, just the NAT ones.
Anyone?
-
Seems like a dead post, no idea what's going on here with the GUI and rules.
Suddenly the firewall crashed yesterday and rebooted on it's own, where can I send the crash report?
-
use the button in the GUI to submit the crash report and let us know the date/time it was submitted.
I'm not sure why just the firewall rules aren't making it to your rules.debug, though the most likely scenario is a package hooking into the rules process that is not doing something correctly.
