Port forwarding HTTP and HTTPS dont work on pfsense 2.4.0 (sg2220).

starr

I did sniff the traffic on pfsense LAN interface as well as on the web server.

Both packet dumps shows that the webserver is reciving the SYN and replying with SYN ACK. But it seems like the SYN ACK is never recived by the client.. As TCP retransmission is occurring..

Screen dump of pfsense LAN interface:

Screen dump of webserver interface:

This is not a issue with the webserver, I can run

sudo python -m 'SimpleHTTPServer' 80

to start a simpleHTTP instance on port 80 on my workstation or any other VM,(and changing the NAT rule accordingly) and the behavior is still the same..

Edit:
Change the port to 8085 shows "ESTABLISHED:ESTABLISHED" in the state table

PF_lan.PNG_thumb

web_int.PNG_thumb

johnpoz

Makes no sense.. your saying if your forward 8085 to 80 works.. But if 80 to 80 fails.

Do you have any floating rules? Are you running transparent proxy? You only have the 1 wan, no vpn setup for routing. Possible pfsense doesn't know where to send the syn,ack back? There is nothing in the firewall log. If the traffic was out of state pfsense should log that it blocked it.

Are you using any vlan tags? Did you validate that the syn,ack back is going to the correct mac address

starr

Yes I know this makes absolutly no sense..

No floating rules, no proxy, no VPN. This is a clean install of pfsnese. Only one WAN, and one LAN port.

However i have two vlans: HOME - vlan 20 - tagged(192.168.2.1/24) , GUEST - vlan 30 - tagged(192.168.3.1/24). Currently no FW or NAT rules other than the "default" allow internett..

I also have the interface "LAN" which is not a VLAN, just a normal interface(192.168.1.1/24) - this is were the traffic in question is flowing.

The packet dump shows that the syn ack have the "LAN"(pfsense) interface as the destinaiton, which is correct.

FW logs do show that the traffic gets blocked(see attachment)

fw_log.PNG_thumb

starr

A packet dump form the pfsense WAN inteface shows SYN traffic from the client, but SYN ACK is never transmitted by pfsense. So when the webserver recives the SYN, it responds with the SYN ACK and then pfsense discards thoes packets some how.. Why this is happending is super wierd..

johnpoz

So hold on.. Your firewall rule is showing blocked… This is the SYN coming in from the net.. But you show pfsense forwarding the traffic out the lan to your forward?

Would you mind me Teamviewer to your machine and we could take a look? PM the info and can take a look see to what is going on... This is ODD as shit!

starr

PM sent

johnpoz

So update to this.. I TV in… And yeah its strange... But pfsense looks to be working just fine.

We did a sniff on wan and lan.. And you can see the forward work, server behind answers with syn,ack and pfsense gets this and sends it out the wan interface..

The only thing that makes sense is that port 80 as source port outbound is blocked somewhere upstream from pfsense. The gateway which is bridge mode was not reachable via http but answered ping on 192.168.100.1 -- he was going to try and reset the modem.. Reboot of it did not help.

This would explain why using 8085 to 80 works. Since the return traffic leaving pfsense back to the internet would have source port of 8085 vs 80..

https on 443 was working when we tested it.

Very Strange!!

starr

I sent a fairly detailed mail to my ISP regarding my and johnpoz findings and suspected that my ISP router was the problem.
The ISP replied that the port 80 was closed due to "security reasons"… Even thou I called my ISP earlier that week and asked specifically if they did block that port and the answer was no... This must be a new "security policy" they have applied as the port 80 was "open for forwarding" 1-2 years back on the same router.

But still I can't quite wrap my head around how they block port 80 when the router is in bridge mode? Unless they block it some where in the "ISP net"..

So no problem or bug with Pfsense!:) And many thanks to johnpoz for giving me some really good help:D

johnpoz

Well clearly they are not blocking it INBOUND.. Since you see the syn come into pfsense wan..

What they are doing is blocking any traffic outbound from your network from a source port of 80, ie your answer to anything inbound.

Don't see why they just don't block it inbound.. Would make it so much easier for you to see that is where the problem is ;) But this way guess they can say when users call.. We do not block inbound traffic to you.. And just to forget to mention that we will not allow your return traffic from that port though ;) hehehe

But if they were worried about so called "security" issues for their users and inbound traffic on 80.. Say for example IP camera's etc that the users have opened and get exploited via some web ui, etc. Then they should block it inbound into your IP.

As to how they do it - real simple, you transverse their network to get to and from the internet. They can block any port or protocol they want..

Thanks for updating the thread - puts that issue to bed I guess. Will they open it for you on special request. Does their website state anything about blocking traffic for their services? How come it works for your buddy? Guess they have not gotten around to blocking it on his connection yet? They really should clearly state what they do for "security" when you sign up for their service. Many isp block outbound on 25 for example (smtp) since home connections really have no need for such connectivity.. And for sure can reduce the number of spam bots their users would become ;)

443 was working.. Clear http is dying anyway.. Just host up what you need to host up via httpS..

starr

I asked about what the "security reason" was, but he could not tell me..:P And he instructed me to use port 8080 instead.. which is as much spammed as port 80 I guess.. They do not state in their website that any port is blocked by default or any thing about security for that matter.. I have put in a special request on opening port 80, we'll see how that goes..

As for my buddy, I don't really know, probably don't have the latest update is my guess.