Some websites not responding
-
I ran a packet capture on the WAN and LAN interfaces. On the WAN I can see the SYN and ACK packets flowing as I would expect. On the LAN side, the ACKs never make it there. So, there is some sort of disconnect between the WAN and the LAN. I don't see anything in any of the logs.
There's got to be a way to trace the traffic, I just don't know what it is.
e
-
WAN/LAN connectivity is usually an all-or-nothing deal. I can't even fathom how the firewall would decide to selectively break some websites, but only on some of your clients. No caching involved such as Squid?
-
No squid, no packages installed at all. Just the base system configured with bridging, that's it.
It seems really bizarre to me as well. I can only think that there must be something specific to that traffic that is causing some sort of failure, but I can't figure out how to track it down.
e
-
I'd start at the back end. You have clients that consistently fail to render a site that is fine in other clients? What is different between these clients? What's different between sites that always works and problem sites (eg HTTPS)? Are you allowing IP6?
-
um if your trying to use pfsense as transparent bridge firewall. Then there really wouldn't be a wan would there? It would be a bridge interface.. pfsense would not be the dns server normally in such a setup, etc. And by default I don't even think it firewalls traffic over a bridge. Don't you have to that?
What guide did you follow to setup this sort of setup?
What if you just let pfsense do its thing and route and nat the connection?
-
haha - So we are now finding out pfsense is in some bizarre configuration?
-
johnpoz,
Looks like you found me the magic bullet. In the guide I used for the bridging setup, it did have me turn on filtering on the bridge interface (net.link.bridge.pfil_bridge=1). I had assumed that was required for bridging, but apparently not. I've set that back to default, the bridging still works and I am still able to set firewall rules and limiters, etc. Craigslist is also now responding. I think that's got this problem solved. Now to find new, more exciting problems.
Kejianshi, I did mention in my first post that I was using a bridged setup. :)
Kejianshi, KOM and johnpoz, thank you all so much for your help. This is a great community and I'm glad I found my way here.
e
-
Without even looking at the guide - can tell you its dated, link says 2.0.1, your on 2.2 are you not? Shitload of changes since 2.0
-
Yeah, I am on 2.2. I searched, but I didn't find any newer guides. Everything I found on setting up bridging was 2.0 or older. Is there a newer, better way of doing bridging?
e
-
Paul,
Did you ever find a resolution for this issue? We just deployed a brand new pfsense firewall (2.2.1) this morning and we have the exact same issue.
All API calls fail form servers behind the firewall. Its a transparent bridge setup with all public IPs (no NAT no DHCP).
Thanks
-
Call this a shot in the dark…
I had a great deal of problem with a handful of sites after I upgraded from 2.1.5 to the 2.2 beta. My problem turned out to be excessive & unexplained IP fragmentation occurring somewhere between the remote site and the firewall. For some reason, 2.1.5 had no problem with this, but in 2.2 did. Setting the "Clear Invalid DF bits" did not address the problem.
In the end, what fixed my issue was to clamp the media segment size to 1400 on the WAN interface. You might give clamping a try and see if it has any effect.
-
Just tried that. It did not work.
