Cannot make UDP tunnel

[avok]

My problem is with data tunnels. The control connection completes successfully, one of the data UDP tunnels also goes well, but the second fails. This is what my VPN log looks like:

01/26/04 01:49:37 VPN Connection: Negotiated a protocol version 1.4 connection with 'Main'
01/26/04 01:49:37 VPN Connection: A VPN connection has been established to 'Local network of MANAGER'
01/26/04 01:49:37 VPN Tunnels: Tunnel to 'Local network of MANAGER' requested on 212.122.161.167:810
01/26/04 01:49:37 VPN Tunnels: Error ffe0b427 creating tunnel to node Local network of MANAGER (212.122.161.167:810) with ID 5

My setup is as follows

The client VPN node is Windows XP SP1 machine. It has private ip range and connects to Internet through NAT (Sygate Office network) the gateway (Windows XP SP1) has 2 LAN cards, one for the private network, the other for ISP LAN. The Internet connection on gateway is PPPoe through the LAN of the ISP. Let us call it "HOME"

The server is also in private network PC running Windows 2000 Pro SP4
The network is behind NAT (some old version of Solaris) The NAT is the type where the private machines inside are seen with public IPs outside not with the gateway IP. Let us call it "WORK"

Both client and server are set to use TCP 809 for control connection and UDP 810 for data. These ports are forwarded in both firewalls and available (I tested it with UDP and TCP test tools from here http://www.simplecomtools.com/downloads.html) The TCP and UDP packets come and go from and to both networks. So it is very strange that UDP connection from "HOME" to "WORK" fails

I also tried running the VPN client from the gateway PC at HOME. Same result. Another thing I tried is switching the places of VPN server and client: vpn client connects from WORK network and vpn server is on private PC in HOME network. No luck either. UDP tunnel from HOME to WORK fails again.

I searched in the forum and it seems to me that the problem may be related to MTU size. Maybe the maximum size UDP packets are cut in the PPPoe?

Below are report files from both VPN client and server

Server
---------

1.01 WinGate VPN CONFIGURATION REPORT
1.02 Monday, January 26, 2004, 00:26
1.03
1.04 ---------------------------------------------
1.05 WinGate VPN Engine
1.06 ---------------------------------------------
1.07 WinGate VPN 1.2.2 (Build 892)
1.08 Operating System: Windows 2000 (NT 5.0)
1.09 Language: ENU
1.10
4.01 ---------------------------------------------
4.02 Dialer information
4.03 ---------------------------------------------
4.04 Dialer is disabled
4.05
5.01 ---------------------------------------------
5.02 Network Interfaces
5.03 ---------------------------------------------
5.04 172.16.134.52 (LAN) [Internal] [Secure]
5.05 127.0.0.1 (LOOPBACK) [Internal] [Secure]
5.06
6.01 ---------------------------------------------
6.02 Services
6.03 ---------------------------------------------
6.04
6.05 System Policies
6.06 ---------------------------------------------
6.07 Default System Access Rights:
6.08 Everyone - Unrestricted rights
6.09 Default Start/Stop Rights:
6.10 Administrators - Unrestricted rights
6.11 Default Edit Rights:
6.12 Administrators - Unrestricted rights
6.13
6.14 DHCP Service (DHCP Service)
6.15 ---------------------------------------------
6.16 Session Timeout: 60
6.17 Port: 67
6.18 Startup: Disabled
6.19 Binding 1: 172.16.134.52
6.20 Access Rights: Defaults: are ignored
6.21 Everyone - Unrestricted rights
6.22 Start/Stop Rights: Defaults: may be used instead
6.23 Edit Rights: Defaults: may be used instead
6.24
6.25 DNS Service (DNS Service)
6.26 ---------------------------------------------
6.27 Session Timeout: 60
6.28 Port: 53
6.29 Startup: Automatic start/stop
6.30 Binding 1: 172.16.134.52
6.31 Access Rights: Defaults: may be used instead
6.32 Start/Stop Rights: Defaults: may be used instead
6.33 Edit Rights: Defaults: may be used instead
6.34
6.35 Remote Control Service (Remote Control Service)
6.36 ---------------------------------------------
6.37 Session Timeout: 60
6.38 Port: 808
6.39 Startup: Automatic start/stop
6.40 Binding: 127.0.0.1
6.41 Access Rights: Defaults: may be used instead
6.42 Start/Stop Rights: Defaults: may be used instead
6.43 Edit Rights: Defaults: may be used instead
6.44
7.01 ---------------------------------------------
7.02 System Route Table
7.03 ---------------------------------------------
7.04 Current Route Table:
7.05 ---------------------------------------------
7.06 Network Mask Gateway Interface Metric
7.07 0.0.0.0 0.0.0.0 172.16.134.35 172.16.134.52 1
7.08 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
7.09 172.16.132.0 255.255.252.0 172.16.134.52 172.16.134.52 1
7.10 172.16.134.52 255.255.255.255 127.0.0.1 127.0.0.1 1
7.11 172.16.255.255 255.255.255.255 172.16.134.52 172.16.134.52 1
7.12 224.0.0.0 224.0.0.0 172.16.134.52 172.16.134.52 1
7.13 255.255.255.255 255.255.255.255 172.16.134.52 172.16.134.52 1
7.14
8.01 ---------------------------------------------
8.02 Enhanced Network Support
8.03 ---------------------------------------------
8.04 Enhanced Network Support: 5.10 Syz - Installed and active
8.05 Driver: Enabled
8.06 NAT: Disabled
8.07 Router: Disabled
8.08 Firewall level: Disabled
8.100
8.101 Port Security
8.102 ---------------------------------------------
8.103
8.104 Security for: External TCP
8.105 Action: Allow Port: 113 - AUTH
8.106 Action: Allow Port: 809 - Hole for VPN (Control)
8.107 Action: Allow Port: 1024 - 4096 - External
8.108
8.109 Security for: External UDP
8.110 Action: Allow Port: 810 - Hole for VPN (Data)
8.111 Action: Allow Port: 1024 - 4096 - External
8.112
8.113 Security for: Internal TCP
8.114
8.115 Security for: Internal UDP
8.116
8.117 Security for: NAT TCP
8.118
8.119 Security for: NAT UDP
8.500
9.01 ---------------------------------------------
9.02 END OF CONFIGURATION REPORT

Client
--------

1.01 WinGate VPN CONFIGURATION REPORT
1.02 Monday, January 26, 2004, 01:59
1.03
1.04 ---------------------------------------------
1.05 WinGate VPN Engine
1.06 ---------------------------------------------
1.07 WinGate VPN 1.2.2 (Build 892)
1.08 Operating System: Windows 2000 (NT 5.1)
1.09 Language:
1.10
4.01 ---------------------------------------------
4.02 Dialer information
4.03 ---------------------------------------------
4.04 Dialer is disabled
4.05
5.01 ---------------------------------------------
5.02 Network Interfaces
5.03 ---------------------------------------------
5.04 192.168.10.2 (LAN) [Internal] [Secure]
5.05 127.0.0.1 (LOOPBACK) [Internal] [Secure]
5.06
6.01 ---------------------------------------------
6.02 Services
6.03 ---------------------------------------------
6.04
6.05 System Policies
6.06 ---------------------------------------------
6.07 Default System Access Rights:
6.08 Everyone - Unrestricted rights
6.09 Default Start/Stop Rights:
6.10 Administrators - Unrestricted rights
6.11 Default Edit Rights:
6.12 Administrators - Unrestricted rights
6.13
6.14 DHCP Service (DHCP Service)
6.15 ---------------------------------------------
6.16 Session Timeout: 60
6.17 Port: 67
6.18 Startup: Disabled
6.19 Binding 1: 192.168.10.2
6.20 Access Rights: Defaults: are ignored
6.21 Everyone - Unrestricted rights
6.22 Start/Stop Rights: Defaults: may be used instead
6.23 Edit Rights: Defaults: may be used instead
6.24
6.25 DNS Service (DNS Service)
6.26 ---------------------------------------------
6.27 Session Timeout: 60
6.28 Port: 53
6.29 Startup: Automatic start/stop
6.30 Binding 1: 192.168.10.2
6.31 Access Rights: Defaults: may be used instead
6.32 Start/Stop Rights: Defaults: may be used instead
6.33 Edit Rights: Defaults: may be used instead
6.34
6.35 Remote Control Service (Remote Control Service)
6.36 ---------------------------------------------
6.37 Session Timeout: 60
6.38 Port: 808
6.39 Startup: Automatic start/stop
6.40 Binding: 127.0.0.1
6.41 Access Rights: Defaults: may be used instead
6.42 Start/Stop Rights: Defaults: may be used instead
6.43 Edit Rights: Defaults: may be used instead
6.44
7.01 ---------------------------------------------
7.02 System Route Table
7.03 ---------------------------------------------
7.04 Current Route Table:
7.05 ---------------------------------------------
7.06 Network Mask Gateway Interface Metric
7.07 0.0.0.0 0.0.0.0 192.168.10.1 192.168.10.2 30
7.08 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
7.09 192.168.10.0 255.255.255.0 192.168.10.2 192.168.10.2 30
7.10 192.168.10.2 255.255.255.255 127.0.0.1 127.0.0.1 30
7.11 192.168.10.255 255.255.255.255 192.168.10.2 192.168.10.2 30
7.12 224.0.0.0 240.0.0.0 192.168.10.2 192.168.10.2 30
7.13 255.255.255.255 255.255.255.255 192.168.10.2 192.168.10.2 1
7.14
8.01 ---------------------------------------------
8.02 Enhanced Network Support
8.03 ---------------------------------------------
8.04 Enhanced Network Support: 5.10 Syz - Installed and active
8.05 Driver: Enabled
8.06 NAT: Disabled
8.07 Router: Enabled
8.08 Firewall level: Disabled
8.09
8.10 Routing
8.11 ---------------------------------------------
8.12 Multiple default routes: Enabled
8.13 Relay UDP broadcast packets: Enabled
8.100
8.101 Port Security
8.102 ---------------------------------------------
8.103
8.104 Security for: External TCP
8.105 Action: Allow Port: 113 - AUTH
8.106 Action: Allow Port: 809 - Hole for VPN (Control)
8.107 Action: Allow Port: 1024 - 4096 - External
8.108
8.109 Security for: External UDP
8.110 Action: Allow Port: 810 - Hole for VPN (Data)
8.111 Action: Allow Port: 1024 - 4096 - External
8.112
8.113 Security for: Internal TCP
8.114
8.115 Security for: Internal UDP
8.116
8.117 Security for: NAT TCP
8.118
8.119 Security for: NAT UDP
8.500
9.01 ---------------------------------------------
9.02 END OF CONFIGURATION REPORT

[avok]

I have some new information available.
A friend with public IP from another ISP was able to connect successfully to the same VPN server, which I am trying to. With the same settings and all.
This proves to me that the problem is either in my ISP routers or most probably in PPPoe system. I also tried RASPPPoe and WinPoet clients instead of win XP build-in client with no success. Changed MTU sizes to smallest possible. Tried various network test tools; they all show maximum size packets flowing without problem.

Please, tell me what exactly you VPN needs to connect, how to debug it? Maybe some tool to use? You are not telling me anything and I am trying blindly to fix things that are probably all right. And I am getting frustrated already!

[neil]

I think you're right in your estiimation that the problem is to do with your internet connection. Our support for PPPoe is not as full in some areas as we would like. I take it you can access the Home gateway machine (running sygate) fairly easily? If so could you try disabling the PPPoe connection and connect to the internet using a modem and try this set up again then?! I think you'll find this will work. If that is the case then post here and we'll see what we can do in regard to PPPoe support.

(Also, when you connect out through Sygate, can you see the connection in its activity screen / logs?!, and i take it solaris logs the connection in bound correctly as well?)

Regards

Neil

[avok]

Unfortunately I don't have a modem available to test with. But you can assume that it will work, because as I said my friend made it to work with my client to my server on same ports and same user. But he doesn't have PPPoe connection. Sygate logs show outgoing TCP tunnel on port 809 when connecting to the server with VPN client. When the server becomes client and I become server the logs show same TCP tunnel and UDP tunnel on port 810 in addition. It seems normal to me as I think NAT does not make tunnels for outgoing UDP. But anyway the NAT is not causing the problem, because the connection is not happening from gateway PC also.

Will it help if I lower the MTU of PPPoe adapter further from 1400? The Microsoft article I read does not recommends doing so. I don't know why. Is there something else I could do to improve PPPoe support?

[Pascal]

Will it help if I lower the MTU of PPPoe adapter further from 1400? The Microsoft article I read does not recommends doing so. I don't know why. Is there something else I could do to improve PPPoe support?

http://forums.qbik.com/viewtopic.php?t=794&highlight=

Michelle had some problems with a Cisco VPN client and an MTU of 1400. Try lowering it to the value she specified, then see what happens.

[avok]

Nothing happens. Same thing. I lowered my MTU as low as 576. Both in PPPoe adapter on gateway and my client PC. It doesn't seem to have any effect. I don’t think this is an MTU issue anyway. It is most likely some sort of misbehavior. When I connect the SSL control channel is negotiated within a second, one of the tunnels also. The other fails immediately without even trying to send something.
Do you know at all how this product works? Does it send UDP packets with don't fragment bit set? How come the UDP packets come, but cannot go back? Is this UDP packets problem at all? What can I do to analyze what is happening? Some network tool, analyzer maybe. If you don't want to help I cannot make it work alone. I'll just go seek some other solution.

[Pascal]

The error message you reported will happen if the driver cannot find an appropriate route to send the traffic out on. Now this is a bit strange, as you can establish a TCP connection, which means it must have found an appropriate route for that.

Currently, we think it might be a problem with the routes that are being sent from the WinGate VPN Engine to the driver, after it has received the control channel information about the remote node. Would you be able to run a debug kit for us, as this will tell us what routes are being published and will help us to fix this problem for you ?

One suggestion to get it to work is to add a static route on the client to 212.122.161.167 using the same gateway as your default route uses. This route will always be found then, and should allow the UDP traffic to be pumped through.

[avok]

The error message you reported will happen if the driver cannot find an appropriate route to send the traffic out on. Now this is a bit strange, as you can establish a TCP connection, which means it must have found an appropriate route for that.

Currently, we think it might be a problem with the routes that are being sent from the WinGate VPN Engine to the driver, after it has received the control channel information about the remote node. Would you be able to run a debug kit for us, as this will tell us what routes are being published and will help us to fix this problem for you ?

One suggestion to get it to work is to add a static route on the client to 212.122.161.167 using the same gateway as your default route uses. This route will always be found then, and should allow the UDP traffic to be pumped through.

I added the route. My routing table (PC at home behind NAT with VPN client) now looks like this:

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 60 b0 f0 ce 8d ...... AMD PCNET Family PCI Ethernet Adapter
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.10.1 192.168.10.2 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.10.0 255.255.255.0 192.168.10.2 192.168.10.2 20
192.168.10.2 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.10.255 255.255.255.255 192.168.10.2 192.168.10.2 20
212.122.161.167 255.255.255.255 192.168.10.1 192.168.10.2 20
224.0.0.0 240.0.0.0 192.168.10.2 192.168.10.2 20
255.255.255.255 255.255.255.255 192.168.10.2 192.168.10.2 1
Default Gateway: 192.168.10.1
===========================================================================
Persistent Routes:
None

Is this all right? Because is doesn't help. Still same error.

I could run this debug kit for you. I hope it will help find the problem.

[Pascal]

I could run this debug kit for you. I hope it will help find the problem.

Okay, just compiling the debug kit at the moment. Can you send me an email-address, please, so I can email it to you ? (Approximately 2MB, might be less if I leave GateKeeper out)

[avok]

Thank you!
I've just sent you an e-mail. Please, use the address inside.

[avok]

I've sent you an e-mail with logs.

[Pascal]

I've sent you an e-mail with logs.

Thanks, looking through them now. I'll get back to you when there's more questions / ideas.

[avok]

I sent you the logs from the new version. Hope you find then useful. Unfortunately it was not posible to test on the gateway today. So I used the client. But the target is to run wingate VPN from there anyway.

[Pascal]

I sent you the logs from the new version. Hope you find then useful. Unfortunately it was not posible to test on the gateway today. So I used the client. But the target is to run wingate VPN from there anyway.

Yup, thank you. I'll run through them now ...

[Pascal]

Yup, thank you. I'll run through them now ...

Alright. That took a while. We currently have two possible theories - but need a bit more info. (Sorry for the to-and-fro, but this is a very unique problem)

First, what network card is in the VPN client machine ? (Brand + model + type would be good - also driver revision would be great)

Second, is it possible to switch on debug logging in the ENS and send us the log file from there. That would indicate to us if the route table was accepted by the driver.

Thanks in advance,

[adrien]

One other thing.

We note that some NIC drivers are able to set the MAC address on their adapters. Is your network adapter configured to set a specific MAC address? If so, turning this off might help. We found a potential issue where if a protocol sets the MAC address on a NIC (fairly rare - never seen it, but possible), then the driver won't get the MAC address for a NIC. This means then we can't look up the interface handle, and the route table is then messed up, which could cause problems creating tunnels.

In this case NAT would not operate either, but since you are using the VPN client, that has been disabled anyway so you wouldn't be able to test.

We are working on a fix for this and will send through to you soon.

Adrien

[avok]

One other thing.

We note that some NIC drivers are able to set the MAC address on their adapters. Is your network adapter configured to set a specific MAC address? If so, turning this off might help. We found a potential issue where if a protocol sets the MAC address on a NIC (fairly rare - never seen it, but possible), then the driver won't get the MAC address for a NIC. This means then we can't look up the interface handle, and the route table is then messed up, which could cause problems creating tunnels.

In this case NAT would not operate either, but since you are using the VPN client, that has been disabled anyway so you wouldn't be able to test.

We are working on a fix for this and will send through to you soon.

Adrien

Hi,
My network card is "AMD PCNET Family PCI Ethernet adapter"

You can find info, drivers, various release notes, known issues and documentation here [url]http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_6629_2452^2454,00.html[/url]
The currently installed windows driver is signed by Microsoft Windows XP Publisher and is version 4.38.0.0; Supports changing MAC address, but this option is switched off.

I will run your new tests now.

[Pascal]

Thanks, just got the logs.

[avok]

The logs are on their way. Changed the driver and tested with it. Thank you for your determination to making things work. I will help you with whatever I can. I am a developer too and I know a lot about networks and computers. Not so much about windows programming unfortunately :) Could you explain me more in detail? What route wingate fails to discover? The one from the client to the server or the one from the server to the client?

[Pascal]

The logs are on their way. Changed the driver and tested with it. Thank you for your determination to making things work. I will help you with whatever I can. I am a developer too and I know a lot about networks and computers. Not so much about windows programming unfortunately :) Could you explain me more in detail? What route wingate fails to discover? The one from the client to the server or the one from the server to the client?

Any route that will give it access to the server. (Normally the default route!) Can you send me the NAT / ENS log for that client too, please ?

[avok]

One of the things I know is not right with my system is WMI. I've sent you a screen shot of my WMI control. I am searching for things that are common between my PC and the gateway PC (because they both fail to run VPN client) The gateway PC also has similar problems with WMI. The other common thing is the LAN adapter (AMD family...). My PC adapter and one of the LAN adapters on the gateway PC actually. The other (with PPPoe and NAT enabled) is Intel 10/100, I don't know the exact model.

[avok]

The screenshots are on their way.

In the mean time, I cleared out a few other things. Removed my old NIC and used a new one with realtec chip. The problem was still there. Therefore, this is probably not a NIC issue. Next, I tried to run Wingate on my dual boot Windows ME. Surprisingly it worked! The VPN connected all tunnels successfully and I had access to the remote system. BTW, my friend who also succeeded to run this setup had Win 98 SE. Next, I repaired my Win XP system. The WMI is now working and the few other issues I had are now gone. I am still reinstalling a few failed drivers. But the problem with wingate still exists. Must be something about Windows XP in general or my current software environment. Now when WMI is working I can send you a full system info report along with the data from devicetree. I hope you find something.

[larsdennert]

Just curious if you have the XP firewall turned off? Also if you think its a PPOE problem, try and get your hands on a hardware router and have it do the PPOE for the machine. Make sure to open/forward port 809 on the router though.

[avok]

I am positive that ICF is turned off. And from the tests I made (read above) it is very clear now that the problem is OS specific rather than network specific. I don't want to believe that the new version of wingate (5.2.2) does not work at all on Windows XP SP1. But the two installations I have here are affected in the same way, although they have very little in common. I sent very detailed configuration info to qbik and I am still waiting for their opinion.

[adrien]

We have tested WinGate VPN extensively on XP SP1 as well as other OSes from 95 onwards, so it isn't the OS.

From the trace logs we got back, it looked like the driver was not seeing any registration of network adapters. We think this could only happen for a couple of reasons.

1. You have some other protocol installed that hooks the adapters rather than MS TCP
2. Your protocol sets the MAC address on the adapters. I think we discounted this one.

So we are working on the first option. Do you have any other protocols installed on that machine? Any special software? From memory the route table looked like a normal one you would expect to see on a machine with a single NIC on a private network.

[avok]

We have tested WinGate VPN extensively on XP SP1 as well as other OSes from 95 onwards, so it isn't the OS.

From the trace logs we got back, it looked like the driver was not seeing any registration of network adapters. We think this could only happen for a couple of reasons.

1. You have some other protocol installed that hooks the adapters rather than MS TCP
2. Your protocol sets the MAC address on the adapters. I think we discounted this one.

So we are working on the first option. Do you have any other protocols installed on that machine? Any special software? From memory the route table looked like a normal one you would expect to see on a machine with a single NIC on a private network.

Thank you for the idea! I fixed it finally. I looked into system info on page Software environment -> Signed drivers. I saw some entries for "sygate for NT...” I was puzzled at first, because I deinstalled sygate office network long ago. But then I remembered that some particularly ill written software would have this habit of leaving its components behind. And figured that this is something in common with my XP installation on gateway PC. And sygate has NAT drivers, making it very good candidate for the problem you mentioned. I took me a while clearing all entries of sygate from the registry. When I rebooted the VPN worked like charm.

So I think you should have a word with your colleagues from Sygate about that. Thank you for all your help!