1

I am using the great technique from How can I get my external IP address in a shell script? to find my public IP address:

dig +short myip.opendns.com @resolver1.opendns.com

I'm also using sshuttle as a proxy over ssh tunnel. It is started to forward traffic on all ports and IPs (including DNS requests) using the following command:

sshuttle --dns -vr usr@sshserver 0/0

After the proxy has started I visit https://canihazip.com/s to verify that my external IP has changed. It has, but when I run the dig command again, it reports the same external IP reported as before the proxy was started.

From the verbose output, sshuttle seems to be forwarding on other dig commands, and checking https://dnsleaktest.com only reveals the IP on the other end on my proxy, as expected. As far as I can tell sshuttle seems to be working.

Can anyone explain why the dig command reports my external IP before the proxy? My aim is make it seem to the opendns servers that the request is originating from my ssh server.

It's a bit over my head, but I had a quick look in Wireshark and when filtering for DNS traffic Wireshark doesn't see any DNS requests apart from the above DIG command. The command is bypassing the proxy.

I'm happy to use any of the other (less elegant) ways to find my external IP, but this makes me ask the question: what else is bypassing sshuttle?

3
  • Would you able to explain this better, or provide evidences? It sounds strange the same command producing different results. Jun 12, 2018 at 12:29
  • @RuiFRibeiro I'd added some clarity, does that help? The command is run before the proxy, then after, but both give me the same external IP. Despite icanhazip giving me different external IPs. Any specific evidence you are looking for?
    – alcafly
    Jun 13, 2018 at 10:46
  • That explains it, it was not entirely clear the first command was done without using the proxy. Jun 13, 2018 at 11:16

2 Answers 2

1

Now that you have used the -v option to show debug message when running shuttle command, you can find that shuttle created some iptables rules. One of the rules is as follows:

iptables -t nat -A sshuttle-12300 -j REDIRECT --dest <nameserver>/32 -p udp --dport 53 --to-ports 12299

The rule above redirects the DNS request sent to <nameserver> to shuttle proxy port. Shuttle finds these <nameserver>s in /etc/resolv.conf file and automatically create iptables rules accroding to them.

So when the dig command make DNS queries using the nameserver defined in /etc/resolv.conf file, it will be proxied by sshuttle, but if not, it will not be proxied.

In your case, the address of resolver1.opendns.com which is 208.67.222.222 is not defined in your /etc/resolv.conf, so it will not be proxied by sshuttle.

0

The gateway has two external IP addresses. The NAT running on the gateway employs some kind of load balancing. It can be based on the destination IP or protocol type. If this is the case the source IP address of the DNS queries and HTTP packets will be different.

2
  • Sorry, I'm not sure what you mean. What gateway? How is dig leaking my "true" (un-tunnelled) IP?
    – alcafly
    Aug 6, 2018 at 13:22
  • My bad, please ignore the response
    – Larytet
    Aug 12, 2018 at 11:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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