Opened 3 years ago

Closed 2 years ago

#126 closed Bug / Defect (fixed)

Cannot access Syspro 6.0 Server with 2.2RC or 2.2.0

Reported by: coopermh Owned by:
Priority: major Milestone: release 2.2.2
Component: Networking Version: 2.2.0
Severity: Not set (if unsure, select this one) Keywords:
Cc:

Description

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.

Change History (17)

comment:1 Changed 3 years ago by dazo

  • Component changed from Generic / unclassified to Networking

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.

comment:2 Changed 3 years ago by samuli

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

comment:3 follow-up: Changed 3 years ago by 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

comment:4 in reply to: ↑ 3 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by 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

comment:6 Changed 3 years ago by 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

comment:7 Changed 3 years ago by samuli

  • Milestone set to release 2.2.2

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.

comment:8 Changed 3 years ago by dazo

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.

comment:9 Changed 3 years ago by samuli

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

comment:10 Changed 3 years ago by samuli

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."

comment:11 Changed 3 years ago by tno

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

comment:12 Changed 3 years ago by samuli

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).

comment:13 Changed 2 years ago by samuli

These patches attempt to fix this issues.

comment:14 Changed 2 years ago by samuli

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

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).

comment:15 Changed 2 years ago by 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!

comment:16 Changed 2 years ago by samuli

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."

comment:17 Changed 2 years ago by dazo

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.