Opened 14 years ago

Closed 9 years ago

#55 closed Bug / Defect (fixed)

After enabling "topology subnet" no route settings for server

Reported by: controlc.de Owned by: Gert Döring
Priority: major Milestone: release 2.3.5
Component: Networking Version: OpenVPN 2.1.0 / 2.1.1 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: gateway
Cc: gert@…

Description

If I enable "topology subnet" in my server.conf OpenVPN don´t set up the clientlan route. If I use the default entry for topology it works.

I´ve attached the server.conf (without "topology subnet") and the log outputs with verb 4.

Attachments (2)

server.conf (550 bytes) - added by controlc.de 14 years ago.
log files.zip (3.4 KB) - added by controlc.de 14 years ago.

Download all attachments as: .zip

Change History (13)

Changed 14 years ago by controlc.de

Attachment: server.conf added

Changed 14 years ago by controlc.de

Attachment: log files.zip added

comment:1 Changed 14 years ago by Emmanuel Bretelle

if you are trying to make 192.168.13.0 to be routed to client1 i believe you need to remove
route 192.168.13.0 255.255.255.0 in server.conf
see attachment:server.conf Line 14

comment:2 Changed 14 years ago by controlc.de

I read FAQ and this seams to be right, isn´t it?

comment:3 Changed 14 years ago by Emmanuel Bretelle

i dont really know. I was just suggesting.

I dont use these kind of settings, so i might be totally wrong here :)

comment:4 Changed 14 years ago by controlc.de

No - it doesn´t work. I´ve removed line 14 in server.conf and set up "topology subnet" - there is now no error line in log file but also no routing to clientlan.

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

Cc: gert@… added

The config looks OK.

This message in the log file hints to where the problem is:

Thu Sep 16 01:09:34 2010 us=22049 OpenVPN ROUTE: OpenVPN needs a gateway paramet
er for a --route option and no default was specified by either --route-gateway o
r --ifconfig options
Thu Sep 16 01:09:34 2010 us=22061 OpenVPN ROUTE: failed to parse/resolve route f
or host/network: 192.168.13.0

... the logic wants to install the route with the "right" next-hop, but doesn't know it yet, so "no gateway".

On a tun device, the next-hop doesn't really matter at all, as long as it's part of the "connected net" (ifconfig+mask), as there is no ARP / next-hop resolution happening anyway. So the code tries to do "too much" and falls on its face.

It should not be too hard to get this fixed, though, but it takes some time to review the code and understand the caveats, especially potential cross-platforms issues.

comment:6 Changed 11 years ago by Samuli Seppänen

Keywords: gateway added

comment:7 Changed 10 years ago by Gert Döring

Milestone: release 2.3.3

For 2.3.3, this should at least be tested to see whether it's still broken -> milestone 2.3.3

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

See also #90 - a workaround is to specify a gateway IP in the "route" statement, as

route 192.168.13.0 255.255.255.0 10.8.0.2

... which is a bit cumbersome, but gets the job done. A real fix to come.

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

Milestone: release 2.3.3release 2.3.5

Won't make 2.3.4. No promises about 2.3.5, but at least trying.

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

Owner: set to Gert Döring
Status: newassigned

Uh. I'm a bit lazy in updating tickets.

2.3.5 has this in its commit list:

commit 3a3da8ddd3f395f9b2bc64f84cb549d99e7c6dbd
Author: Arne Schwabe <arne@…>
Date: Sun Jul 13 14:28:47 2014 +0200

Fix server routes not working in topology subnet with --server [v3]


The IPv4 routing code needs an IPv4 address to point a route to, and
in --topology subnet mode, the *server* did not have one set by default.


So we now just default --route-gateway to the next address right after
the server address - the specific address doesn't matter, as the correct
next-hop will not be resolved by the host OS but by the OpenVPN daemon.
All that is needed is "it's in the subnet routed to the tun interface".

...

URL: http://article.gmane.org/gmane.network.openvpn.devel/8904

so - this *should* be fixed. Could you please re-test with 2.3.5 and let us know?

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

Resolution: fixed
Status: assignedclosed

Well, since I did not hear otherwise, I just claim it's fixed. If not, please reopen.

Note: See TracTickets for help on using tickets.