Odd Craigslist Issue
-
It's hard to see how this can be anything other than a client side issue. When it fails the client never ACKs the servers SYN-ACK. It fails the initial TCP handshake. Either the SYN-ACK from the server never makes it back to the client or the client never responds to it. A capture actually on the failing client would show which.
Are those pcaps on the pfSense LAN? Since they are bridged they should be the same but...Steve
-
@stephenw10 The pcaps are on the pfSense WAN. I will run a pcap on a failing system.
-
@stephenw10 I ran a pcap from one of the systems that time out. Refreshed craigslist.org. Applied filter: ip.addr == 208.82.237.226 and get a blank result. How can packets not be leaving the NIC?
-
@stephenw10 See attached. These are pcaps from a system that times out and a system that successfully connects. Both are on the LAN. Note how the "Not Working" starts with .17 and the "Working" starts with .2 and never shows packets to or from .17.
-
Interesting. Do they both resolve craigslist.org to the same IP?
Steve
-
@stephenw10 Yes 208.82.237.226
-
Is there any security or AV software or browser plugins on the affected machine.
-
@grimson No, all have been disabled. Let me also reiterate that the machines that time out can successfully connect if plugged directly into the modem. This very much seems to be a pfSense problem, but I cannot for the life of me understand what the issue is or even where to look.
-
Any other suggestions?
-
@sabyre said in Odd Craigslist Issue:
Any other suggestions?
Wipe your pfSense installation. Leave a basic, default configuration on it and then connect a client to it. See if you can repeat the issue.
It could be a config issue buried deep somewhere that we're not looking. A default install turned into a bridge would eliminate a config issue (in theory). You can save your old configs and re-import them after the test.
It shouldn't be behaving like it is, and if it truly is a pfSense issue, testing a default install with minimal configurations may help resolve this.
-
@tim-mcmanus I was trying to avoid that, but thank you for the response. It seems that may be the best option at this point.
-
I know you've kind of covered this but could Squid or some proxy caching be causing the issue? Or did you have it and remove the package where there may be some remnants? One PC could be set to be ignored and allow all traffic. Could explain why that one PC can connect but the others can't?
Just throwing something out there.
-
@stewart Excellent reply, thank you. I did have Suricata installed at one point, however it would crash and need a restart every couple of weeks. Downtime tends to make customers angry. So I disabled it. It is still installed, just not running.
-
@sabyre I've had a lot of experience with Suricata doing odd things. Under Diagnostics-Table is there anything in the Snort2c table?
-
@stewart Good call, I didn't think of that, but alas it is empty.
-
Yeah disabling Suricata (or Snort) or even uninstalling it does not necessarily remove any blocks.
At this point I would be setting it to a basic config to test. It's easy tot restore your current config if it doesn't help.
Steve
-
@stephenw10 Yeah, I've been bit by that before.
@Sabyre On an affected machine, what does a traceroute show? Also, I've used a program called PingPlotter (there is an old freeware version floating on the internet) that graphically combines Ping and Traceroute. I'm curious what a trace would show since you said you don't see packets going to the router.
-
@stewart That's a nice program. I hadn't used it before. So I ran a trace with the program on the working machine and on the fail machine. Both results are identical with the exception of the final destination.
On the working machine the trace ends at 208.82.237.2
On the fail machine the trace ends at 208.82.237.242Both IP's belong to CL. On either machine there is only one CL IP in the trace.
-
@stewart And when running it again on both they both end with 208.82.237.18
-
@sabyre If you do a dump, is there any http/https traffic that gets passed on the failed attempt? The varying IP could explain the difference. From the CLI you can try running the "host" command to see the varying IPs that get reached. For me it would be:
/root: host orlando.craigslist.org
orlando.craigslist.org is an alias for cities.g.craigslist.org.
cities.g.craigslist.org has address 208.82.237.130
cities.g.craigslist.org mail is handled by 10 mxicorpa.craigslist.org.@stephenw10 is probably correct but I'm always curious as to what is happening. Reloads usually fix things but it never satisfies the "Why" for me.
