Hi Arne,
Arne Schwabe wrote:
This is really not *necessary*, but the way the code does tun & tap and
net30 & subnet, it gets confused about things. Needs fixing, sorry for
that.
so in some cases a server-side statement
route 192.168.1.0 255.255.255.0
works fine with 'topology net30' but NOT with 'topology subnet'.
This is a long standing bug that needs to be fixed before we can
forcefeed everybody 'topology subnet'.
Okay. I see where the confusion is coming from. if you have net30, the
second parameter for the ifconfig is always the gateway. In subnet you
explicity need to set the gateway by setting/pushing route-gateway.
In normal setups the --server macro automatically does that for you.
I wish this were true. Consider the following server config:
proto udp
port 1194
dev tun
server 192.168.200.0 255.255.255.0
ca /etc/openvpn/cookbook/ca.crt
cert /etc/openvpn/cookbook/server.crt
key /etc/openvpn/cookbook/server.key
dh /etc/openvpn/cookbook/dh1024.pem
tls-auth /etc/openvpn/cookbook/ta.key 0
persist-key
persist-tun
keepalive 10 60
push "route 10.198.0.0 255.255.0.0"
user nobody
group nobody
client-config-dir /etc/openvpn/cookbook/clients
route 192.168.4.0 255.255.255.0
(example from my cookbook)
this example works fine 'as is' but if you add
topology subnet
you get
Fri Jul 11 11:31:28 2014 OpenVPN ROUTE: OpenVPN needs a gateway
parameter for a --route option and no default was specified by either
--route-gateway or --ifconfig options
Fri Jul 11 11:31:28 2014 OpenVPN ROUTE: failed to parse/resolve route
for host/network: 192.168.4.0
Fri Jul 11 11:31:28 2014 TUN/TAP device tun0 opened
so the 'server' macro does not seem to properly publish this in all cases.
JJK
