Port 80 not forwarding
-
@johnpoz Ok, so I was doing it right then. I wasn't suggesting that I sniff the port from my local IP, I was just wondering if since the port forward is specific to a single IP on my LAN, if it would still show as open when I run the test on that site.
In that case, it's definitely not working. I've tried testing ports 80, 1880, 443, and 18443. None of them flag as open using either of the sites I've tried.
What's really weird is that if I restrict the sniff to only my WAN IP, and only port 18443, then run the capture for only the long enough for the port test to run (maybe 10 secs?), I get a long list of packets, both to and from my WAN IP, none of which are 18443. Some of them are port 443, but lots of them are some other random port, like 8812, or 52570. Any idea what's up with that?
I can post the output, but my IP is all through there and it would be a nightmare to obscure.------EDIT-----
OK, scratch that. If I sniff them one at a time, it looks a bit more reasonable. Checking port 80 or 1880, I get only a few captured packets, all incoming, all on the expected ports.
However, on port 443 I get all the crazy output as described above.
On port 18443, I get pretty much the same output as 443, but even more of it. I see hits on 443, but also lots of other random ports. None of them are 18443. How is that possible? -
@elmojo if your sniffing on 443 and your wan IP, you will see traffic in both directions where 443 is either source or destination, so you went to some website, that would be from your public IP and port 443 is in there as well.. So yeah you can see some other traffic.
Here, I will forward 80 external to 1880 internal with nothing listening on that port.. But it will show you how to validate pfsense is working..
First thing to check is that 80 is inbound from outside, the can you see me site.
I limit the traffic to my IP by using the known source IP, 52.202.215.126 in my case with can you see me.
Now I setup my port forward rule, and you can see the firewall rule it created.
Now I sniff on my lan, for port 1880, and then run the test from can you see me again to port 80.
its that simple.
Why would you think you would see port 80 traffic on the lan, if your sending to 1880?
You don't need anything running anywhere to test if port forwards work on pfsense - what you need is an IP to send to, because if pfsense can not arp for that IP, then it can not forward to it..
How do you think any port forward would work with this rule
Rules are evaluated top down, first rule to trigger wins. You need to move your firewall rules for your ports above that block rule, or no they are never going to work because your firewall rule is blocking all inbound unsolicited traffic before it can get to the rule that allows your port forward. Should of spotted that right away :) hehehe Not sure how I missed it to be honest, maybe I thought it was just the block rfc1918 rule at first glance - DOH! But yeah that rule there is stopping any port forwards from ever working.
-
@johnpoz So mine is set up exactly as you show.
The "All WAN block" was set up by one of the mods here, so I didn't question it. I know very little about this stuff, I'm learning as I go, so I have to trust those with more experience than me. :)Let me go back and check everything and try the port checks and captures again...
Thanks for the excellent, very clear instructions, by the way. -
@elmojo you need to remove that rule - while you can sniff and see traffic on the wan with that rule, none of your port forwards would ever work with that rule on top like that.. You need to move your port forward rules above that.
If I had to "guess" to why such a rule would be placed, is you turned off logging of the default rule, and wanted to log your wan inbound traffic. It shows that its being logged with that little symbol there next to the red X.
Nothing wrong with having that rule there for logging blocked traffic, but you need to move stuff you want to allow above it.
With that rule in place - you should of seen block entries in your firewall log for when you tried to access port 80 or 443 from can you see me.
-
@johnpoz It was part of a massive troubleshooting effort to figure out why certain sites were being blocked for no reason. We finally got it sorted out, but I couldn't begin to tell you all the stuff they had me change.
I've moved that rule to the bottom of the stack.
Both ports 80 and 443 now test as open (yay!) but they are captured as 80 and 443, not 1880 and 18443. Per your example, shouldn't I be seeing the "forwarded" ports on the capture?
Just trying to learn the ropes here...---EDIT---
Oh wait, it's late and I'm an idiot. I didn't sniff the LAN. One sec.... -
@elmojo if your forwarding port 80 to 1880 then yes your sniff on your LAN would show 1880, on your WAN it would still be port 80.
For completeness - here is my wan rules, I have sim log rules at the bottom of my stack for tcp (syn only) that is the little gear you see on that rule. And then UDP ports that are of interest to me to see in my log.
Notice the order of the rules, the Reject rule is there so traceroutes answer from the outside.
I moved the 1880 rule to the top just to make it easier to take the pic, it really could be anywhere in the stack as long as its above where I block all.
-
@johnpoz Cool, thanks for sharing that!
I'm getting there.
Still fuzzy on how to cap the packets on the LAN, I can't seem to get it to work.
When I set up the capture, I choose LAN, then what IP? Still external IP or the internal IP that the ports are forwarded to?
Then port 80, then start....
I've tried with both internal and external IP. Neither one gives any packet output.
I know I'm doing something simple wrong. -
@elmojo said in Port 80 not forwarding:
Still external IP or the internal IP that the ports are forwarded to?
Then port 80, then start....Again why would you think it would be 80? And what external IP - not yours.. It would be the IP of can you see me.
To sniff for the traffic going to your lan device. 192.168.11.108 is where your port forwarding - use that IP in your sniff, and the port would be 1880. That is the port you setup in your port forward from you screenpic
Your sending traffic that hits your wan on port 80, to that 11.108 address on port 1880. Is that what you want, or do you want reverse 1880 on your wan and send 80 to 11.108?
-
@johnpoz said in Port 80 not forwarding:
And what external IP - not yours.. It would be the IP of can you see me.
Umm... okay I was with you until right then. For all these other port tests we've done, they've always been tested against my public IP. In fact, when I go to canyouseeme, it fills in my public IP and I can't even change it.
In any case, the brain cells finally clicked and I see it working!
I sniffed the LAN, and I can see incoming traffic on 1880, so I know the forward is working.
Oh man, thanks so much!
I still have a long way to go to get my reserve proxy working, but at least this first small hurdle is jumped. :)Speaking of, which package do you suggest? I'm looking at Nginix Proxy Manager right now, but I'm open to suggestions.
All I want to do is to be able to host my simple landing web site myself, rather than pay for a monthly hosting fee for literally 1 page.
I'm sure you've been through all this and can save me some (additional) headaches. ;)Again, thanks so much for your patience in beating this knowledge into my head.
-
@elmojo when you sniff on the LAN you will not be seeing your wan IP.. You would see the public IP of who is sending the traffic, and the IP you forwarded too.
Only on your wan would you see traffic to your wan IP, once you forwarded it the source would be the external, and dest (your lan IP you sent to) your wan would not be there to see.
So to filter traffic on your lan, and you want to use an IP, you can either use the source IP of the traffic - the can you see me IP, or your destination lan IP your sending it to.
edit: As to what reverse proxy? I just run haproxy on pfsense, I use it to send to a couple of sites behind pfsense based on the host info they send. Also allows for easy use of acme certs for ssl offloading.. The app I run doesn't really make it easy to do ssl on its own.
edit2: reminds me should prob redo that config, I am no longer running the one site, I switched from ombi to overseerr, and I was running both for a while as I tested overseerr - but it won, and now ombi is shutdown. I like the ssl offload feature, and I like how I can limit based on host header info sent.. So bots just searching 443, don't get anything - unless they send the valid fqdn.. I also run openvpn instance on 443 tcp, when I am might be at a place that blocks 1194 udp. And can do both with port share in openvpn and haproxy its pretty simple setup.
-
@johnpoz Ah, I see the confusion now.
I meant when I was setting up the packet capture. I was asking what host address I needed to input. Sorry I wasn't clear. Turns out the answer is none, unlike in previous steps, where we were specifying my external IP.
I'm sure that's all second nature to you, but it's baffling to me when it's not spelled out. lolAny thoughts on the web self-hosting question?
-
@elmojo see my edit.. I use haproxy.
The services I run are all in just dockers on my nas, I use haproxy on pfsense to send traffic to the right place. This way can all use 443 externally.
-
@johnpoz That sounds a bit beyond me. I'll probably just stick with the noob-friendly stuff that has lots of youtube tutorials and handholding guides. lol
Thanks again for your help!
At least I know how to forward whatever ports I need open now.
Next on my list is some sort of remote access for one of my client's Netgate machines via either Wireguard or OpenVPN, but that's another kettle of fish entirely. ;) -
@elmojo openvpn is simple and straight forward. I do believe at some point wireguard will give it a run for its money. Especially if they come up with the QR code to just scan ;)
There was a bit issue, of whats the term to use - quagmire prob works ;)
It was in, and then it was pulled, and some social media craziness, etc. Now there is a package again listed..
I'm a fan of openvpn. Its rock solid, used it for years and years.. It can do tcp for your tunnel, which I do not believe WG supports.. While tcp is not optimal for the vpn, it can come in quite handy when the UDP port is blocked - its a given that 443 is almost always open ;) And you can connect via proxy even.. So when your say at the office, and they run a proxy, and you want to vpn into your home network ;) Use to do that daily before covid and now just full time work from home.
-
@johnpoz That's good info, thanks.
I'll probably stick with OpenVPN, since it seems to be a bit more robust and mature. -
Okay, this is giving me a headache. I thought we had it all sorted out. I was able to forward ports, and checking them against the canyouseeme site was reporting them as open.
However, as of today, they are suddenly closed again?!
I was attempting to forward a different set of ports, for another container.
Once I realized it wasn't working, I set everything back to the way it was, but even the original rules aren't working now. What gives?
Here are my NAT and WAN rules screens. See anything I broke that could be accounting for this behavior?
I can sniff the traffic on the WAN and see it hitting the wall, but canyouseeme reports an immediate "connection refused". Ports that aren't forwarded tend to time out after about 10 secs, so I know it's doing something, just not what I've asked it to do.
I'm too old for this... lol -
@elmojo just out of curiosity why would you forward 1194 to the wan? Openvpn is listening on that - there is no need to forward it.
So when you sniff on the wan do you see a R go back?
Your forward for 80 is showing an active state that /1/1 there - so did your server refuse it?
https://docs.netgate.com/pfsense/en/latest/troubleshooting/nat-port-forwards.html
-
@johnpoz
The 1194 forward is part of the OpenVPN wizard setup. I don't believe I did it manually.
I don't see any explicit blocks in the main log, but when I sniff the WAN I see it hit from outside, and a response go back from my side. It doesn't say what sort of reply it is, only that it's on some random port. Looks like this... (this is 2 attempts)23:42:49.722015 IP 52.202.215.126.36854 > 174.xx.xxx.184.80: tcp 0
23:42:49.722035 IP 174.xx.xxx.184.80 > 52.202.215.126.36854: tcp 0
23:42:51.138779 IP 52.202.215.126.36860 > 174.xx.xxx.184.80: tcp 0
23:42:51.138801 IP 174.xx.xxx.184.80 > 52.202.215.126.36860: tcp 0 -
@elmojo said in Port 80 not forwarding:
The 1194 forward is part of the OpenVPN wizard setup.
No it isn't.. You had to have done that manually. It makes zero sense.. The wizard will make your wan rule for you, but it would not do a port forward.
23:42:49.722035 IP 174.xx.xxx.184.80 > 52.202.215.126.36854: tcp 0
Your server you forwarded too sent a RST! Telling them to go away..
If you would up the verbosity of the sniff, you would see it was RST..
When you do that test do it on the lan side your sniff, and you will see your server sending it back.. Unless you had setup a specific reject rule pfsense wouldn't send a RST.
Did you put a specific rule in your floating tab?
-
@johnpoz
Beats me, I set it up a while back, and I'm not even using it right now. Ignore it for the current conversation. I can delete the rule if you think it may be having an impact?
There are no floating rules.
Nothing has changed from when you helped me the other day. I literally have had no time to work on it any more. I just sat down this evening to try to get SWAG set up, and it needed a different set of ports forwarded. I plugged in those forwards, noticed they weren't working, removed the entries, and here were are. Dunno man, it's baffling.
I'll have to tackle it more tomorrow, if you're available. It's nearly midnight and I'm beat. :)Well son of a.... I think I just figured it out!
I distinctly recall you telling me before that I didn't need any service running on the server (LAN) side in order to check if the ports were open, so I hadn't bothered spinning up the container until I got that sorted out. However, I just went back, turned off SWAG, and fired up NginxProxyManager. This was really just to make sure I hadn't broken anything on the server side. I clicked the port test button, and wouldn't you know, they're testing as open now!
I guess not having anything running on the server to "accept" the request, for lack of a better term, it was rejecting the packets. Man, I wish I had tried this 2 hours ago. :/
At least I can get some sleep now. lol
