Use of a custom port for admin console caused issue with NAT using same port
-
This was a head-scratcher. As a public library, we have our web server with a 2nd open port (9443) for handling EZProxy connection requests. NAT had been fine all along and there were never any issues. Then I decided to add a wee bit of security by changing the admin console port in pfSense to 9443 as well. No problem. Or so I thought. Then we started to get random reports of patrons saying they would get our EZProxy login page when trying to connect to our website homepage. At the time I was unable to re-create the error condition, but reports increased and I started to get the login page as well. I started looking into a possible rogue redirect, but found nothing. It was only once I changed the secure login port for the pfSense admin console to not be 9443 that the problem went away.
I read that with NAT, the first match wins, but in this case 443 took a back seat to 9443.
Should this be filed as a bug? The current release is 2.4.5-RELEASE-p1 (amd64). I'll update it tonight and test with the new release, but I have a feeling that it'll be the same behavior... although maybe not right away.
-
You describe thoroughly and quite well why it's clear that this is not a software bug: you assigned two disparate services the same service port number on the same router/software firewall.
If anything, possibly a feature request for a 'duplicate assigned port check' which logic would determine when any port anywhere on the platform is duplicated. Seems like a development beast.
Also—update that system!
-
@tinfoilmatt
I may be missing something or was unclear, but I still don't understand why I couldn't use https://172.16.0.1:9443/ to log into pfSense without it causing a request to https://example.org/ to connect as https://example.org:9443/. Why shouldn't the router be able to keep track of the port number and IP address from the request, even if the router listens on the same port as a listening service on the web server? Also, the behavior was sporadic.Of course, this isn't such a burning issue given that it's so easily fixed. I'm just trying to grok what's going on while letting others know to avoid such a configuration.
-
@jliolios Does
[OP's FQDN].org(too much information by the way) resolve to either the same IP address of the LAN or WAN interfaces at all—either from the inside or the outside? -
@jliolios Also—I'm personally unfamiliar with EZProxy. But assuming this is your edge firewall, any proxying being performed on it, too?
-
Maybe just hit me and it's in your post title: the NAT rule.
What does this NAT rule—assuming it forwards 9443-bound traffic to the EZProxy host (???)—look like? On what interface does it apply, etc.?
-
@tinfoilmatt
Thanks for bearing with me!Nope. Different IP addresses internally and externally. Below is a screenshot of what's in NAT. As for EZProxy, it's something many libraries use to allow patrons access to resources normally only accessible from within the library. I could assign it a different IP address or move it to another server and go with the default 443 port, but everything's been working great until this which is now moot.
The destination public address is the same for the three entries; likewise, the NAT IP is the same internal address for all three. As for port 2048, it's a failover to accommodate those who may have bookmarked our old EZProxy links which used proxy by port.
-
@jliolios Got it, got it. Alright, this all makes much more sense now.
Foundational understandings:
1.) When you assign pfSense's GUI (called the webConfigurator) a port, it listens on all interfaces, including both WAN and LAN. Since most people never 'open' this port to inbound connections on the WAN interface, it typically never presents a conflict or a problem that the webConfigurator's nginx-based web server listens on all interfaces by default. (See this post for a recent thread on this point.)
2.) You have both:
- 'Opened' port 9443 on the WAN interface; and
- Crafted a NAT rule to forward any/all inbound 9443-destined traffic arriving on the WAN interface, to be 'redirected' to the EZProxy host that I'm assuming is not homed to
172.16.0.1
3.) At some later point, you changed the webConfigurator's listening port to 9443. It would not have been readily apparent at that time that inbound 9443-destined traffic arriving on the WAN interface now had two potential and conflicting routes to take: the webConfigurator webserver, and the EZProxy LAN host.
With all that being said, and returning to your original question, what do you mean when you've said:
[in Use of a custom port for admin console caused issue with NAT using same port:]
in this case 443 took a back seat to 9443
