#609 closed Bug / Defect ( fixed )

Autolocal does not work on Windows

Reported by: dferbas Owned by:
Priority: minor Milestone: release 2.3.9
Component: Networking Version: OpenVPN 2.3.8 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description

The redirect-gateway autolocal option should check, if a target IP resides on a same network as an initiating client does. We tested this works on Ubuntu for Linux code, but it does not work with precompiled clients for Windows, downloadable from here .

It can be simply tested by a presence of "ROUTE remote_host is ..." message in a session log.

We checked source code and found, there is a code implemented for WIN32, but probably for Windows, code flows other way?

route.c:rl->spec.remote_host_local = test_local_addr (remote_host, &rl->rgi);
route.c:add_routes() -> redirect_default_route_to_vpn()

We already posted a message ​ here 1/2 a year ago.

Attachments (3)

vpn_bug.log ​ ( 20.7 KB ) - added by dferbas 9 years ago .
Session log without fix.
vpn_fix.log ​ ( 20.0 KB ) - added by dferbas 9 years ago .
This log was produced with a fixed openvpn.exe.
ena_local.ovpn ​ ( 200 bytes ) - added by dferbas 9 years ago .
And this is a client config file.

.zip

Change History (11)

comment:1 Changed 9 years ago by Gert Döring

Component: OpenVPN Connect → Networking

please show logs for linux and windows, running with --verb 4

comment:2 Changed 9 years ago by dferbas

I think, we've got it.

In the test_local_addr() routine, there is a return variable of bool type:

bool ret = TLA_NONLOCAL;

All 3 return codes, defined in header, cannot fit within the bool variable:

#define TLA_NOT_IMPLEMENTED  0
#define TLA_NONLOCAL         1
#define TLA_LOCAL            2

comment:3 Changed 9 years ago by Gert Döring

Good morning. Thanks for looking into this - and yeah, "bool" is definitely not the right return type here (and due to C rules, "TLA_LOCAL" will then always be mapped to "true" which is "TLA_NONLOCAL" *sigh*). "bool" used to be "int", but got changed to "true bool" a while ago, and some of the fallout is still keeping us busy...

The right fix, of course, is to use "int" here.

I'll prepare a patch - but could I still have a log file that shows the issue?

Changed 9 years ago by dferbas

Attachment: vpn_bug.log ​ added

Session log without fix.

Changed 9 years ago by dferbas

Attachment: vpn_fix.log ​ added

This log was produced with a fixed openvpn.exe.

Changed 9 years ago by dferbas

Attachment: ena_local.ovpn ​ added

And this is a client config file.

comment:4 Changed 9 years ago by dferbas

Of course, I attached log files. If you compare them, just go to their end and you will see.

Is it possible to get Windows installers (binary exe) with a patched openvpn.exe in it?

comment:5 Changed 9 years ago by Gert Döring

Thanks for the logs, it is quite obvious - and of course, the bug fix is also quite obvious, when I look at the code line you've found.

This is the patch I intend to commit (ACK on the openvpn-devel list needed):

--- a/src/openvpn/route.c
+++ b/src/openvpn/route.c
@@ -3600,7 +3600,7 @@ test_local_addr (const in_addr_t addr, const struct route_gateway_info *rgi)
 {
   struct gc_arena gc = gc_new ();
   const in_addr_t nonlocal_netmask = 0x80000000L; /* routes with netmask <= to this are considered non-local */
-  bool ret = TLA_NONLOCAL;
+  int ret = TLA_NONLOCAL;
 
   /* get full routing table */
   const MIB_IPFORWARDTABLE *rt = get_windows_routing_table (&gc);

as soon as that is in, the "daily snapshot builder" will build a windows installer from git master. We don't currently do snapshots from intermediate 2.3 release, but we'll see whether we can do a 2.3.9 release "soonish", with the fix.

comment:6 Changed 9 years ago by dferbas

I think it cannot work for anyone under Windows :-).
The windows installer will save our time, I will appreciate if you can post it somewhere.

When do you plan to release the 2.3.9?

comment:7 in reply to: 6 Changed 9 years ago by Gert Döring

Hi,

Replying to dferbas :

I think it cannot work for anyone under Windows :-).

True, but the scenario "VPN server is in local network" is actually not seen so often - which is why this was not noticed until now, while the change that broke things went in in April 2012 - more than 3 years ago... (commit 4029971240b6274b9b30e76ff74c7f689d7d9750)

The windows installer will save our time, I will appreciate if you can post it somewhere.

Daily snapshots are built and stored here: ​ http://build.openvpn.net/downloads/snapshots/ - the patch went in this morning, so everything Sep 25 or later will have it. Watch out, this is "git master" - it is very well tested, but might behave different in some scenarios (notably, IPv6 support is less wacky).

When do you plan to release the 2.3.9?

No specifics, but maybe in about 4 weeks time or so. Depends on a few other bug reports that should be fixed.

comment:8 Changed 9 years ago by Gert Döring

Resolution: → fixed
Status: new → closed

Just for completeness, the patch has been committed and pushed last week:

commit c40f088e52132273f6d4e83d05fa64bbaedd860f (master)
commit 60287662bbdb1a29d9bd6244917a050410fa6b49 (release/2.3)

Author: Gert Doering
Date: Fri Sep 25 08:36:10 2015 +0200

Repair test_local_addr() on WIN32

2.3.9 will happen "in time".

I'm closing this ticket as there is nothing left to do in here - we won't forget the 2.3.9 release in any case :-)