|
|
On Fri, 1 Oct 2004, Chris Mills wrote: > 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. The fact that you can ping Linux from XP but not the other way around seems to suggest a firewall issue. The TAP-Win32 adapter on XP sees the ping coming from Linux as "incoming" data on a network interface. By contrast, the pings that originate on XP would be going "out" the TAP-Win32 adapter. The behavior you are seeing is consistent with a firewall which only allows incoming packets which are associated with a locally originated connection. I'm referring to the internal windows firewall which can be selectively enabled or disabled for a given adapter. If this isn't the problem, you could take your debugging a step further and install the debug version of the TAP-Win32 driver to further trace the packet path: http://openvpn.sourceforge.net/beta/tapwin32-debug.zip James > 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. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal > Use IT products in your business? Tell us what you think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Openvpn-users mailing list > Openvpn-users@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/openvpn-users > ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |