Opened 5 years ago

Closed 6 months ago

#55 closed Bug / Defect (fixed)

After enabling "topology subnet" no route settings for server

Reported by: controlc.de 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@…

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 5 years ago.
log files.zip (3.4 KB) - added by controlc.de 5 years ago.

Download all attachments as: .zip

Change History (13)

Changed 5 years ago by controlc.de

Changed 5 years ago by controlc.de

comment:1 Changed 5 years ago by chantra

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 5 years ago by controlc.de

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

comment:3 Changed 5 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 5 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 5 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: 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 2 years ago by samuli

  • Keywords gateway added

comment:7 Changed 17 months 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 17 months ago by cron2

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 13 months 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 6 months 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".

...

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 6 months 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.