[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

[Openvpn-users] Linux-XP Incomplete Connection.


  • Subject: [Openvpn-users] Linux-XP Incomplete Connection.
  • From: Chris Mills <millsspam@xxxxxxxx>
  • Date: Fri, 1 Oct 2004 07:34:41 +0000 (UTC)

This is a reposting of an earlier thread, but more refined and focused. Please
ignore the earlier post. I did my best to be as complete as possible in
researching the problem and provided all (hopefully) relevant information.

Problem:

My Linux-XP point-to-point tunnel connection is not completely connected. I can
ping the Linux tunnel adapter ip address from XP but I can't ping the XP tunnel
adapter ip from Linux.

Software and Versions:

- Devil-Linux Distribution (Firewall, iptables based running off CDROM, floppy)
- Openvpn 1.5 running on Devil-Linux (impractical to change this to 2.0)
- WinXP/Pro (SP1) (laptop)
- Openvpn 2.0 running on laptop  (tried 1.6 also. Same problem)

What I have done and learned in my investigations:

1) The peers connect, acknowledge each other, and show the udp packets via
   verb 5 (WRwr...)
2) Devil-Linux tunnel ip: 10.3.0.1, XP tunnel ip: 10.3.0.2
3) Internal subnet of Devil-Linux 192.168.2.0/24
4) Internal subnet of WinXp laptop 192.168.1.0/24
5) WinXP laptop behind a wireless router NATed to the Internet.
6) WinXP laptop can ping both tunnel ips upon connection.
7) Devil-Linux can ping its local tunnel ip, but not the WinXP ip tunnel ip.
8) Devil-Linux has direct interface to Internet with a global ip of
   xxx.xxx.xxx.20/248. (Xed out for security, of course).

Further investigation using tcpdump, Ethereal, and verb 11 has revealed the
following:

1) When pinging WinXP laptop from Devil Linux the ip packet is sent out onto
   the Devil-Linux tunnel ip.
2) UDP packets are sent between the machines. I can see them using verb 5,
   and the sniffing tools. They are transmitted in lock step with the ICMP
   packets.
3) Turning on verb 11 on XP appears (in my educated guessing from examining the
   output) to show receipt of a UDP packet, and a follow on that looks like
   it decrypts the data, perhaps verifies it, and writes it to the tunnel
   "driver". (see output of verb 11 on XP at the end of this post).
   There is no obvious reply from the tunnel write that jumps out
   to my unversed eye. It appears to go back to waiting for the next UDP packet.
4) So data to the tunnel from UDP on XP appears to go into a black hole at the
   tunnel write.
5) No activity of any kind appears on the XP tunnel ip when watching with
   Ethereal. I see the UDP packets on the wireless interface, and that is
   all.

What follows are the Openvpn config files, the route tables, and the verb 11
output from the XP machine.

Devil-Linux Openvpn config file:

dev tun1
ifconfig 10.3.0.1 10.3.0.2
secret key.txt
port 5000

tun-mtu 1500
tun-mtu-extra 32
mssfix 1450

verb5
ping 10


WinXP Pro config file:

remote xxx.xxx.xxx.20
dev tun1
ifconfig 10.3.0.2 10.3.0.1
secret key.txt
port 5000

tun-mtu 1500
tun-mtu-extra 32
mssfix 1450

verb 11
ping 10



The XP route print output. (Please note, the laptop is docked with both
an ethernet adapter in the docking station, a PCMCIA ethernet card, as
well as the wireless adapter. Only the wireless adapter is active.):

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 09 5b 45 97 e4 ...... NETGEAR WG511 54 Mbps Wireless PC Card -
                                   Packet Scheduler Miniport
0x3 ...00 10 a4 a7 45 0d ...... Xircom CardBus Ethernet II 10/100 - Packet
                                   Scheduler Miniport
0x4 ...00 ff c0 0a 75 3c ...... TAP-Win32 Adapter V8 - Packet Scheduler
                                   Miniport
0x5 ...00 b0 d0 59 dd 64 ...... 3Com 3C920 Integrated Fast Ethernet
                                   Controller (3C905C-TX Compatible
) - Packet Scheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1   192.168.1.100       40
         10.3.0.0  255.255.255.252         10.3.0.2        10.3.0.2       30
         10.3.0.2  255.255.255.255        127.0.0.1       127.0.0.1       30
   10.255.255.255  255.255.255.255         10.3.0.2        10.3.0.2       30
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.1.0    255.255.255.0    192.168.1.100   192.168.1.100       40
    192.168.1.100  255.255.255.255        127.0.0.1       127.0.0.1       40
    192.168.1.255  255.255.255.255    192.168.1.100   192.168.1.100       40
        224.0.0.0        240.0.0.0         10.3.0.2        10.3.0.2       30
        224.0.0.0        240.0.0.0    192.168.1.100   192.168.1.100       40
  255.255.255.255  255.255.255.255         10.3.0.2        10.3.0.2       1
  255.255.255.255  255.255.255.255    192.168.1.100   192.168.1.100       1
  255.255.255.255  255.255.255.255    192.168.1.100               3       1
  255.255.255.255  255.255.255.255    192.168.1.100               5       1
Default Gateway:       192.168.1.1
===========================================================================
Persistent Routes:
  None


