New NAT rules not working
-
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.
