Resolved Mysterious TCP block?

[Let's Sekuhara!]

This is bizarre. I can't connect to the internet on my iMac because all sorts of connections are being blocked. No TCP connections are going through. I can successfully ping an IP address through Terminal because ping is ICMP, not TCP.

The problem came up seemingly randomly today. It was working fine a couple of days ago.

At first it seemed to be specifically a DNS problem, but now it's clear that it is something beyond that.

UDP may also not be working because I can't ssh.

Any ideas? Please help!

[OS X 10.8.2]

 

[vmachiel]

Check your router settings, do they have some option for port blocking?

 

[Let's Sekuhara!]

Check your router settings, do they have some option for port blocking?

Thanks but it's not a router issue. There are several other Macs connected with no problems.

 

[vmachiel]

Thanks but it's not a router issue. There are several other Macs connected with no problems.

Maybe setting up the connection as new again? https://discussions.apple.com/message/16563566#16563566

 

[Let's Sekuhara!]

Maybe setting up the connection as new again? https://discussions.apple.com/message/16563566#16563566

Thanks, but I've tried that. No luck.
I suspect it's not a network configuration thing,
but rather something deeper in the system.

I had a firewall (Little Snitch) running, although after running into this problem I turned it off, and after still not being able to connect I completely uninstalled it (using the official uninstaller). This didn't resolve the issue.

I also tried creating a new user account and attempted to connect while signed in to this new test account. But it still won't connect to the internet. (It connects to Wi-Fi, just won't pull data through the connection)

 

[vmachiel]

Thanks, but I've tried that. No luck.
I suspect it's not a network configuration thing,
but rather something deeper in the system.

I had a firewall (Little Snitch) running, although after running into this problem I turned it off, and after still not being able to connect I completely uninstalled it (using the official uninstaller). This didn't resolve the issue.

I also tried creating a new user account and attempted to connect while signed in to this new test account. But it still won't connect to the internet. (It connects to Wi-Fi, just won't pull data through the connection)

Are you sure this isn't a router issue? Isn't there some setting in there that limits traffic to your local IP?

 

[Let's Sekuhara!]

Are you sure this isn't a router issue? Isn't there some setting in there that limits traffic to your local IP?

The person who set up the network was confident it was nothing in the router settings or network settings.
Let me ask you however, is there any reason a router would block a local IP suddenly?

 

[satcomer]

The person who set up the network was confident it was nothing in the router settings or network settings.
Let me ask you however, is there any reason a router would block a local IP suddenly?

What router are you using? I ask because there is story called D-Link routers authenticate administrative access using specific User-Agent string you should be aware of.

 

[mfram]

One possibility to look into is MTU weirdness. If there are mismatched MTU values on different segments on the network, it can cause problems because larger IP packets could be dropped by the network. Apps that use TCP would lend themselves to applications that could use large IP packets.

One place MTUs could be artificially lowered is if there's a VPN involved. Another problem I've seen is with a mis-configured DHCP server at an ISP that was sending out bogus values for MTU. I think Windows tends to ignore that information, but a Mac (or your router) may pay attention to it which would be a problem.

Normal MTU over an ethernet segment should be 1500.

Linux 'ping' offers the -s argument to specify a packet size. I don't have a Mac in front of me at the moment to see if that same option is available. If so, use a larger size like 1490 and see if the ping goes through.

 

[Let's Sekuhara!]

One possibility to look into is MTU weirdness. If there are mismatched MTU values on different segments on the network, it can cause problems because larger IP packets could be dropped by the network. ...

Thanks for the idea. We played with changing the MTU value, but to no avail.

The conclusion we're coming to is that there's something in the software configuration of this Mac that has somehow been changed, possibly by malware or a corrupt setting file that is causing certain types of connections to be refused.

Pinging a domain name fails. (Seems it can't resolve DNS)
Pinging an IP address succeeds in Terminal but if that IP address is entered into a browser it fails to connect to the site. (I think because when going through an application TCP is used?)

Connecting to another machine on the network via ssh fails (from both directions), yet via ftp succeeds! Strange.

We get the same results whether physically connected through a LAN cable or wirelessly through Wi-Fi.

We can view the router settings page through the browser, but all router settings appear normal and all other connected devices are functioning as normal.

----------

Another reason we believe there is something blocking the connection from the Mac's software configuration locally is that when connections are "refused" or fail the error message is returned instantaneously. It's not like it's taking a moment to talk to the network and then failing. The request never makes it out in the first place.

 

[ElectricSheep]

Couple of things to try....

Check the state of the ipfw and pf packet-filters:

sudo ipfw show
sudo pfctl -s all

the default ipfw rule is to allow ip any from any, and the pf should be disabled (Status: Disabled; all counters should be zero).

You can perform manual dns lookups with nslookup, optionally specifying a specific DNS server to override the system configured DNS server:

nslookup www.google.com 208.67.222.222 (using one of OpenDNS's servers)

Running nslookup without specifying a server address will report the configured server.

scutil --dns will provide comprehensive information with how the resolver is configured on the Mac. There will be quite a few entries for local, multicast, and ipv6; you are interested in resolver #1. You can test reachability with scutil -r www.google.com.

If you can on another machine, download lft (Layer Four Traceroute) and copy it to the target machine. You may have to build from source, and libpcap must also be installed. Its a much more flexible traceroute tool that allows for using protocols alternative to ICMP.

 

[Let's Sekuhara!]

scutil --dns will provide comprehensive information with how the resolver is configured on the Mac. There will be quite a few entries for local, multicast, and ipv6; you are interested in resolver #1. You can test reachability with scutil -r www.google.com.

IT IS FIXED! YESSSSSSSS!

The culprit was either a Dropbox auto-update or something in /Library/Preferences/SystemConfiguration
Since Dropbox updated itself on the 16th I believe Dropbox is most likely the cause.

Steps to resolve:
I quit Dropbox, deleted Dropbox.app and DropboxHelperTools
(Steps to uninstall Dropbox here)

I also deleted the contents of /Library/Preferences/SystemConfiguration
(No known connection to Dropbox, but it's another step I took. Mentioning it just in case.)

I then rebooted. And once again I can connect to the internet!

Symptoms:
It is interesting to note that before deleting said files scutil --dns would list only resolver #1 with if_index being 5.
After resolving the problem scutil --dns now lists resolvers #1 through #8, and the if_index of #1 is now 6.

Thank you ElectricSheep and everyone who contributed ideas in this thread!
I was on the verge of wiping my drive and reinstalling OS X.

 

[ElectricSheep]

I'm glad you resolved your issue (no pun intended). The reason for the inconsistent behavior is that DNS resolution on MacOS X is a little bit funny depending on what is doing the lookup. For most basic posix/command-line/non-cocoa applications, the contents of /etc/resolv.conf governs what name servers will be used for DNS queries.

However, starting with MacOS X 10.6, name resolution is handled by mDNSResponder, which consolidates lookups for multicast (Bonjour/Rendezvous) and unicast (traditional DNS lookups) requests. mDNSResponder uses the SystemConfiguration, stored in /Library/Preferences/SystemConfiguration/. This collection of property lists forms a database which can be manipulated by scutil. If something gets screwed up, it can affect DNS requests from some applications but maybe not others.

This is also why you should not disable mDNSResponder unless you know what you are doing; its not just for Bonjour/Rendezvous anymore.

 

[Let's Sekuhara!]

What's odd is that in the end I had to do a complete reinstall anyway.
Still not sure if it was a Dropbox issue or something else.
But the TCP problems came back after a week or so.

Figured that the time I'd need to spend pinpointing the issue would be greater than simply reinstalling, so I chose the later.

Oh well. In the end I have to chalk it up to being one of those inexplicable issues that you just gotta let go and start over.