-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connection originates from a wrong IP when using VPN #113
Comments
A timeout ("Timeout in Discover: ...") in discovery() means that your peer is behind a NAT or firewall. Discovery contacts a peer that is well reachable in the Internet and tells this peer to contact my peer behind the NAT. The well reachable peer will most likely see the IP 178.* and try to contact this peer on port 7700. Since this is your VPN server, the packets will be dropped and thus you see a timeout. So seeing a timeout is normal when your peer is not reachable. |
Could be it but why can't I connect to that peer? I'm doing bootstrap later and still have no traffic on tun0: FutureBootstrap fb = dhtPeer.peer().bootstrap().inetAddress(inetAddr).ports(7700).start();
fb.awaitUninterruptibly(); Also, forgot to provide the log:
And I can connect to that ip/port via telnet, no problem. |
Interesting, its not a regular discovery timeout issue, but it seems that you cannot establish a TCP connection to rkfg.me. In the latest commit, I exposed now fromAddress in ChannelClientConfiguration. Can you try to set it to 0.0.0.0 and see what happens? |
Thanks, this way it works fine. Here's what I added: Peer basePeer = new PeerBuilder(Utils.makeSHAHash(keyPair.getPublic().getEncoded()))
.keyPair(keyPair)
.ports(7700)
.channelClientConfiguration(
PeerBuilder.createDefaultChannelClientConfiguration().fromAddress(InetAddress.getByName("0.0.0.0"))).start(); |
My bad, forgot that I set the direct route to my own server. Maybe that's what caused the confusion, the default route pointed to the tun0 interface while the target peer was accessible directly via br0 because of that one route? So far, looks good to me though that 0.0.0.0 fromAddress should definitely be set by default. |
Thanks for testing. Hmm, I had issues in my NAT setup with 0.0.0.0, I need to investigate this. Most likely I need to open two connections and see what is coming back. With 0.0.0.0, which interface was used? Is it going through br0? The thing in Java is that you cannot set a sending interface, just set an inetaddress and it will figure out the interface. I wonder why this is not the case with 10.6.0.29. This should be clearly going out through tun0. |
It's going through the right interface, br0 in this case with the direct route (for my server) added. After I remove it, it also works fine switching to tun0. Everything is as it should be, double checked with Wireshark. Actually, the situation in the first post should be described a bit more correctly. The problem was not the interface but the source address. As I said, I forgot about that "exclusion" route that allows me to bypass VPN for my server so any traffic to it goes from br0 and it was actually right. The wrong thing was the IP selected as the source, 10.6.0.29, while it should have been 172.25.10.35. And another one little thing: Could it be that TomP2P takes the first discovered interface as the source "by default"? |
Fixed the issue title and the first comment. |
Yes, TomP2P takes the first non-local interface. To make TomP2P robust for "exotic" network configuration, I should test various source addresses and see what is coming through. |
The code is as simple as this:
I'm getting a timeout because connection initiates from a wrong interface as seen in Wireshark. Here's what I have:
Internet is available on both interfaces but routing is set up to route all traffic through tun0 (except the VPN server I connect to). It's a bit weird:
0.0.0.0/1 via 10.6.0.1 dev tun0
default via 172.25.10.36 dev br0
10.6.0.0/16 dev tun0 proto kernel scope link src 10.6.0.29
172.25.10.0/24 dev br0 proto kernel scope link src 172.25.10.35
128.0.0.0/1 via 10.6.0.1 dev tun0
178.xxx.xxx.xxx via 172.25.10.36 dev br0
172.25.10.36 is my router, 178.xxx.xxx.xxx is the VPN server. This solution allows to replace the default route without actually removing it by creating two /1 subnets that together fully cover the IPv4 address space and have priority over /0 default route. That's not my invention, it's how the VPN provider set it up. Enough with these technical details, sufficient to say I don't have any issues with it and all network software just works.
So, TomP2P tries to connect to some Internet IP via TCP from br0 interface but sends the SYN packet originating from 10.6.0.29! The source IP is
valid but the interface is not, it should be tun0 insteadinvalid while the source interface is fine (explained in further comments). Of course, my router is still accessible and probably TomP2P discovers it via UPnP but all the traffic goes through VPN. I tried.bindings(new Bindings().addInterface("tun0"))
but still there's no traffic on tun0 (and it's also fine, tun0 shouldn't be involved, explained further).The text was updated successfully, but these errors were encountered: