pfSense -> pfSense NUT connection issues
-
For reference, I have NAT & firewall rules configured similarly on the second pfSense to allow select clients on there access to the NUT server on the first pfSense via their local access to the second pfSense. So my NAT issue seems specific to trying to port forward to the localhost address rather than being more general.
-
@AngryAnt said in pfSense -> pfSense NUT connection issues:
Surely the destination matching should be the pfSense LAN address (192.168.1.1) and then the NAT IP (where the package is redirected to) should be 127.0.0.1 where NUT listens by default?
You saw it :
@AngryAnt said in pfSense -> pfSense NUT connection issues:
Only firewall log entry related to 3493 is from a port scan on WAN by known-bad actor according to https://www.abuseipdb.com
Normally, you don't place any rules on WAN.
The default firewall for every interface, including WAN is : "silently drop". This is not a pfSense behavior, every firewall on planet earth does this.
Don't ( ^^ ) have this drop rule log, as you'll be smacked with firewall log notification.So, normally, un check this :
@AngryAnt said in pfSense -> pfSense NUT connection issues:
Also: Progress! I am unsure why my previous attempt at having LISTEN 192.168.1.1 in there was unsuccessful
A service needs to listen on an interface, and a port, using UDP and/or TCP.
and
You need on that interface (LAN) a firewall rule that allows that traffic to enter.
For your pfSense LAN, there is/was an install pass-all rule, so as soon as upsd was listening on 192.168.1.1, it would have worked.
That is : you also need to set up user auth. -
@Gertjan Thank you for the overview :)
My port forward does indeed match yours.
No surprises in the overview of socket mechanisms. I also confirmed that listening on 192.168.1.1 does indeed bypass the firewall. After disabling the two NUT-specific allow rules and replacing the two allow-all rules at the bottom of the list with an originally intended allow-outgoing rule at the top of the list:
... all connections to the NUT port are still successful - leading me to conclude that having NUT listening directly on 192.168.1.1 does as I suspected unintentionally bypass the firewall.
I would prefer to:
- Only have NUT listen on 127.0.0.1.
- Have port forwarding handle mapping to 127.0.0.1 from 192.168.1.1, thus looping in the firewall rules on the LAN port (192.168.1.1).
- Explicitly allow access to the NUT port on LAN on a per-host basis.
Thanks again for all of your help.
-
@AngryAnt said in pfSense -> pfSense NUT connection issues:
Not following your correction to the NAT rule. Surely the destination matching should be the pfSense LAN address (192.168.1.1) and then the NAT IP (where the package is redirected to) should be 127.0.0.1 where NUT listens by default? Or am I completely misunderstanding psSense port forwarding here?
No, when you NAT the destination of the [firewall] rule should be for the forward address, not the firewall interface address. 127.0.0.1 is the correct destination address [for the firewall rule].
Please see the instructions for "option 1" here.
-
@dennypage I'm sorry but I seem to be misunderstanding something core here. Looking at the option 1 instructions from your link, all of those match my forward point for point. I originally used those exact instructions to create the forward:
(Note that I reintroduced the filter rule association as I moved away from the allow-all setup as outlined above)
-
@AngryAnt said in pfSense -> pfSense NUT connection issues:
By my understanding this still is effectively a bypass of the firewall,
No, it's not bypassing the firewall. You aren't reposting your rules with every change, so we can't explain each success/failure, but I assure you nothing escapes the firewall rules.
FWIW, I'm not sure exactly what you are really trying to do with the RFC1918 alias, but you may want to look at "Local networks" instead. And perhaps the Local tab on the firewall rules page. These are often overlooked simplifiers.
-
@AngryAnt The correction was for the destination of your firewall rule, not the destination of your NAT rule. Sorry this was ambiguous.
-
@dennypage Apologies - an obvious omission when juggling changes here. The updates are as follows - with host & port aliases added for better referencing and typo avoidance on my part:
-
@AngryAnt said in pfSense -> pfSense NUT connection issues:
@dennypage Apologies - an obvious omission when juggling changes here. The updates are as follows - with host & port aliases added for better referencing and typo avoidance on my part:
Assuming that you still have the NAT rule in place...
Okay, I think I may see the confusion. It's important to realize that the NAT packets do not pass through the firewall twice, only once, and that NAT is applied before the firewall are processed.
So, looking at your rules, the rules that have source "Nilt", "Dejima", "Haro", "Toulon" are meaningless because they have the wrong Destination address. These are the rules referred to earlier that would need to have a destination address of 127.0.0.1. As it sits, these rules will have no effect because of the NATing.
However, it won't really matter because below you have a rule that allows everyone access to 127.0.0.1.
With this in mind, it may help to re-read items 1 & 2 of the "Items related to your problem" list that I wrote above. I added a couple of words above to make it more clear.
-
@dennypage said in pfSense -> pfSense NUT connection issues:
Okay, I think I may see the confusion. It's important to realize that the NAT packets do not pass through the firewall twice, only once, and that NAT is applied before the firewall are processed.
Bingo! This is exactly the piece of the puzzle missing from my understanding. So with that in mind and given the port forward above, what should give me the result I am looking for is a ruleset like this?
-
@AngryAnt said in pfSense -> pfSense NUT connection issues:
@dennypage said in pfSense -> pfSense NUT connection issues:
Okay, I think I may see the confusion. It's important to realize that the NAT packets do not pass through the firewall twice, only once, and that NAT is applied before the firewall are processed.
Bingo! This is exactly the piece of the puzzle missing from my understanding. So with that in mind and given the port forward above, what should give me the result I am looking for is a ruleset like this?
Close.
If I understand what you are trying to do...
What I think you want is this (in order, following the Anti-lockout rule):
- Allow Nilt/Dejima/Haro/Toulon to 127.0.0.1:nut. Just as you have the rules currently.
- Rules to drop some of the Dejima packets without logging. FWIW, I would recommend this be done on an individual port basis to avoid issues down the road.
- Allow * to ! Local networks. NB: "Local networks" is a pfSense provided system alias, found at the bottom of the destination selection list.
In addition, you will want rules to allow access to the firewall for things like DNS and NTP. The Local tab is a good place for this.
-
@dennypage Your interpretation of my intent is exact. Thank you for the suggested improvements :)
Before I touch anything else here: In combination with the port forward, the given hosts should through these rules have access to the NUT server when it is only set to
LISTEN 127.0.0.1either explicitly or reliant on that default? -
@AngryAnt said in pfSense -> pfSense NUT connection issues:
Before I touch anything else here: In combination with the port forward, the given hosts should through these rules have access to the NUT server when it is only set to LISTEN 127.0.0.1 either explicitly or reliant on that default?
Localhost is already accounted for by NUT, and you do not need to add a LISTEN directive.
I believe the only thing you need in the Advanced section will be the user/password entries in Additional configuration lines for upsd.users.
-
@dennypage Ok so something is still not right. I'm assuming with the port forward. If I drop the
LISTENdirectives in order to rely on the port forward and firewall rules, all clients stop being able to connect.upsc ups@192.168.1.1times out. Adding back theLISTEN 192.168.1.1directive restores access (but obv. no longer lets me filter access by host). -
@AngryAnt said in pfSense -> pfSense NUT connection issues:
Ok so something is still not right. I'm assuming with the port forward. If I drop the LISTEN directives in order to rely on the port forward and firewall rules, all clients stop being able to connect. upsc ups@192.168.1.1 times out.
Here is what your NAT should look like:
Note that "Filter rule association" is set to "none" in the NAT.
Here are two example firewall rules:
The firewall first rule is an example of granting access to a specific system. The second firewall rule is an example of denying access to everyone else. You only need the second rule if you have an "allow all" rule further down in the list.
Btw, keep in mind that the upsc test you are running must be from one of the devices you have allowed...
-
@dennypage That all checks out. I had explicited the firewall allow rules to the NUT port only, but changing them to any had no effect. My best guess is still that I have managed to have something somewhere else mess up my port forward even though it is configured identically to what has been shown in this thread and indeed your latest reply here.
I will keep chasing what might possibly trip up that port forward. Thanks again for all of your patience and help :)
-
@AngryAnt said in pfSense -> pfSense NUT connection issues:
I had explicited the firewall allow rules to the NUT port only
Yes, that is appropriate. The allow example really should have had a destination port like so:
