Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0

[coopermh]

Use OpenVPN primarily to access the data server at work as well as to access the Syspro SQL server at work.
We use Syspro 6.0 SP1 for our manufacturing, stock control and accounts software.
Will not access the SQL server with 2.2.0
Would not access the SQL server with 2.2 RC2
Works perfectly with 2.2 RC and all prior versions.

[David Sommerseth]

Can you please elaborate more of your configuration files on both client and server? Which OS are the client and servers running? And also log files with --verb 4 on both client and servers would be helpful here.

[Samuli Seppänen]

If this is reproducible at all, it may have been triggered by this commit. Will close this ticket soon unless we get more information.

[eliyak]

With 2.2.1 on a Windows 7 Pro system, I am unable to access a remote Microsoft SQL server (on an XP box). This includes using the odbc interface. The XP OpenVPN server is also running 2.2.1. The problem disappears when I go back to 2.1.4 on the client. File sharing is not affected by this issue.

Config is standard:

client
dev tun
proto udp
remote <server> <port>
resolv-retry infinite
nobind
persist-key
persist-tun
ca "C:
Program Files
OpenVPN
config
ca.crt"
cert "C:
Program Files
OpenVPN
config
<client>.crt"
key "C:
Program Files
OpenVPN
config
<client>.key"
ns-cert-type server
comp-lzo
verb 3

[eliyak]

Replying to eliyak:

With 2.2.1 on a Windows 7 Pro system, I am unable to access a remote Microsoft SQL server (on an XP box). This includes using the odbc interface. The XP OpenVPN server is also running 2.2.1. The problem disappears when I go back to 2.1.4 on the client. File sharing is not affected by this issue.

Config is standard:

client
dev tun
proto udp
remote <server> <port>
resolv-retry infinite
nobind
persist-key
persist-tun
ca "C:
Program Files
OpenVPN
config
ca.crt"
cert "C:
Program Files
OpenVPN
config
<client>.crt"
key "C:
Program Files
OpenVPN
config
<client>.key"
ns-cert-type server
comp-lzo
verb 3

Also, my XP SP3 Home laptop experiences the same issue with a similar config file.

[tno]

using openvpn 2.2.1 i encountered the same problem with microsoft sql server management studio connecting to a microsoft sql server but i debugged the problem with wireshark and ostinato

it is no openvpn configuration problem, the sql client software generates udp packets with a frame length of 51 bit and these packets do not get forwarded through the tunnel (tcpdump on the other end didn't receive anything)

but when i take the same packet, only modifing the frame length to 64 and injecting it, then the packet gets forwarded through the tunnel

using openvpn 2.1.4 circumvents this issue and sends the (uncommon) udp packets through the tunnel and the whole sql communication is working

[tno]

of course i meant 51 bytes instead of bit, but maybe i'll do some deeper research why these packets are under 64 bytes, maybe it is an ethernet frame padding problem/bug

however, with openvpn 2.1.4 these packets are going through the tunnel and with openvpn 2.2.1 not

[Samuli Seppänen]

Could you do a Git bisect to pinpoint which commit causes this regression. There are instructions ​here. This would make fixing this problem much easier.

[David Sommerseth]

Another valuable test would be to see if this is related to the TAP driver in Windows.

• Extract the OpenVPN 2.2.1 bin directory and make a copy of it (where you have openvpn.exe and some dll files).
• Remove all TAP devices
• Install OpenVPN 2.1.4 and create a new TAP device
• Run the your test with both the the openvpn-2.1.4 and openvpn-2.2.1 executables
• Report if this works or not.

Then do the opposite

• Extract the 2.1.4 bin directory (as above)
• Remove all TAP devices
• Install OpenVPN 2.2.1 and create a new TAP device
• Run your tests with both openvpn-2.1.4 and openvpn-2.2.1 executables
• Report if this works or not.

This will help us distinguish if the problem lays in the openvpn executable or in the TAP driver.

[Samuli Seppänen]

Here's an article that describes manual installation/uninstallation of the TAP-drivers: hopefully it helps.

[Samuli Seppänen]

It might be possible to reproduce this issue using ICMP. From chatlog of IRC meeting on 11th Aug 2011:

• dazo: "ICMP might work ... ICMP with size < 51bytes should in theory then not be passed through."
• jamesyonan: "I wonder if pinging with an explicit ICMP packet length could help to reproduce this."

[tno]

thanks for reply @samuli,dazo, have no time this week, but i'll make the tests next week

[Samuli Seppänen]

Tno: Excellent, looking forward to your results! If you need _any_ help, please visit the developer IRC channel and ask for dazo or mattock (=me).

[Samuli Seppänen]

​These patches attempt to fix this issues.

[Samuli Seppänen]

Here are two Windows installers where this issue should be fixed:

• ​http://build.openvpn.net/downloads/snapshots/openvpn-2.2.2-preview-1-install.exe
• ​http://build.openvpn.net/downloads/snapshots/openvpn-2.x-master-20111202-wo-startup-test-install.exe

The first is essentially 2.2.1 with fixes for this and a few other bugs, while the latter is based on a development version of OpenVPN and has tons of new functionality (for a list, look ​here).

[tno]

@samuli: great work, thank you!

just tested the 2.2.2 preview-version and it works!

doublechecked with packetgenerator and sniffer, windows-reboot
after every installation and de-installation -> summary:

2.1.4 lets these special packets through the tunnel
2.2.1 does not pass them through the tunnel
2.2.2-preview does it like 2.1.4!

[Samuli Seppänen]

Test report from the original reported:

"I downloaded and installed 2.2.2 preview and tested it on all the instances
where I use OpenVPN, especially Syspro 6.0 SP2, and it works perfectly."