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:
-
@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:
