OpenVPN with transparent bridge, connects but has routing issues

  • I've got OpenVPN running and I can connect, but there seems to be some trouble with routing. I've configured a bridge between WAN, LAN, and the VPN tap interface. When I connect to the VPN from my Windows desktop, I get a DHCP lease and I might be able to reach hosts on the VPN for a minute, but then everything just stops working.

    I'm trying to VPN all traffic to at least, but all of would be preferable. The gateway is, so it should be routable. There are other hosts, like DNS servers provided by DHCP, on other networks (158.65.12.x), but I don't really care about reaching them. As you can see in the route table, there definitely is a route for, but it's still not working properly.

    OpenVPN server config:

    dev ovpns1
    verb 1
    dev-type tap
    dev-node /dev/tap1
    writepid /var/run/
    script-security 3
    keepalive 10 60
    proto udp
    cipher AES-256-CBC
    auth RSA-SHA1
    up /usr/local/sbin/ovpn-linkup
    down /usr/local/sbin/ovpn-linkdown
    client-connect /usr/local/sbin/
    client-disconnect /usr/local/sbin/
    engine cryptodev
    mode server
    auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' false server1" via-env
    tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'KSC+CS+VPN' 1 "
    lport 1194
    management /var/etc/openvpn/server1.sock unix
    push "route"
    ca /var/etc/openvpn/ 
    cert /var/etc/openvpn/server1.cert 
    key /var/etc/openvpn/server1.key 
    dh /etc/dh-parameters.2048
    tls-auth /var/etc/openvpn/server1.tls-auth 0
    comp-lzo adaptive
    topology subnet

    Client config:

    dev tap
    cipher AES-256-CBC
    auth RSA-SHA1
    resolv-retry infinite
    remote 1194 udp
    lport 0
    verify-x509-name "KSC CS VPN" name
    pkcs12 firewall-udp-1194-wmassingham.p12
    tls-auth firewall-udp-1194-wmassingham-tls.key 1
    ns-cert-type server
    comp-lzo adaptive

    Client interface table:

    Ethernet adapter KSC CS VPN:
    Connection-specific DNS Suffix  . :
    Description . . . . . . . . . . . : TAP-Windows Adapter V9
    Physical Address. . . . . . . . . : 00-FF-C7-57-E9-3B
    DHCP Enabled. . . . . . . . . . . : Yes
    Autoconfiguration Enabled . . . . : Yes
    IPv4 Address. . . . . . . . . . . :
    Subnet Mask . . . . . . . . . . . :
    Lease Obtained. . . . . . . . . . : Tuesday, 12 January, 2016 12:13:50
    Lease Expires . . . . . . . . . . : Tuesday, 19 January, 2016 13:46:48
    Default Gateway . . . . . . . . . :
    DNS Servers . . . . . . . . . . . :
    Primary WINS Server . . . . . . . :
    Secondary WINS Server . . . . . . :
    NetBIOS over Tcpip. . . . . . . . : Enabled

    Client route table:```
    IPv4 Route Table

    Active Routes:
    Network Destination        Netmask          Gateway      Interface  Metric
          On-link    306
          On-link    306        On-link    306        On-link    276        On-link    276        On-link    276
        On-link    281        On-link    281        On-link    281        On-link    266        On-link    266        On-link    266
          On-link    306
          On-link    266
          On-link    281
          On-link    276        On-link    306        On-link    266        On-link    281        On-link    276

    OpenVPN server log:```
    Jan 12 15:10:51   openvpn[23757]: OpenVPN 2.3.8 amd64-portbld-freebsd10.1 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Aug 21 2015
    Jan 12 15:10:51   openvpn[23757]: library versions: OpenSSL 1.0.1l-freebsd 15 Jan 2015, LZO 2.09
    Jan 12 15:10:51   openvpn[24053]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1590 init
    Jan 12 15:10:51   openvpn[24053]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
    Jan 12 15:10:51   openvpn[24053]: Initialization Sequence Completed
    Jan 12 15:10:51   openvpn[24053]: Initializing OpenSSL support for engine 'cryptodev'
    Jan 12 15:10:51   openvpn[24053]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
    Jan 12 15:10:51   openvpn[24053]: TUN/TAP device /dev/tap1 opened
    Jan 12 15:10:51   openvpn[24053]: TUN/TAP device ovpns1 exists previously, keep at program end
    Jan 12 15:10:51   openvpn[24053]: UDPv4 link local (bound): [AF_INET]
    Jan 12 15:10:51   openvpn[24053]: UDPv4 link remote: [undef]
    Jan 12 15:11:20   openvpn: user 'wmassingham' authenticated
    Jan 12 15:11:20   openvpn[24053]: [wmassingham] Peer Connection Initiated with [AF_INET]
    Jan 12 15:11:20   openvpn[24053]: wmassingham/ MULTI: no dynamic or static remote --ifconfig address is available for wmassingham/
    Jan 12 15:11:22   openvpn[24053]: wmassingham/ send_push_reply(): safe_cap=940

    Server ifconfig:

    vmx0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
       options=60009b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,rxcsum_ipv6,txcsum_ipv6>ether 00:0c:29:86:a2:31
       inet6 fe80::20c:29ff:fe86:a231%vmx0 prefixlen 64 scopeid 0x1 
       nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect
       status: active
    vmx1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
       options=600099 <rxcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,rxcsum_ipv6,txcsum_ipv6>ether 00:0c:29:86:a2:3b
       inet6 fe80::20c:29ff:fe86:a23b%vmx1 prefixlen 64 scopeid 0x2 
       nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect
       status: active
    pflog0: flags=100 <promisc>metric 0 mtu 33144
    pfsync0: flags=0<> metric 0 mtu 1500
       syncpeer: maxupd: 128 defer: on
       syncok: 1
    lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
       options=600003 <rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6>inet netmask 0xff000000 
       inet6 ::1 prefixlen 128 
       inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 
       nd6 options=21 <performnud,auto_linklocal>enc0: flags=0<> metric 0 mtu 1536
       nd6 options=21 <performnud,auto_linklocal>bridge0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
       ether 02:cb:53:65:ea:00
       inet netmask 0xffff0000 broadcast 
       nd6 options=1 <performnud>id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
       maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
       root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
       member: ovpns1 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 8 priority 128 path cost 2000000
       member: vmx1 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 2 priority 128 path cost 2000
       member: vmx0 flags=143 <learning,discover,autoedge,autoptp>ifmaxaddr 0 port 1 priority 128 path cost 2000
    ovpns1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
       options=80000 <linkstate>ether 00:bd:f1:01:00:01
       inet6 fe80::2bd:f1ff:fe01:1%ovpns1 prefixlen 64 scopeid 0x8 
       nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect
       status: active
       Opened by PID 24053</performnud,auto_linklocal></linkstate></up,broadcast,running,promisc,simplex,multicast></learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></learning,discover,autoedge,autoptp></performnud></up,broadcast,running,simplex,multicast></performnud,auto_linklocal></performnud,auto_linklocal></rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6></up,loopback,running,multicast></promisc></performnud,auto_linklocal></rxcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,rxcsum_ipv6,txcsum_ipv6></up,broadcast,running,promisc,simplex,multicast></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,rxcsum_ipv6,txcsum_ipv6></up,broadcast,running,promisc,simplex,multicast> 

  • I've configured a bridge between WAN, LAN, and the VPN tap interface. When I connect to the VPN from my Windows desktop, I get a DHCP lease and I might be able to reach hosts on the VPN for a minute, but then everything just stops working.

    It might be that NAT is urgent needed in that case for the OpenVPN server.
    It must be routet between the WAN and LAN port and if you was bridging this ports together there is nothing
    that is routing between them as I see it right.

  • A network map would be helpful.  Then my next question is… what are you trying to accomplish with a bridged solution?  Also, unless this is a typo:

    I've configured a bridge between WAN, LAN, and the VPN tap interface.

    This is incorrect.  The bridge should only be between the LAN and the openvpn interface.

  • I'm trying to have the clients appear as if they were connected directly to the network, so that they can interact with upstream servers (DHCP, site DNS, etc.), rather than put behind NAT.

    That's not a typo, that's how I currently have it configured. Initially I tried creating a bridge between the WAN-LAN bridge and the tap interface, but that didn't work. I guess what I'm having a problem with here is which interface gets which IP address. The bridge gets the IP, and I didn't want to assign more than one to this server, so that's why I tried this setup. I guess I'll try creating another bridge between the LAN and tap interfaces and see if that works any better.

    I tried my hand at creating a network diagram that reflects my network:

  • and just plain routing is not an option? why would you want to NAT ?
    sending a zillion useless broadcasts will slow down the openvpn.

    bridging is almost always the worst solution to a problem.

  • I agree with heper.  I haven't heard anything that would require or even suggest a bridged solution.  The only reason to go bridged is if your VPN clients need to communicate with a broadcast-based application on your LAN.  Every other situation is better served, more efficient and more scalable in a routed solution.  DNS, NTP, WINS, DNS suffix, etc can all be pushed to your clients via the config.

    Also, bridging your WAN to your LAN would put your LAN in a DMZ… that's not what you want.

    Switch to routed.  Not only will it perform better, you will save yourself several hours (if not days) of banging your head against the wall!

  • Everything I've read seems to indicate that my choices are bridged or routed+NAT. I don't want to use NAT, and I want clients to be able to use DHCP to get IP addresses from a server on the end of the tunnel. Is that possible with a routed VPN, and if so, is there documentation on how to set it up?

  • Everything I've read seems to indicate that my choices are bridged or routed+NAT

    For a simple remote access setup, you don't need NAT.  There are situations where NAT is a workaround or puts a band-aid on certain issues, but none of them apply to your situation.

    I've searched and could not find a post or any documentation for running openvpn with an external dhcp server unless you setup a bridged solution.  Even if you could, it might mess with tracking on your dashboard.

    Configure a road warrior, routed solution where your clients get their IP from the OpenVPN server.  Problem solved…. and you can monitor your connected clients from the dashboard.

    Pretty straight forward ->

Log in to reply