Opened 6 years ago

Closed 2 years ago

#55 closed Bug / Defect (fixed)

After enabling "topology subnet" no route settings for server

Reported by: Owned by: cron2
Priority: major Milestone: release 2.3.5
Component: Networking Version: 2.1.0 / 2.1.1
Severity: Not set (if unsure, select this one) Keywords: gateway
Cc: gert@…


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 6 years ago.
log (3.4 KB) - added by 6 years ago.

Download all attachments as: .zip

Change History (13)

Changed 6 years ago by

Changed 6 years ago by

comment:1 Changed 6 years ago by chantra

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

comment:2 Changed 6 years ago by

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

comment:3 Changed 6 years ago by chantra

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 6 years ago by

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 6 years ago by cron2

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

... 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 4 years ago by samuli

  • Keywords gateway added

comment:7 Changed 3 years ago by cron2

  • Milestone set to 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 3 years ago by cron2

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


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

comment:9 Changed 3 years ago by cron2

  • Milestone changed from release 2.3.3 to release 2.3.5

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

comment:10 Changed 2 years ago by cron2

  • Owner set to cron2
  • Status changed from new to assigned

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



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

comment:11 Changed 2 years ago by cron2

  • Resolution set to fixed
  • Status changed from assigned to closed

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.