Port 80 not forwarding

Bob.Dig

I can't open port 443 and I don't know why, but I have another router in front of pfSense, so it is hard to tell, which device is responsible for that... but pfSense is the exposed host of that first router.

johnpoz

@bob-dig said in Port 80 not forwarding:

but pfSense is the exposed host of that first router.

If pfsense does not see traffic get to it on 443 (when you sniff on pfsens), then "something" upstream didn't allow it, be it that router in front of pfsense (likely suspect) or your ISP. etc..

Bob.Dig

@johnpoz The Problem for me, the ISP is not known for doing that and also the router is not. I can see which port the router has opened to WAN and there is no 443. Do you have any tip for seeing it in pfSense?
What I did after noticing this problem was placing a reject tcp 443 floating WAN in on top and logging and doing a port test on a website, still port is stealth and no log entry...
Also sorry, I have not read this whole thread.

johnpoz

@bob-dig said in Port 80 not forwarding:

still port is stealth and no log entry..

Then it didn't get to pfsense.. Pfsense has zero control over what gets to it or not.. It can not do anything with traffic it never sees, be that ignore it, or forward it or reject it.

If you sniff on pfsense when you do a test from can you see me .org for example - and you don't see it, then it didn't get to pfsense. Something upstream prevented it, or your sending to the wrong IP..

You could be standing at the plate, all ready to hit that homerun. If the pitcher never throws you the ball.. Nothing you can do about it.

Bob.Dig

@johnpoz I don't know about American Football ;) but I was able to open the web-ui of that router to the public, so it is not an ISP thing. So I guess the router firmware is faulty, I will report to them. Still, this problem seems to "big" that nobody has found it so far... thx John.

johnpoz

@bob-dig said in Port 80 not forwarding:

Still, this problem seems to "big" that nobody has found it so far

Who says its a problem.. Could just be operator error. If you setup pfsense as dmz host, ie all ports forwarded to pfsense IP in your first router. What if your 1st router is actually using 443 for its web interface, and say you enabled remote management of this router.

How would it forward 443, if its using it, etc.

Possible your using a vpn? And when you go to can you see me, its sending the traffic to your vpn IP..

Maybe your isp is blocking 443 inbound? Do other ports work?

Don't know your setup, maybe you have UPnP enabled on it, and you have some other device along side pfsense on your 1st routers lan having 443 forwarded to it.

Lots of things that could be causing what your seeing other than "bug/problem" with your 1st router.

American football ;) hehehe Ok how about this analogy. Kind of hard to take your penalty shot if there is no ball..

Bob.Dig

@johnpoz Damn, I almost cut myself off from home and all the services, because I am not at home for some weeks and I just disabled the exposed host function in the router and I was connected to it via pfSense VPN...
I really had big luck, that the ongoing rdp-connection wasn't canceled, otherwise I would have some serous problems...

Anyways, what I found out by disabling the exposed host function and enabling only one explicit port forward on port 443 to pfSense for a short time was, that this time I got a different result on grc.
I always did testing on port 80 and 443 and this time 443 was still stealth but Port 80 was just closed.
I don't use Port 80 on pfSense WAN and I think port 80 closed is the normal behavior of the first router, because it is not in stealth mode and exposed host was not activated. So now I do think it is pfSense!

Any tips how to investigate further? Everything you explicitly mentioned to me I already had checked.

Bob.Dig

@johnpoz So I just did a packet capture of the port scan with grc, exposed host active and it looks like it is coming through? I never do packet capture, please be calm with me.
It looks like this (there is more) but I am not sure what it means, could need some help here.

13:36:42.561714 IP 172.25.0.2.39667 > 4.79.142.202.443: tcp 517
13:36:42.562998 IP 172.25.0.2.8719 > 4.79.142.192.443: tcp 517
13:36:42.734132 IP 4.79.142.202.443 > 172.25.0.2.36858: tcp 1452
13:36:42.734233 IP 4.79.142.202.443 > 172.25.0.2.36858: tcp 1452
13:36:42.734332 IP 172.25.0.2.36858 > 4.79.142.202.443: tcp 0
13:36:42.742283 IP 4.79.142.202.443 > 172.25.0.2.39667: tcp 1452
13:36:42.742430 IP 4.79.142.202.443 > 172.25.0.2.39667: tcp 1452
13:36:42.742527 IP 172.25.0.2.39667 > 4.79.142.202.443: tcp 0
13:36:42.750059 IP 4.79.142.192.443 > 172.25.0.2.8719: tcp 1452
13:36:42.750193 IP 4.79.142.192.443 > 172.25.0.2.8719: tcp 1452
13:36:42.750275 IP 172.25.0.2.8719 > 4.79.142.192.443: tcp 0
13:36:42.875387 IP 4.79.142.202.443 > 172.25.0.2.41225: tcp 117
13:36:42.886209 IP 4.79.142.206.42743 > 172.25.0.2.443: tcp 0
13:36:42.898437 IP 4.79.142.202.443 > 172.25.0.2.36858: tcp 964
13:36:42.900825 IP 172.25.0.2.36858 > 4.79.142.202.443: tcp 150
13:36:42.906914 IP 4.79.142.202.443 > 172.25.0.2.39667: tcp 964

4.79.142.202 is grc port tester
172.25.0.2 is my pfSense

But I think the port tester is also testing for other things, so is port 443 on pfSense touched or is is not?

Here is the floating rule:

Bob.Dig

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?

johnpoz

@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..

Bob.Dig

@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 0

Port 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 649

So 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.

johnpoz

@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 0

You 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.

Bob.Dig

@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...

johnpoz

@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.

Bob.Dig

@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.

johnpoz

@bob-dig

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?

Bob.Dig

@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...

johnpoz

@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?

Bob.Dig

@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.

johnpoz

@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.