I am using openvpn server on my network at home on an Ubuntu machine. I have the following server config: mode server tls-server local 192.168.1.1 port 1194 proto udp #bridging directive dev tap0 ## If you need multiple tap devices, add them here up "/etc/openvpn/up.sh br0" down "/etc/openvpn/down.sh br0" persist-key persist-tun #certificates and encryption ca ca.crt cert server.crt key server.key # This file should be kept secret dh dh1024.pem tls-auth ta.key 0 # This file is secret cipher BF-CBC # Blowfish (default) comp-lzo #log and security user nobody group nogroup keepalive 10 120 status /var/log/openvpn-status.log verb 3 DHCP is being provided by the server 192.168.1.1 with a split pool using the tap mac address. The client config is: ### Client configuration file for OpenVPN # Specify that this is a client client # Bridge device setting dev tap #dev tun # Host name and port for the server (default port is 1194) # note: replace with the correct values your server set up remote 123.123.123.123 1194 # Client does not need to bind to a specific local port nobind # Keep trying to resolve the host name of OpenVPN server. ## The windows GUI seems to dislike the following rule. ##You may need to comment it out. resolv-retry infinite # Preserve state across restarts persist-key persist-tun # SSL/TLS parameters - files created previously ca ca.crt cert client.crt key client.key # Since we specified the tls-auth for server, we need it for the client # note: 0 = server, 1 = client tls-auth ta.key 1 # Specify same cipher as server cipher BF-CBC # Use compression comp-lzo # Log verbosity (to help if there are problems) verb 3 Now I'm virtually certain (but not positive) that my DHCP server is handing out IP addresses to clients on the client LAN (from looking at the /var/log/syslog messages and the hostnames I don't recognise in bind). How can I ensure that the openvpn client is tunneling, rather than bridging whilst still using DHCP ? cheers Simon

Loading...

Something went wrong while trying to load the full version of this site. Try hard-refreshing this page to fix the error.

Question about tun/tap (remote DHCP addresses being handled