Seems like a NAT issue with static outbound…
-
I'd be curious to see the output of 'pfctl -s all | grep 80' with the port forward to a LAN host, and then an OPT1 host (more usefully, a diff of the rules - hopefully not too huge?)
-
Oh its huge. Several pages worth. Help me out w/ a command to pare it down a bit?
-
It's huge even grepping for port 80? Sigh. Try grepping for 80 and pipe that into another grep for the host you are forwarding that to. Maybe also pick a silly port no-one uses (like 12345?)
-
ok, here it is as it sits right now… call me paranoid but I've masked my public IP with letters... This is with Manual outbound NAT
2 ports forwarded on the OPT1 interface:
pfctl -s all | grep 192.168.5.99
rdr on sis0 inet proto tcp from any to A.B.C.D port = hosts2-ns -> 192.168.5.99 port 80
rdr on sis0 inet proto tcp from any to A.B.C.D port = https -> 192.168.5.99...and here's one on the LAN interface...
pfctl -s all | grep 192.168.0.6
rdr on sis0 inet proto tcp from any to A.B.C.D port = smtp -> 192.168.0.6
pass in quick on sis0 reply-to (sis0 A.B.C.1) inet proto tcp from any to 192.168.0.6 port = smtp flags S/SA keep state label "USER_RULE: NAT Mail to Exchange"Not knowing much of the nuts-n-bolts of BSD, I'll need a bit of help to decipher this.
-
I'm confused. Maybe I wasn't clear, but what I wanted was the output for both cases, with LAN and OPT1 as only differences. Is that what you posted?
-
Well, yes..
But the examples are for two different hosts, which I already had set up. Can I replicate the same port forward to two different destination hosts? I didn't expect that would be allowed.
What I've posted is one example of ports 80 & 443 forwarded to a host on the OPT1 interface, with destination IP 192.168.5.99.
Second example is port 25, forwarded to a host on the LAN interface, 192.168.0.6.
The output is clearly different between the two.
If you'd rather I make a more precise comparison, I can certainly do that, but I expected this set of examples might display the differences you were looking for.
I use the destination IP's as the grep variable, which seemed to produce good results.
-
Ah, okay, this makes sense then. What I see that is suspicious: there is no 'pass in quick' rule for the two OPT1 port forwards. If you go to the firewall => rules section, do you not see any auto-generated rules for the OPT1 port forwards? if not, that is the issue, IMO. I don't know why it would not be generating those (maybe a bug?) If so, you can probably get around that by adding them yourself?
-
OK, sorry for the confusion, but this makes more sense. I had an error in there, which I've now corrected. Funny how scrutiny turns up those things… Here's the (correct) output per the previous request. Port 80 on Opt1, port 25 on LAN. I've confirmed the port forward actually
pfctl -s all | grep 192.168.5.99
rdr on sis0 inet proto tcp from any to A.B.C.D port = http -> 192.168.5.99
pass in quick on sis0 reply-to (sis0 A.B.C.1) inet proto tcp from any to 192.168.5.99 port = http flags S/SA keep state label "USER_RULE: NAT "pfctl -s all | grep 192.168.0.6
rdr on sis0 inet proto tcp from any to A.B.C.D port = smtp -> 192.168.0.6
pass in quick on sis0 reply-to (sis0 A.B.C.1) inet proto tcp from any to 192.168.0.6 port = smtp flags S/SA keep state label "USER_RULE: NAT Mail to Exchange"So now the outputs match, as I would expect, but the port forward doesn't actually "work" on the OPT interface. I still wonder if this has something to do with the outbound NAT, and the packets not getting back out? Just a thought.
-
what (if any) are your OPT1 rules?
-
Also, test out this theory (if possible) by running some kind of sniffer on a host on the OPT1 subnet, and see if it sees anything coming from the pfsense box when you try to connect from outside.
-
Good Morning. Opt FW rules look like this. This interface IP is 192.168.5.1/24
Proto Source Port Destination Port Gateway Schedule Description
X * OPT3 * 192.168.0.0/24 * ** OPT3 * * * *
Wan rules look like this:
TCP * * 192.168.0.6 25 (SMTP) * NAT Mail to Exchange
TCP * * 192.168.5.99 80 (HTTP) * NAT Web server
Nat rules next:
WAN TCP 25 (SMTP) 192.168.0.6(ext.: A.B.C.D) 25 (SMTP) Mail to Exchange
WAN TCP 80 (HTTP) 192.168.5.99(ext.: A.B.C.D) 80 (HTTP)
To review, the port 25 forwards OK, the 80 does not. Mail host is on the LAN interface, web is on the OPT interface.
Outbound manual NAT rule is the standard default, with static port enabled (for both networks). Static port enabled/disabled seems to make no difference.
I'll try to capture some packets next and see what happens.
-
Well, the packet capture was very enlightening. It showed, well, no packets at all. A little detective work with alternate ports indicates that my lovely ISP is blocking port 80, despite allowing port 25 and being a commercial connection. Changed to another port number and everything works as it should. As for the original issue with the VNC ports, I suspect there was a separate issue there as well. I'll consider this mystery solved. Thanks for all your time and effort, it certainly did lead me to the solution. Port forwarding works just fine, as long as the packets actually get there!