Opened 4 years ago

Closed 4 years ago

#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 4 years ago.
Session log without fix.
vpn_fix.log (20.0 KB) - added by dferbas 4 years ago.
This log was produced with a fixed openvpn.exe.
ena_local.ovpn (200 bytes) - added by dferbas 4 years ago.
And this is a client config file.

Download all attachments as: .zip

Change History (11)

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

Component: OpenVPN ConnectNetworking

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

comment:2 Changed 4 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 4 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 4 years ago by dferbas

Attachment: vpn_bug.log added

Session log without fix.

Changed 4 years ago by dferbas

Attachment: vpn_fix.log added

This log was produced with a fixed openvpn.exe.

Changed 4 years ago by dferbas

Attachment: ena_local.ovpn added

And this is a client config file.

comment:4 Changed 4 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 4 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 4 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 4 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 4 years ago by Gert Döring

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.