Accessing facebook.com in browser gets This webpage is not available

[d0u9]

When I visit www.facebook.com in my Chrome with sshuttle is on, the browser respond me that This webpage is not available.

However, the www.twitter.com is opened correctly. I don't know why.

By the way, when I execute curl www.facebook.com or curl www.google.com in my terminal, curl: (56) Recv failure: Connection reset by peer is dumped.

The way that I run sshuttle is sshuttle --dns -vvr tri-doug@do6.d0u9.xyz 0/0.

---

I think it is still due to the IPV6 address of my remote sever...

---

if I access ipv4.google.com, everything is fine.

[brianmay]

Yes, IPv6 will be the issue. Unfortunately, IPv6 is not supported unless you use the TPROXY (Linux only) firewall method.

Going from memory here, before you use TPROXY you need to run the following commands as root. This only needs to be done once:

ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
ip route show table 100
ip -6 route add local default dev lo table 100
ip -6 rule add fwmark 1 lookup 100
ip -6 route show table 100

You then need to run sshuttle (as root) and use the --method=tproxy option.

Unfortunately my tests this morning have failed, sshuttle isn't intercepting the outgoing connections. I haven't used the TPROXY method in some time, so not sure if I have forgotten something important or the latest kernel (4.2.0) I am using has changed something.

TPROXY is somewhat complicated to understand, and even worse to try and debug - will see if I can see what is going on.

[brianmay]

On second thoughts, TPROXY shouldn't be required just because you are connecting to the remote server via IPv6. It is only required if transporting IPv6 connections across the tunnel. You might need to do this if your remote server only supports IPv6 and not IPv4.

[brianmay]

Have got TPROXY support working for IPv4 and IPv6 TCP. TPROXY works by intercepting packets already in transit. This means if the client side doesn't have IPv6 support, there will no IPv6 routes, and no IPv6 traffic to intercept. In this case need to add a dummy IPv6 route, so the system will attempt to send the data - e.g. to eth0, where it can be intercepted by sshuttle.

[brianmay]

Not absolutely sure this was an IPv6 issue. If it is the case that your remote server doesn't support IPv4, it will be a IPv6 issue. Otherwise, IPv6 should fall back to IPv4, and IPv4 should be getting transported just fine.

[brianmay]

No response; closing. Can get reopened. If you do want to reopen, please provide more debugging information.