OpenVPN Tap Server and Linux dhclient

[DapperDave]

I learn by trial and error, and this problem was a lot of trial and error... I have a Debian router running DnsMasq (v2.76) as the DHCP server and an OpenVPN (v2.4.0) tap server on the LAN bridge for local clients. I created hook-scripts for Windows clients with OpenVPN such that configuration is done by DHCP with the server running in "DHCP mode" ("server-bridge" only), these scripts work fine. I wanted to do the same for Linux clients with OpenVPN (v2.4.0) so I modified my dash scripts. I am able to obtain a lease using dhclient but only with the server running in the "no-gateway mode" ("server-bridge nogw"). I will give you a description of what I mean. With the only difference between the two following scenarios being the server mode, and with the hook-scripts only setting the device up, this is the difference at the root command prompt trying to obtain a lease;

- with server in DHCP mode ("bridge-server"), note that 192.168.1.193 is the gateway, 192.168.1.194 is a br0 alias for dnsmasq, and 192.168.1.209 is the client wifi link

Code: Select all

root@user:/home/user# dhclient tapbr0 -v -lf /var/lib/dhcp/dhclient.tapbr0.leases
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/tapbr0/xx:xx:xx:8a:3a:0e
Sending on   LPF/tapbr0/xx:xx:xx:8a:3a:0e
Sending on   Socket/fallback
DHCPDISCOVER on tapbr0 to 192.168.1.194 port 67 interval 3
DHCPOFFER from 192.168.1.193: no routers option.
DHCPOFFER from 192.168.1.209: no routers option.
DHCPDISCOVER on tapbr0 to 192.168.1.194 port 67 interval 4
DHCPOFFER from 192.168.1.193: no routers option.
DHCPOFFER from 192.168.1.209: no routers option.
DHCPDISCOVER on tapbr0 to 192.168.1.194 port 67 interval 11
DHCPOFFER from 192.168.1.193: no routers option.
DHCPOFFER from 192.168.1.209: no routers option.
...continues

- with server in no-gateway mode ("bridge-server nogw")

Code: Select all

root@user:/home/user# dhclient tapbr0 -v -lf /var/lib/dhcp/dhclient.tapbr0.leases
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.In 
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/tapbr0/xx:xx:xx:8a:3a:0e
Sending on   LPF/tapbr0/xx:xx:xx:8a:3a:0e
Sending on   Socket/fallback
DHCPDISCOVER on tapbr0 to 192.168.1.194 port 67 interval 3
DHCPREQUEST of 192.168.1.217 on tapbr0 to 192.168.1.194 port 67
DHCPOFFER of 192.168.1.217 from 192.168.1.193
DHCPACK of 192.168.1.217 from 192.168.1.193
dhcp-server-identifier: 4 extra bytes
dhcp-server-identifier: 4 extra bytes
bound to 192.168.1.217 -- renewal in 55 seconds.

To me, this is impling that in "DHCP mode" the tunnel is not passing information, verified by trying to "ping -I tapbr0 192.168.1.193/194" which failed for both the gateway and dnsmasq. In the "no-gateway mode" I am able to ping dnsmasq only, the gateway fails. These senarios happen with DnsMasq bound to tapbr0/br0 or listening on 192.168.1.194(,127.0.0.1) only. When the hook-scripts are set to only put the tap up and then obtain a lease with dhclient, it works with the server set to "no-gateway mode" but fails when set to "DHCP mode". With "no-gateway mode" the routes (including default) are set by dhclient. Shouldn't OpenVPN be passing the DHCP requests/replys untouched in both senarios? What exactly is the "no routers option" reply? If needed I can post OpenVPN logs and configs as well as script logs, I wasn't sure if they are needed at this point.

Any insight would be appreciated, Dave

[DapperDave]

Okay, I received no replies. From this I am assuming people think I'm uninformed or a little dim witted!
The thing that perturbs me is that I can create a tap manually and have dhclient get the static lease and set the routing.

Adding tap0 to the server bridge;

Code: Select all

ip tuntap add dev tap0 mode tap
ip link set tap0 master br0
ip link set dev tap0 address ba:bb:bb:bb:bb:ba
ip link set tap0 up
ip link set tap0 promisc on

We have the following bridge at the server

Code: Select all

root@gate:/home/gatekeeper# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.aabbbbbbbbbb no 
lan0
lan1
lan2
tap0
tapbr0
wlan0

Moving to the wifi client we start with the following devices and routes;

Code: Select all

root@client:/etc/openvpn/scripts# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 30:e1:71:81:1e:8e brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d0:57:7b:8a:3a:0e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.209/26 brd 192.168.1.255 scope global wlan0
       valid_lft forever preferred_lft forever
       