Devil-Linux Route table (I don't think this is relevant to this problem
since the ping packet is shown heading out the tun1 interface,
and the UDP heads across. I included it for completeness):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.3.0.2        *               255.255.255.255 UH    0      0        0 tun1
255.255.255.255 *               255.255.255.255 UH    0      0        0 eth1
xxx.xxx.xxx.16  *               255.255.255.248 U     0      0        0 eth0
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1
default         xxx.xxx.xxx.17  0.0.0.0         UG    0      0        0 eth0



A segment of verb 11 output which looks like the ping receipt (with global
ip replace by xxx.xxx.xxx.20 for security):

Thu Sep 30 23:39:41 2004 us=825120 WIN32 I/O: Socket Completion success [124]
Thu Sep 30 23:39:41 2004 us=843007 UDPv4 read returned 124
Thu Sep 30 23:39:41 2004 us=859953 UDPv4 READ [124] from xxx.xxx.xxx.20:5000:
DATA f8bb06f4 eaa6242c 51ca755b c64ca87d 8fbc2f2d 1ae7cb73
9f3fd7f7 06ff5fa[more...]
Thu Sep 30 23:39:41 2004 us=893555 DECRYPT IV: 1ae7cb73 9f3fd7f7
Thu Sep 30 23:39:41 2004 us=910483 DECRYPT TO: 0000251d 415cbe0d 45000054
63a74000 4001c2f9 0a030001
 0a030002 0800ffc[more...]
Thu Sep 30 23:39:41 2004 us=957523 PID TEST 1096597005:9500 1096597005:9501
Thu Sep 30 23:39:41 2004 us=964815 WE_CTL n=0 ev=0x0044f574 rwflags=0x0001
arg=0x0040b4f0
Thu Sep 30 23:39:41 2004 us=983219 WE_CTL n=1 ev=0x009d1900 rwflags=0x0000
arg=0x0040b4e8
Thu Sep 30 23:39:41 2004 us=998098 WE_CTL n=1 ev=0x009d72f8 rwflags=0x0003
arg=0x0040b4ec
Thu Sep 30 23:39:42 2004 us=14989 I/O WAIT TRQ|TW1|Sr0|Sw1 [1/91249]
Thu Sep 30 23:39:42 2004 us=31819 WE_WAIT enter n=3 to=1091
Thu Sep 30 23:39:42 2004 us=48819 [0] ev=0x00000003 rwflags=0x0001
arg=0x0040b4f0
Thu Sep 30 23:39:42 2004 us=65563 [1] ev=0x00000740 rwflags=0x0002 arg=0x0040b4ec
Thu Sep 30 23:39:42 2004 us=82600 [2] ev=0x00000744 rwflags=0x0001
arg=0x0040b4ec
Thu Sep 30 23:39:42 2004 us=99369 WE_WAIT leave [1,0] rwflags=0x0002
arg=0x0040b4ec
Thu Sep 30 23:39:42 2004 us=116177  event_wait returned 1
Thu Sep 30 23:39:42 2004 us=133012 I/O WAIT status=0x0008
Thu Sep 30 23:39:42 2004 us=151379 TUN WRITE [84]: 45000054 63a74000 4001c2f9
0a030001 0a030002 0800
ffcc 490b1c2b d2ec5c4[more...] md5=e495bca9 39090b7a d596cbf4 23f08e78
Thu Sep 30 23:39:42 2004 us=185751 WIN32 I/O: TAP Completion non-queued success
[84]
Thu Sep 30 23:39:42 2004 us=201231 WIN32 I/O: TAP Write immediate return [84,84]
Thu Sep 30 23:39:42 2004 us=217945  write to TUN/TAP returned 84
Thu Sep 30 23:39:42 2004 us=235325 WE_CTL n=0 ev=0x0044f574 rwflags=0x0001
arg=0x0040b4f0
Thu Sep 30 23:39:42 2004 us=252328 WIN32 I/O: Socket Receive queued [1576]
Thu Sep 30 23:39:42 2004 us=268720 WE_CTL n=1 ev=0x009d1900 rwflags=0x0001
arg=0x0040b4e8
Thu Sep 30 23:39:42 2004 us=285207 WE_CTL n=2 ev=0x009d72f8 rwflags=0x0001
arg=0x0040b4ec
Thu Sep 30 23:39:42 2004 us=302133 I/O WAIT TRQ|Tw1|SRQ|Sw1 [1/91249]
Thu Sep 30 23:39:42 2004 us=318894 WE_WAIT enter n=3 to=1091
Thu Sep 30 23:39:42 2004 us=335688 [0] ev=0x00000003 rwflags=0x0001
arg=0x0040b4f0
Thu Sep 30 23:39:42 2004 us=353014 [1] ev=0x00000714 rwflags=0x0001
arg=0x0040b4e8
Thu Sep 30 23:39:42 2004 us=369677 [2] ev=0x00000744 rwflags=0x0001
arg=0x0040b4ec
Thu Sep 30 23:39:42 2004 us=781516 WE_WAIT leave rwflags=0x0001 arg=0x0040b4e8
Thu Sep 30 23:39:42 2004 us=789227  event_wait returned 1
Thu Sep 30 23:39:42 2004 us=805595 I/O WAIT status=0x0001

I have tried a lot of things to get this to work. I have read the man
page forward and backward. I really want to see it
working. Openvpn looks fantastic, and I really like the whole design. It
really seems clean. But I am getting exaserbated and am about
ready to pursue IPSEC if I don't get this working soon. I don't know what
else to do at this point. I hate to give up on it.


____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users