HTTPS Inbound NAT Rule taking people to pfSense GUI
-
Hi All,
We've been running with pfsense since 1.2 through to 2.1 and all has been going well.
Yesterday, we added another CARP address to the WAN. Added in a NAT:
- Source: "From customer alias"
- Destination: "New WAN Carp Address"
- Destination Port: "HTTPS"
- Redirect target IP: "Alias of VM on cluster"
- Redirect target port: "HTTPS"
- Add associated filter rule
like we have done MANY times before…. HOWEVER, this time it was set up using an Alias for the Destination
- Source: "From customer alias"
- Destination: "Alias of the New WAN Carp Address"
- Destination Port: "HTTPS"
- Redirect target IP: "Alias of VM on cluster"
- Redirect target port: "HTTPS"
- Add associated filter rule
When the customer tried to access the HTTPS site, all is well. When visiting it from ANYWHERE else on the net, it directs you to the pfSense GUI!
BAD times ensues when the Customer attempts to connect to it from home and is greeted with the firewall landing page.
I've deleted and recreated the rules with manually setting the Firewall Rules myself and we're back to normal with no Web GUI being exposed. The scary thing is, that if he had had his own VPN connection up we probably would never have spotted it. Subsequent check on similar rule configurations has shown the same issue.
Looking in the system logs is showing quite a few CARP fails overnight:
Mar 13 02:36:37 kernel: lan_vip4: link state changed to UP
Mar 13 02:36:34 kernel: lan_vip4: link state changed to DOWN
Mar 13 02:36:34 kernel: lan_vip4: MASTER -> BACKUP (more frequent advertisement received)
Mar 13 01:23:17 kernel: lan_vip4: link state changed to UP
Mar 13 01:23:14 kernel: lan_vip4: link state changed to DOWN
Mar 13 01:23:14 kernel: lan_vip4: MASTER -> BACKUP (more frequent advertisement received)Which I've not seen before…. not sure if its related or not, but I'm going to be keeping an eye one it.
Version:
2.1-RELEASE (amd64)
built on Wed Sep 11 18:17:37 EDT 2013
FreeBSD 8.3-RELEASE-p11 -
Well you have a source listed there, what do you expect would happen.. Coming from that source you would hit the nat.. If not coming from that source you wouldn't follow that nat and hit whatever is just allowed access on https.
If you want anywhere on the net to hit the https redirect, why did you set a source?
-
Hi John,
Well you have a source listed there, what do you expect would happen.. Coming from that source you would hit the nat.. If not coming from that source you wouldn't follow that nat and hit whatever is just allowed access on https.
I was expecting to only allow people from the Source Address to be able to access this WAN IP/port - that's why I added the "also create associated rule" option.
If you want anywhere on the net to hit the https redirect, why did you set a source?
I don't want anywhere else to hit it - hence the source address and the firewall rule.
I was hoping:
- NAT Rule: IF source = {range} AND destination = {WAN address on FW} THEN GOTO {Internal VM Address}
but it seems to have doing:
- NAT Rule: IF source = {range} AND destination = {WAN address on FW} THEN GOTO {Internal VM Address} ELSE {WAN address on FW}
-
Rules are not IF statements with and else – other than IF traffic meets criteria of the rule it applied, if not then its not applied.
And how is it not doing this
IF source = {range} AND destination = {WAN address on FW} THEN GOTO {Internal VM Address}Traffic hit your wan IP on https already so if something is open and not redirected because the nat rule was not applied where in your rules does it get allowed to go.
So is it you don't want the customer to be able to get redirected if they are not from their location. So customer is at starbucks you want them to get what when they hit your wan IP on https? Either this page or juts blocked, a informational page - what?
-
I did a quick test of this on an ordinary system (no CARP). I made aliases Customer (the remote customer addresses), MyServer (the internal server IP) and testAlias (an alias for an extra WAN IP). Made a port forward like in the screen shot and it made a reasonable-looking firewall rule, other screen shot.
In /tmp/rules.debug there was a reasonable NAT redirect rule and a firewall rule allowing just traffic from the Customer alias to MyServer.
Other connections to that extra IP address should not be NAT'd and should not match the auto-added firewall rule. If there are no other matching pass rules on WAN, then the connect attempts should be blocked. But if they are not blocked for whatever reason, then yes, the webGUI is waiting there.
Here are some bits of /tmp/rules.debugtable <customer>{ 2.3.4.0/24 } Customer = "<customer>" table <myserver>{ 10.49.208.42 } MyServer = "<myserver>" table <testalias>{ 10.49.223.2 } TestAlias = "<testalias>" ... # NAT Inbound Redirects rdr on vr1 proto tcp from $Customer to $TestAlias port 443 -> $MyServer ... pass in quick on $WAN reply-to ( vr1 10.49.223.250 ) proto tcp from $Customer to $MyServer port 443 flags S/SA keep state label "USER_RULE: NAT Test zzz"</testalias></testalias></myserver></myserver></customer></customer>This system is 2.1.1-prerelease. So maybe something has been fixed in that.
Make a test port forward in a similar way and look in /tmp/rules.debug and see what it is making for the "pass in quick" rule.
And check your other pass rules on WAN to see if there is some other reason these connects are being passed.
-
Thanks all. I'm not sure what been going on, but going back to the old method of manually creating the rules after making the NAT seems to work.
We're still seeing issues with the CARP and it's only occasionally.
Mar 13 02:36:37 kernel: lan_vip4: link state changed to UP Mar 13 02:36:34 kernel: lan_vip4: link state changed to DOWN Mar 13 02:36:34 kernel: lan_vip4: MASTER -> BACKUP (more frequent advertisement received) Mar 13 01:23:17 kernel: lan_vip4: link state changed to UP Mar 13 01:23:14 kernel: lan_vip4: link state changed to DOWN Mar 13 01:23:14 kernel: lan_vip4: MASTER -> BACKUP (more frequent advertisement received)I'm starting a new topic relating to that.
