Port 80 not forwarding
-
@johnpoz
I think I get you, but the whole point of this exercise is to verify that the ports are indeed open to the internet, so that whatever I do next (say, publish a web site) will actually work. I've been able to validate that pfsense is indeed seeing the incoming traffic, using the methods you taught me. The only issue now is why I have to have a live service running on the "inside" (server) in order for that port check to work. That's what's baffling me. According to everything you've said, and what I've read online from other sources, that shouldn't be necessary.As for the possibility of another device intercepting the traffic, I don't know what else it would be. The only thing plugged in upstream of my pfsense is my modem. It's a DSL router/modem, that's been bridged, so it really should be nothing but a simple modem at this point. I finally have pfsense accepting the PPPoE credentials, so I'm fairly sure that part if working. Is there a way to check that? The part about something else hijacking port 443, I mean.
Regardless, I am able to open both ports 80 and 443 successfully, IF I also spin up the container on my server that will use those ports, so the proceeding paragraph may be moot. lol
-
Wow, I kind of forgot about this thread sense I got really really sick with covid. after dying for about 4 weeks, I was able to get it working. It turned out pfsense was port forwarding properly, the testing websites I was using to see if the port forward was working was giving me false information. Pfsense works great, Port testing websites.. no so much. XD
-
@mr-traxson
Sorry to hear about your COVID battle. Glad you won! ;)
Which site(s) were you using to check ports? -
@elmojo I was using https://portchecker.co/
-
@mr-traxson
Ah. Yeah, that one has lead me astray in the past as well. canyouseeme or yougetsignal are the ones I typically use.
Glad to hear you got your issues all sorted out, both digital and medical. :) -
@elmojo said in Port 80 not forwarding:
That's what's baffling me. According to everything you've said, and what I've read online from other sources, that shouldn't be necessary.
Huh? I have no idea what your thinking... But to actually validate something got some traffic and ANSWERED it, you would have to have something listening for that traffic.
You can check that pfsense saw the traffic, and you can validate pfsense sent that traffic on where you told it too (via sniff on the lan side port). As long as there is an IP that pfsense can arp for where your trying to send it.
But if pfsense sends it on to that IP, and nothing listening there wouldn't be an answer.. Not unless the os is setup to send redirect, they nothing here listening on that IP. But normally OSes would not do that if the source IP is not local.. That bad to do if not a local IP.. Such a test is great that maybe your client your forwarding too is running a firewall, or its not using pfsense as its gateway, etc.
You could validate that where you sent it got it via doing a sniff on that device. But if you want some outside testing site to say hey something answered - then yes something would have to answer.
BTW testing UDP is going be nothing but problematic be it you have something answer or not - I wouldn't trust any outside testing site to give you a valid answer if your trying to test UDP.. You would need to see the sniff for the inbound traffic, and then see the outbound response..
-
@johnpoz
I didn't really follow most of that, sorry. I must be a bit slow this morning.So how does a port checker work under normal circumstances?
Let's say I don't have a pfsense box at all. All I have is a normal home router, and a desktop PC. I want to play some game or whatever, and it requires a port to be open. I go into my router and forward that port via the GUI. I want to see if it worked, so I go to the canyousee web site and ask it to check that port. It says, "yep, that port is now open!". How does it do that? I've seen it work several times in the past. I've done it myself, long before I ever heard of pfsense. What was responding to the request from the port checker?
I'm trying to learn the system here, so that next time something like this comes up, maybe I'll be slightly less dependent on help. :) -
@elmojo said in Port 80 not forwarding:
So how does a port checker work under normal circumstances?
It sends a SYN to the IP and port.. Does it get an SYN,ACK back - if so its open and working. If it doesn't get anything back its not working.
So how could it validate if something is open if it doesn't get an answer to the syn? For something to answer the syn, it has to be listening on that port!
edit: Here see I sent to some port, nothing listening.. But I can tell from sniff that port can get to me..
You can see that traffic is SYN sent to that IP and port
Now if I send to something that is open..
You see the syn,ack is sent back.. And then the closure of the connection.
Might behoove you to do a bit of research of how tcp works, and what the handshake is when connections are being made and when they are closed, etc.
here simple walk through of the handshake
https://www.guru99.com/tcp-3-way-handshake.html -
@johnpoz
Ok, thanks for the example. It actually illustrates my question pretty well.
In your first set of images, the port is not forwarded (or is it? you didn't say) and nothing on your system is "listening", so the port checker comes back as closed. Okay, as expected.
In the second set, you show that it receives an ACK response... from where? What sent that response? Do you have some service active on your system that's listening to that port specifically?
This is what I'm trying to nail down. I fell like we're asking and answering different questions here...
When I do a port check on a port that is forwarded in pfsense, but does not have any active service listening to that port on my server, I don't get a 'connection timeout' like you show in the first image. I get an immediate 'connection refused'. That leads me to believe that pfsense (or something on my server) is actively blocking that port, even though the rule is allowing it through the initial firewall. I'm trying to determine what that thing might be, or how to go about tracking it down. Does that make sense? -
@elmojo said in Port 80 not forwarding:
the port is not forwarded (or is it? you didn't say)
Its not forwarded but it doesn't matter if I forwarded it or not, if I forwarded to something that didn't answer it would be the same exact result.
receives an ACK response... from where?
From where I forwarded it answering.
@elmojo said in Port 80 not forwarding:
I get an immediate 'connection refused'
Then your client you forwarded to sent back a RST.. Or you setup pfsense to do it.
Here this is REFUSED, for that to show up something answered with a RST.. Either the rule you have on pfsense, something in front of pfsense or where you forwarded too.
-
@johnpoz said in Port 80 not forwarding:
something answered with a RST.. Either the rule you have on pfsense, something in front of pfsense or where you forwarded too.
The pfsense rule is the automatic one created by the NAT, so I don't think that's it.
There's nothing ahead of the pfsense, other than the modem, as noted earlier, so I don't see how that could be it.
That only leaves the server. It's possible that unRAID has some sort of generic blocking routine built in for all ports not actively used by a container.
So for my purposes, is it safe to assume that if I see a 'connection refused' message on the port checker, then the forward is probably working correctly and it's just getting "stopped at the door", so to speak? If so, then I'm good, and can proceed with the other aspects of the configuration. There are so many moving parts of this system I'm setting up, and I'm so new to all of this, when (not if) something breaks, I'd like to know where to focus efforts looking for the trouble, and where it's likely not. ;) -
@elmojo said in Port 80 not forwarding:
It's possible that unRAID has some sort of generic blocking routine
Not really a blocking routine.. But more a networking aspect of the OS.. Or the host firewall running on the box.
But if your showing something sent a RST.. But again wouldn't not say getting a Refused is valid test that pfsense sent on the traffic.. Maybe your ISP is blocking that traffic and sending the RST.
All you know from seeing refused is it saw a RST.. Who or what sent that you have no idea, unless your actually sniffing on pfsense and seeing the traffic and then the RST going out.
Sniff on your lan side when you do the test, that will tell you that your box your sending the traffic you sent to sent the RST.. It is normally bad practice to send a RST to anything other than local network.. Because it can be used as attack vector, dos reflection, etc. etc.
So if your box your forwarding to is sending a RST to some public IP address, I would prob suggest you disable that function on that box.
-
@johnpoz said in Port 80 not forwarding:
But again wouldn't not say getting a Refused is valid test that pfsense sent on the traffic.. Maybe your ISP is blocking that traffic and sending the RST.
We've already established that my ISP is not blocking those ports, since I can get them to test as open, simply by running the associated service on my server.I appreciate your help, but I think I'm going to let this sit for a while, before I have a stroke.
I may come back to it later. Thanks again.
