tun2socks not picking up traffic straight after reboot

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Firewall problems maybe?

Original comment by ambr...@gmail.com on 24 Apr 2013 at 12:04

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

whats "Status menu of the TUN interface"?

Original comment by mike...@gmail.com on 24 Apr 2013 at 12:15

[GoogleCodeExporter]

right-click the TUN/TAP/tun2socks interface and choose Status

Original comment by ambr...@gmail.com on 24 Apr 2013 at 12:16

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

I mean the media state of the ehvpn interface, of course.

Original comment by ambr...@gmail.com on 24 Apr 2013 at 1:20

[GoogleCodeExporter]

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