root@client:/etc/openvpn/scripts# ip route
192.168.1.192/26 dev wlan0 proto kernel scope link src 192.168.1.209        

Then executing the following ssh command to
- link to tap0 at gateway,
- create tap1 at the client,
- fork the process into the background;

Code: Select all

ssh -f -o Tunnel=ethernet -w 1:0 server@gateway true

followed by these commands to set tap1;

Code: Select all

ip link set dev tap1 address xx:xx:xx:8a:3a:0e
ip link set tap1 up
ip link set tap1 promisc on

We end up with the following additional device;

Code: Select all

25: tap1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether xx:xx:xx:8a:3a:0e brd ff:ff:ff:ff:ff:ff
    inet6 fe80::d057:7bff:fe8a:3a0e/64 scope link 
       valid_lft forever preferred_lft forever

now run dhclient for the tap1 interface

Code: Select all

       
root@client:/home/client# dhclient -v tap1
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/tap1/xx:xx:xx:8a:3a:0e
Sending on   LPF/tap1/xx:xx:xx:8a:3a:0e
Sending on   Socket/fallback
DHCPDISCOVER on tap1 to 255.255.255.255 port 67 interval 6
DHCPREQUEST of 192.168.1.217 on tap1 to 255.255.255.255 port 67
DHCPOFFER of 192.168.1.217 from 192.168.1.193
DHCPACK of 192.168.1.217 from 192.168.1.193
bound to 192.168.1.217 -- renewal in 47 seconds.

After dhclient has assigned tap1 its address and set the routing;

Code: Select all

      
25: tap1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
    link/ether d2:57:7b:8a:3a:0e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.217/26 brd 192.168.1.255 scope global tap1
       valid_lft forever preferred_lft forever 
root@client:/etc/openvpn/scripts# ip route
default via 192.168.1.193 dev tap1 
192.168.1.192/26 dev wlan0 proto kernel scope link src 192.168.1.209 
192.168.1.192/26 dev tap1 proto kernel scope link src 192.168.1.217 

And now I can ping everything on tap1. So with only the gateway ip and a password (vs certificates for OpenVPN), I can open a tap at the client and have dhclient configure the routing. What am I doing wrong in OpenVPN?

Here are my configurations for openvpn

Server

Code: Select all

dev tapbr0
port 1867
proto udp

# Pre-start and post-stop scripts called from daemon service openvpn@.service
#ExecStartPre=/etc/openvpn/scripts/tapxxx-prestart.sh
#ExecStopPost=/etc/openvpn/scripts/tapxxx-poststop.sh

# Use these server certificates to connect
ca       /etc/openvpn/keys/ca.crt
cert     /etc/openvpn/keys/server.crt
key      /etc/openvpn/keys/server.key
dh       /etc/openvpn/keys/dh2048.pem
tls-auth /etc/openvpn/keys/ta.key 0

# Allow client to pull domain names to use in lui of ip address
allow-pull-fqdn

topology subnet
#server-bridge 192.168.252.193 255.255.255.192 192.168.252.200 192.168.252.253
#server-bridge
server-bridge nogw

txqueuelen 300
sndbuf 393216
rcvbuf 393216
push "sndbuf 393216"
push "rcvbuf 393216"

mute-replay-warnings
client-to-client
keepalive 10 120
cipher AES-256-CBC
auth SHA256
persist-key
persist-tun
status /var/log/openvpn-status.log
verb 4
log /var/log/openvpn
verb 4
explicit-exit-notify 1

Client

Code: Select all

client
dev tapbr0
resolv-retry infinite
remote gateway.home.net 1867 udp
lport 1868
lladdr xx:xx:xx:8a:3a:0e
writepid /run/openvpn/tapbr0.pid

# control routing
route-noexec
ifconfig-noexecremote
script-security 2
up        /etc/openvpn/scripts/client-tap.sh
#route-up  /etc/openvpn/scripts/client-tap.sh
#down      /etc/openvpn/scripts/client-tap.sh

user nobody
group nogroup
persist-key
persist-tun

remote-cert-tls server
ca       /etc/openvpn/keys/ca.crt
cert     /etc/openvpn/keys/client.crt
key      /etc/openvpn/keys/client.key
tls-auth /etc/openvpn/keys/ta.key 1

mute-replay-warnings
keepalive 10 120
cipher AES-256-CBC
auth SHA256
tun-mtu 1500
tun-mtu-extra 32
status /var/log/openvpn-status.log
verb 6
log /var/log/openvpn
verb 4
explicit-exit-notify 1

Any insight into why the DHCP server mode isn't working would be appreciated, Dave

[DapperDave]

How does one mark a topic as solved? I can no longer edit the original post. Dave