tun2socks not picking up traffic straight after reboot
GoogleCodeExporter opened this issue · 19 comments
What steps will reproduce the problem?
1. After reboot start tun2socks as normal
2. Start proxy server
3. Add/change routing
What is the expected output? What do you see instead?
The traffic should go through the tunnel and then onto the socks proxy but
instead the connection fails. The tun2socks route is the only route available
so all connections simply fail until they decide to start working. I cannot see
any pattern to this, it just appears to start working.
Once it works it will continue to work, even with restarting tun2socks until
the system is rebooted again. Once it is rebooted the procedure must be started
again.
What version of the product are you using? On what operating system?
1.999.127.rc1
Please provide any additional information below.
This problem is only on startup.. if I wait for say 10 mins, sometimes less and
sometimes longer it eventually starts working.. without restarting tun2socks
and using the exact same settings.
When it is not working I can successfully ping both the main gateway (10.5.0.1)
and the second internal IP (10.5.0.2).
tun2socks just sits there saying entering event loop and waits.. if I keep
disabling and reenabling the routing eventually it will successfully route.
Sometimes restarting tun2socks is required, sometimes not.
The prog is being started with the following params:
--tundev tap0901:ehvpn:10.5.0.1:10.5.0.0:255.255.255.0 --netif-ipaddr 10.5.0.2 --netif-netmask 255.255.255.0 --socks-server-addr 127.0.0.1:4021
Any my socks server is running and working on 127.0.0.1:4021.. the routing
table is as follows:
----
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.5.0.2 192.168.0.104 31
8.8.8.8 255.255.255.255 192.168.0.1 192.168.0.104 30
81.94.201.130 255.255.255.255 192.168.0.1 192.168.0.104 30
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
192.168.0.0 255.255.255.0 On-link 192.168.0.104 281
192.168.0.104 255.255.255.255 On-link 192.168.0.104 281
192.168.0.255 255.255.255.255 On-link 192.168.0.104 281
224.0.0.0 240.0.0.0 On-link 127.0.0.1 306
224.0.0.0 240.0.0.0 On-link 192.168.0.104 281
255.255.255.255 255.255.255.255 On-link 127.0.0.1 306
255.255.255.255 255.255.255.255 On-link 192.168.0.104 281
===========================================================================
Original issue reported on code.google.com by mike...@gmail.com
on 24 Apr 2013 at 10:44
- Merged into: #5
I forgot to mention, the local socks server routes traffic to a secondary socks
server located at 81.94.201.130 which is why the entry is there in the routing
table.
Original comment by mike...@gmail.com
on 24 Apr 2013 at 10:46
If tun2socks doesn't say anything about accepting connections, the issue is
most likely not with tun2socks but in strange behavior of the Windows TCP/IP
stack which may sometimes fail to respect route metrics. To be sure, you should
check with Wireshark if there are any packets going into the tun2socks
interface when it's not working.
You're probably hitting issue 5. I'm closing this since I think there's nothing
I can do to fix it; if you determine that it is in fact a problem with
tun2socks, do say so.
Original comment by ambr...@gmail.com
on 24 Apr 2013 at 11:10
- Changed state: Duplicate
It is not the same issue as 5.. I have deleted the main route and can confirm
that all connections now fail.. the problem is that for some reason the traffic
is either not getting to tun2socks or tun2socks is not accepting it
Original comment by mike...@gmail.com
on 24 Apr 2013 at 11:19
Yeah, this is the critical part - do the connections get to tun2socks in the
first place? If they do not, this is not a problem with tun2socks, and I do not
have the resources to investigate it. If you find the reason they don't, feel
free to say so, so I can update the wiki with the problem and possible
workaround.
Original comment by ambr...@gmail.com
on 24 Apr 2013 at 11:23
just checking with wireshark to see if they get to the tun2socks interface..
Original comment by mike...@gmail.com
on 24 Apr 2013 at 11:24
can you please give me a little info on what to look for in wireshark? I
presume I should be monitoring my main network interface and then TAP interface
then check for any traffic going to my 10.0.5.0 network?
Original comment by mike...@gmail.com
on 24 Apr 2013 at 11:31
you should be monitoring the TAP interface. When you try to make a connection,
you should see a TCP SYN packet going into the interface.
Hm, are you sure this isn't actually a problem with your DNS? Does it work if
you try to connect directly to an IP address without using a domain name?
Original comment by ambr...@gmail.com
on 24 Apr 2013 at 11:35
No, connecting direct to IP does not help.
I have just noticed that with routing as normal I can ping 10.5.0.1 but not
10.5.0.2.
I am sure that when this is working I should be able to ping 10.5.0.2 as well?
Original comment by mike...@gmail.com
on 24 Apr 2013 at 11:54
mmm, now the ping works and the connection works! any idea why it would not be
workign after a reboot?
Original comment by mike...@gmail.com
on 24 Apr 2013 at 11:56
def something going on there.. after reboot ping 10.0.5.2 fails again.. and
connection fails with routing setup.
I have no idea what that means but looking at your documentation 10.0.5.0
(10.0.0.2 in your doc) should be the IP of the internal router inside the TUN
device.
Any idea why 10.0.5.1 would work but 10.0.5.2 not based on this startup param?
--tundev tap0901:ehvpn:10.5.0.1:10.5.0.0:255.255.255.0 --netif-ipaddr 10.5.0.2
--netif-netmask 255.255.255.0 --socks-server-addr 127.0.0.1:4021
Original comment by mike...@gmail.com
on 24 Apr 2013 at 12:00
Firewall problems maybe?
Original comment by ambr...@gmail.com
on 24 Apr 2013 at 12:04
no, just disabled windows firewall and still not pinging.. also would not
explain why 10.0.5.1 works where .2 doesn't.
I appreciate that this is an open source project and that you are not earning
out of this.. I really am very keen to get this problem sorted and I would be
more than willing to pay a support fee to help get this working?
Original comment by mike...@gmail.com
on 24 Apr 2013 at 12:07
Here are the details in an rtf (your service does not allow zip/rtf)
http://www.fileconvoy.com/dfl.php?id=gee9455a7492730f699927366807216d819d14f3dd
Original comment by mike...@gmail.com
on 24 Apr 2013 at 12:54
See this in your ipconfig /all:
Media state: media disconnected
This is very concerning. Are you sure the ipconfig was done while tun2socks is
running? The media state should change to connected (disappear in ipconfig)
when tun2socks starts up.
Original comment by ambr...@gmail.com
on 24 Apr 2013 at 1:19
I mean the media state of the ehvpn interface, of course.
Original comment by ambr...@gmail.com
on 24 Apr 2013 at 1:20
Post your ipconfig /all please, screenshot the Network Connections, and the
Status menu of the TUN interface, when it's not working. You can use use
http://www.pasteall.org/pic/ for pasting pics.
Original comment by ambr...@gmail.com
on 24 Apr 2013 at 12:13
whats "Status menu of the TUN interface"?
Original comment by mike...@gmail.com
on 24 Apr 2013 at 12:15
right-click the TUN/TAP/tun2socks interface and choose Status
Original comment by ambr...@gmail.com
on 24 Apr 2013 at 12:16
I'm trying to simulate the problem again but of course it doesn't want to break
now!
If I do not get back to you today I will be away for the next few days but will
get back to you early next week.
Original comment by mike...@gmail.com
on 24 Apr 2013 at 2:59