Opened 13 years ago
Closed 13 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: | OpenVPN 2.2.0 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | 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 13 years ago by
Component: | Generic / unclassified → Networking |
---|
comment:2 Changed 13 years ago by
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: 4 Changed 13 years ago by
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 Changed 13 years ago by
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 13 years ago by
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 13 years ago by
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 13 years ago by
Milestone: | → 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 13 years ago by
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 13 years ago by
Here's an article that describes manual installation/uninstallation of the TAP-drivers: hopefully it helps.
comment:10 Changed 13 years ago by
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 13 years ago by
thanks for reply @samuli,dazo, have no time this week, but i'll make the tests next week
comment:12 Changed 13 years ago by
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:14 Changed 13 years ago by
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).
comment:15 Changed 13 years ago by
@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 13 years ago by
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 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.