Opened 4 years ago

Last modified 3 months ago

#55 new Bug / Defect

After enabling "topology subnet" no route settings for server

Reported by: controlc.de Owned by:
Priority: major Milestone: release 2.3.3
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 4 years ago.
log files.zip (3.4 KB) - added by controlc.de 4 years ago.

Download all attachments as: .zip

Change History (10)

Changed 4 years ago by controlc.de

Changed 4 years ago by controlc.de

comment:1 Changed 4 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 4 years ago by controlc.de

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

comment:3 Changed 4 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 4 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 3 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 13 months ago by samuli

  • Keywords gateway added

comment:7 Changed 3 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 3 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.

Note: See TracTickets for help on using tickets.