Port 80 not forwarding
-
After doing another port test with port 80 it looks like port 80 is recognized in the packet capture and port 443 is not.
But both rules show 0 States and there are no log entries which is weird, isn't it?
-
@bob-dig state counters don't always update instantly. You might have to refresh that page if you just created the rules, and just generated traffic.
Where exactly are you sniffing,
13:36:42.562998 IP 172.25.0.2.8719 > 4.79.142.192.443: tcp 517
That clearly shows an answer from your pfsense IP as you mentioned. But 172.25 is RFC1918, its not going to get back to where you sent it.. Unless something upstream is natting that, I take your 1st router.. Since your behind a double nat.
But yes, pfsense saw that traffic and answered..
Its also possible that rule didn't get triggered if you had a state already for that traffic..
-
@johnpoz said in Port 80 not forwarding:
Where exactly are you sniffing,
I sniffed on WAN.
Port 80 it looks like this:
14:36:49.624193 IP shieldsup.grc.com.43073 > 172.25.0.2.http: tcp 0 14:36:50.139169 IP shieldsup.grc.com.43073 > 172.25.0.2.http: tcp 0 14:36:50.653947 IP shieldsup.grc.com.43073 > 172.25.0.2.http: tcp 0 14:36:50.995847 IP 93.184.220.29.http > 172.25.0.2.31946: tcp 0 14:36:51.168731 IP shieldsup.grc.com.43073 > 172.25.0.2.http: tcp 0 14:36:51.288596 IP 93.184.220.29.http > 172.25.0.2.18060: tcp 0 14:36:51.291502 IP 93.184.220.29.http > 172.25.0.2.28221: tcp 0Port 443 like this:
14:39:44.028582 IP 172.25.0.2.10728 > www.grc.com.https: tcp 837 14:39:44.196798 IP www.grc.com.https > 172.25.0.2.10728: tcp 517 14:39:44.197041 IP www.grc.com.https > 172.25.0.2.10728: tcp 1452 14:39:44.197054 IP www.grc.com.https > 172.25.0.2.10728: tcp 649So no Port 443 on my side, searched the whole capture.
This time I was resetting the state table before and after each test.
Still only 0/0 states, but maybe this is normal because of the reject? But also no log entries for both.
I still think it is something with pfSense, but it is hard to tell for me and because I am not home I can't test everything.
-
@bob-dig said in Port 80 not forwarding:
Still only 0/0 states, but maybe this is normal because of the reject? But also no log entries for both.
No - here I created a reject for 80..
I then created some traffic to me from can you see me. Rejected, logged
If I then look at the floating rule - you can see it was evaluated and how much traffic
If you increase the verbosity of your sniff, you can see the Syns and Acks or RST right in the output. So above is viewing it in wireshark (easier to follow and see exactly)... But there is from the output right in pfsense.
08:05:22.032521 00:01:5c:b9:06:46 > 00:08:a2:0c:e6:25, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 48, id 18315, offset 0, flags [DF], proto TCP (6), length 60) 52.202.215.126.45648 > 64.53.x.x.80: Flags [S], cksum 0x38a4 (correct), seq 3282396933, win 26883, options [mss 1460,sackOK,TS val 1682776206 ecr 0,nop,wscale 7], length 0 08:05:22.032591 00:08:a2:0c:e6:25 > 00:01:5c:b9:06:46, ethertype IPv4 (0x0800), length 54: (tos 0x10, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 64.53.x.x.80 > 52.202.215.126.45648: Flags [R.], cksum 0x8e52 (correct), seq 0, ack 3282396934, win 0, length 0You can clearly see pfsense sent back RST via the Flags [R]
edit:
You know when your shiffing are you letting it log more than 100 packets.. Quite possible with all your normal https traffic, your just hitting 100 before you actually generate traffic to you. -
@johnpoz said in Port 80 not forwarding:
You know when your shiffing are you letting it log more than 100 packets..
Yeah, did that. Thank you for your testing.
So my install is once again hosed...
-
@bob-dig said in Port 80 not forwarding:
So my install is once again hosed...
Again - pfsense not seeing traffic, has ZERO to do with pfsense, ZERO!!
Lets try another analogy ;)
If you order a beer, can you drink it before the bartender puts it in front you?
Pfsense can not do anything with something its not seeing.
-
@johnpoz said in Port 80 not forwarding:
Again - pfsense not seeing traffic, has ZERO to do with pfsense, ZERO!!
Wait, although Port 80 was seen in the packet capture, it did not log, so this is definitely a problem in my pfSense.
I now tried a random port and at least with it, everything looks like it should, also got logged.
Still a problem, see above.
-
So lets get your theory correct.. There is a "bug or problem" in pfsense that doesn't log traffic it sees but only on port 80..
Logs all other traffic, just not 80.. Does that make sense???
Or is it more likely that since your rule is not showing it has been evaluated. You have another rule or state that is handling the traffic that is set not to log.
Since for one - I just showed you it doing exactly what it suppose to do via my 30 second test to port 80..
And what the does that have to do with NOT seeing anything to 443?
-
@johnpoz 443 is totally not clear where the problem comes from but port 80 doesn't log although it is the highest floating rule with quick and was seen in the capture (other then 443), so at least this looks like a problem in my pfSense. And if one thing is not correct there might be others.
But if you have another opinion on port 80, let me know. I even reset the state table before testing.
And I didn't said that this is a general problem, I just said that, once again, my pfSense is hosed. And I might have to look elsewhere, I have to add, unless you have an explanation, because again, not the first time. I do run it virtually though, maybe part of the problem...
-
@bob-dig 1 thing that comes to mind that would cause exactly what your seeing is a port forward on 80.. That has a state created.
States are evaluated before rules.
So if there is a state open for 80, then now your new block/reject rule would not be evaluated, nor would that rule log any traffic.
You said you cleared states? Maybe it didn't clear? Maybe you cleared the wrong one?
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.7.2, 24.11 -
@johnpoz I did reset the whole state table. Also I did reboot pfSense now several times.
I also tried your test-site, giving the same results.
Also, for an incoming tcp connection on port 80 with a reject, do states really matter? But as you know, I have no greater knowledge about networking, I only do it for the fun, which I had plenty with pfSense so far. -
@bob-dig said in Port 80 not forwarding:
do states really matter?
Yes!!! States are evaluated before rules be it floating or on the interface.
-
@johnpoz Problem solved...
There is one thing done before Firewall rules and that is portforwards and I had one I had forgotten, pointing to a machine but with no firewallrules....I could slap myself and I will, ty John for your patience.
-
@bob-dig said in Port 80 not forwarding:
pointing to a machine but with no firewallrules....
That could cause it, but if you had no rule to allow it, it should of been logged by the default logging rule.
But your floating rule to wan address, wouldn't of triggered because the forward to evaluated and said to send to some internal IP, on some other port even..
edit: In all my years using pfsense and frequenting this board, when it comes to port forwarding. I can not recall an issue that was not PEBAC ;)
-
@johnpoz said in Port 80 not forwarding:
That could cause it, but if you had no rule to allow it, it should of been logged by the default logging rule.
That one I had disabled...
-
@bob-dig said in Port 80 not forwarding:
That one I had disabled...
So it should of been caught by the default logging.. Do you have that turned off?
When the state is being created, it still has to evaluate the rules to validate the traffic is allowed. If you had no rule to allow it, or the rule that allowed it was disabled then it should hit the default deny rule and be logged. Unless you disabled logging of the default deny.
-
@johnpoz said in Port 80 not forwarding:
Unless you disabled logging of the default deny.
I have this off because of to much noise, my pfSense is exposed so there is a lot. But for error seeking I should remember to turn it on from now on.
-
@johnpoz said in Port 80 not forwarding:
You don't need to have anything listening if your going to sniff to see if the traffic gets to psfense..
I done been hijacked! lol
I don't know what to tell you, but if I don't have anything running on my server to "accept" the packets (for lack of a better term), I get an instant 'connection refused' notice when I try the port check. If I start up SWAG or NPM, the port reads as open as expected.
I do see that you're referencing the packet sniffer, and I'm talking about the online port checker, so maybe we're talking about 2 different things?
All I know (very little!) is that my web services are not being exposed the way they're supposed to be, and I can't figure out why. It's really frustrating.
To be clear, I'm fairly sure it's an issue with the way I have things configured, not really a problem with pfsense, per se. As always, the issue is usually an ID10T-error. ;) -
@elmojo said in Port 80 not forwarding:
I done been hijacked! lol
You mean on the thread you hijacked?
My point is about having anything "listening" to know if the packets get to you., You do not need anything listening to know if the packets get to pfsense wan. Which before anything can be forwarded or not.
You can validate that port xyz can get to my wan IP without anything having to accept it. Or that it be forwarded. You just need to sniff on your wan while you send the traffic - do you see it or not. If you do not see it then no pfsense can not do anything with it.
-
@johnpoz said in Port 80 not forwarding:
You mean on the thread you hijacked?
Well, kinda, except that my post was several months after the last comment by the OP, so I felt pretty safe that I wasn't interrupting anything. lol
I see what you mean about sniffing the packets on the WAN, but that doesn't really tell me if the port is actually forwarded or not...does it? Only once I can run the port checker from an external web site and get an "okay, I see you" response, can I be sure it's really forwarded. At least that's the best I can do with my limited knowledge. I'm sure others (such as yourself) can check may other ways to see if the port is forwarding or not.
For those purposes, it seems that I must have a service running on my server side. I don't understand how that could be, maybe you can explain it? All I know is that it wasn't working until I turned on that docker, then it was.
