Problem: when setting up openvpn to act as server and bridge the device, no communication is transmitted over the vpn channel. looking at /var/log/messages I see this: [ 3516.124757] device tap0 entered promiscuous mode but these lines are missing: br0: port 2(tap0) entering listening state [171340.112008] tap0: no IPv6 routers present [171344.521010] br0: port 2(tap0) entering learning state [171359.521007] br0: topology change detected, propagating [171359.521015] br0: port 2(tap0) entering forwarding state /etc/init.d/openvpn line 96 : # Warn about the inability to change ip/route/dns information when # dropping privs if grep -q "^[ \t]*user[ \t].*" "${VPNCONF}" ; then ewarn "WARNING: You are dropping root privileges!" ewarn "As such openvpn may not be able to change ip, routing" ewarn "or DNS configuration." fi else # So we're a server. Run as openvpn unless otherwise specified grep -q "^[ \t]*user[ \t].*" "${VPNCONF}" || args="${args} --user openvpn" grep -q "^[ \t]*group[ \t].*" "${VPNCONF}" || args="${args} --group openvpn" so unless the user option appears in openvpn config it will start with an unprivileged user, and the tap device never goes on to being active. I suggest to change the warning, or use "user=root" by default when used as bridge.
So any suggestion on what the new warning should be?
(In reply to comment #1) > So any suggestion on what the new warning should be? > --- /etc/init.d/openvpn.orig 2010-11-15 00:34:44.000000000 +0200 +++ /etc/init.d/openvpn 2010-11-15 00:34:20.000000000 +0200 @@ -105,6 +105,11 @@ # So we're a server. Run as openvpn unless otherwise specified grep -q "^[ ]*user[ ].*" "${VPNCONF}" || args="${args} --user openvpn" grep -q "^[ ]*group[ ].*" "${VPNCONF}" || args="${args} --group openvpn" + einfo "niv changed these args: ${args}" + #args="${args} --up-delay --up-restart" + args="${args} --script-security 2" + args="${args} --up /etc/openvpn/up.sh" + args="${args} --down-pre --down /etc/openvpn/down.sh" fi # Ensure that our scripts get the PEER_DNS variable then create /etc/openvpn/openvpn.SRV-up.sh : #!/bin/bash sleep 2 ifconfig tap0 0.0.0.0 brctl addif br0 tap0
but this seem better: --- /tmp/up.sh.orig 2010-11-15 01:27:20.000000000 +0200 +++ /tmp/up.sh 2010-11-15 01:26:55.000000000 +0200 @@ -60,6 +60,10 @@ fi fi +# in case openvpn is in bridge mode bridge it to the appropriate bridge +if ! grep -q "^[ ]*dev[ ].*tap0" "${VPNCONF}" + /sbin/brctl addif ${BRIDGE} ${DEVICE} +fi # Below section is Gentoo specific # Quick summary - our init scripts are re-entrant and set the SVCNAME env var # as we could have >1 openvpn service and then add these lines in /etc/conf.d/openvpn.SRV : BRIDGE="br0" DEVICE="tap0"
Created attachment 255269 [details, diff] openvpn init.d and up.sh patch to allow auto adding to bridge
Created attachment 255273 [details, diff] openvpn init.d and up.sh patch to allow auto adding to bridge still two issues to mend in this patch, to make it perfect
Created attachment 255275 [details, diff] openvpn init.d and up.sh patch to allow auto adding to bridge
> so unless the user option appears in openvpn config it will start with an > unprivileged user, and the tap device never goes on to being active. We're using OpenVPN with tap0/tap1 in a bridge - we just create the bridge before OpenVPN gets started. Maybe this could be a better approach? /etc/conf.d/net #VPN bridge_vpn0="tap0 tap1" config_vpn0=( "192.168.1.253 broadcast 192.168.1.255 netmask 255.255.255.0" "ABCD:EFAB:CDEF:ABCD:1/64" "fe80::253/64") preup() { if [[ "${IFACE}" == "vpn0" ]]; then /usr/sbin/openvpn --dev tap0 --mktun /usr/sbin/openvpn --dev tap1 --mktun fi } postup() { if [[ "${IFACE}" == "vpn0" ]]; then echo 1 >/proc/sys/net/ipv4/conf/vpn0/forwarding echo 1 >/proc/sys/net/ipv6/conf/vpn0/forwarding fi } predown() { if [[ "${IFACE}" == "vpn0" ]]; then echo 0 >/proc/sys/net/ipv4/conf/vpn0/forwarding echo 0 >/proc/sys/net/ipv6/conf/vpn0/forwarding fi } postdown() { if [[ "${IFACE}" == "vpn0" ]]; then /usr/sbin/openvpn --dev tap0 --rmtun /usr/sbin/openvpn --dev tap1 --rmtun fi }
openvpn shouldn't touching the interfaces managed by the normal gentoo network scripts. Specifically, it should NOT be adding interfaces to the bridge itself. Does this sound like a reasonable order: 1. net creates bridge 2. openvpn starts and creates tapX devices. 3. net adds tapX devices to bridge If it's more intricate than that, we should probably integrate more of openvpn into the network scripts.
(In reply to comment #8) > openvpn shouldn't touching the interfaces managed by the normal gentoo network > scripts. Specifically, it should NOT be adding interfaces to the bridge > itself. Full ACK. > Does this sound like a reasonable order: > 1. net creates bridge > 2. openvpn starts and creates tapX devices. > 3. net adds tapX devices to bridge IMHO net supports everything needed... You can also create tun/tap-devices in a more sofisticated way as using preup/postdown. See /etc/conf.d/net.example... #----------------------------------------------------------------------------- # TUN/TAP # For TUN/TAP support emerge net-misc/openvpn or sys-apps/usermode-utilities # # You must specify if we're a tun or tap device. Then you can give it any # name you like - such as vpn #tuntap_vpn="tun" #config_vpn=( "192.168.0.1/24") # Or stick wit the generic names - like tap0 #tuntap_tap0="tap" Everything to create a bridged tap-interface is available. Why do you want do add the tapX to the bridge after openvpn was started? IMHO the right order should be: 1. net creates tapX 2. net creates bridge 3. net adds tapX devices to bridge 4. openvpn starts and creates tapX devices. > If it's more intricate than that, we should probably integrate more of openvpn > into the network scripts. Maybe, but i believe this is not necessary.
Created attachment 259305 [details] patching openvpn files to add and remove tap device to bridge /etc/conf.d/openvpn file should have this: BRIDGE="br0" in case bridge is br0
Created attachment 259416 [details, diff] patchs to add openvpn device to bridge
From the latest patches, those are for openvpn only, no openrc changes needed. dropping openrc from this bug.
This bug has gotten really old, can you please retry with openvpn-2.3.12 and see if the issue still exists?
