Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I was playing around with SSH and trying to route traffic through my laptop. In the end I succeeeded, however I seem to have messed up my network. I only used ssh and played around with both -D and -L flags. I am running Arch.

I can browse with chromium just fine after setting having set up a socks5 proxy:

$ ssh -D 1339 HOST
$ chromium --proxy-server="socks5://localhost:1338"

If I do not use this socks proxy, I can not browse. And my network does not seem to be able to make any connections through any port (not even 1338):

$ telnet google.com 80
Trying 157.157.135.91...
Connection failed: No route to host
Trying 157.157.135.102...
Connection failed: No route to host
Trying 157.157.135.117...
...
Connection failed: No route to host
Trying 2a00:1450:400b:c02::64...
telnet: Unable to connect to remote host: Network is unreachable

Checking to see if port 80 is used yields no results:

$ sudo fuser 80/tcp

Just to make sure it would be see my socks proxy:

$ sudo fuser 1338/tcp
1338/tcp:           20208

My iptables configuration has never been touched:

$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 42955 packets, 14M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 36322 packets, 2196K bytes)
 pkts bytes target     prot opt in     out     source               destination 

I cannot whois:

$ whois google.com
connect: Network is unreachable

However, I can ping:

$ ping google.com
PING google.com (157.157.135.123) 56(84) bytes of data.
64 bytes from hysing-123.simnet.is (157.157.135.123): icmp_seq=1 ttl=62 time=6.96 ms
64 bytes from hysing-123.simnet.is (157.157.135.123): icmp_seq=2 ttl=62 time=6.87 ms
64 bytes from hysing-123.simnet.is (157.157.135.123): icmp_seq=3 ttl=62 time=6.66 ms

There is nothing grep -i http or grep -i proxy is catching in my env, and /etc/environment is empty.

I am completely lost. Does anyone have any idea what is going on?

Edit with traceroutes: The IP address I get from pinging google is from my ISP.

I'm not sure what to read from these traceroutes, the requestt does not seem to get further than my gateway:

$ sudo traceroute -n -T -p 80 google.com
traceroute to google.com (157.157.135.123), 30 hops max, 60 byte packets
 1  192.168.1.254  2083.374 ms  88.990 ms  88.625 ms
 2  192.168.1.254  88.168 ms !H  87.715 ms !H  87.254 ms !H

$ sudo traceroute -n -T -p 443 google.com
traceroute to google.com (157.157.135.123), 30 hops max, 60 byte packets
 1  192.168.1.254  2006.803 ms  13.076 ms  12.669 ms
 2  192.168.1.254  12.210 ms !H  11.740 ms !H  11.335 ms !H

ICMP packets are answered by my ISP.

$ sudo traceroute -n -I google.com
traceroute to google.com (157.157.135.123), 30 hops max, 60 byte packets
 1  192.168.1.254  6.263 ms  5.779 ms  5.335 ms
 2  * * *
 3  157.157.135.65  12.034 ms * *
 4  157.157.135.123  12.861 ms  6.706 ms *
share|improve this question

migrated from serverfault.com May 25 '14 at 18:22

This question came from our site for system and network administrators.

1 Answer 1

up vote 1 down vote accepted

The IP address you are getting for google.com does not belong to Google. That can mean one of two things, either DNS is being hijacked (possibly by the ISP), or Google has a frontend deployed on an IP belonging to the ISP.

First of all you should try DNS lookups of different domains through different DNS servers, to see if they are all being hijacked, or if the DNS results you get from google.com are legitimate.

Next you can try to compare the output of

  • traceroute -n -T -p 443 google.com
  • traceroute -n -T -p 80 google.com
  • traceroute -n -I google.com

This should tell you how far the packets are getting before you run into a problem. The problem you are seeing could not have been caused by just running the ssh command you were running or the change of settings in Chrome.

The traceroute output shows a few interesting details. When tracing with ICMP echo request packets, the replies are quick and the target is four hops away. When tracing with TCP packets to port 80 or 443, the first hop responds slowly, the delay looks like a typical ARP timeout.

Whatever is blocking the requests, the reason is most likely on 192.168.1.254, which is the router your computer is connected to.

share|improve this answer
    
Thanks for your help. I've edited the question with these results. I'm not sure what to make of them though. –  eythor May 25 '14 at 18:57
    
Yes, the router was the problem. I rebooted it and my desktop works now. I thinkt he reason my laptop still could connect was because it was connected to a VPN network. Could that be? –  eythor May 25 '14 at 19:22
    
@eythor The VPN connection might not have been affected. And if the laptop was connecting to sites through the VPN, then that would have been unaffected as well. –  kasperd May 25 '14 at 19:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.