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 158.65.110.0/24, but all of 158.65.0.0/16 would be preferable. The gateway is 158.65.110.2, 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 158.65.110.0/24, but it's still not working properly.

    OpenVPN server config:

    dev ovpns1
    verb 1
    dev-type tap
    dev-node /dev/tap1
    writepid /var/run/openvpn_server1.pid
    script-security 3
    daemon
    keepalive 10 60
    ping-timer-rem
    persist-tun
    persist-key
    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/openvpn.attributes.sh
    client-disconnect /usr/local/sbin/openvpn.attributes.sh
    local 158.65.110.20
    engine cryptodev
    tls-server
    mode server
    username-as-common-name
    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 158.65.0.0 255.255.0.0"
    client-to-client
    ca /var/etc/openvpn/server1.ca 
    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
    persist-tun
    persist-key
    cipher AES-256-CBC
    auth RSA-SHA1
    tls-client
    client
    resolv-retry infinite
    remote 158.65.110.20 1194 udp
    lport 0
    verify-x509-name "KSC CS VPN" name
    auth-user-pass
    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  . : student.keene.edu
    Description . . . . . . . . . . . : TAP-Windows Adapter V9
    Physical Address. . . . . . . . . : 00-FF-C7-57-E9-3B
    DHCP Enabled. . . . . . . . . . . : Yes
    Autoconfiguration Enabled . . . . : Yes
    IPv4 Address. . . . . . . . . . . : 158.65.110.149(Preferred)
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Lease Obtained. . . . . . . . . . : Tuesday, 12 January, 2016 12:13:50
    Lease Expires . . . . . . . . . . : Tuesday, 19 January, 2016 13:46:48
    Default Gateway . . . . . . . . . : 158.65.110.2
    DNS Servers . . . . . . . . . . . : 158.65.12.103
                                        158.65.12.123
    Primary WINS Server . . . . . . . : 158.65.100.14
    Secondary WINS Server . . . . . . : 158.65.100.15
    NetBIOS over Tcpip. . . . . . . . : Enabled
    
    

    Client route table:```
    IPv4 Route Table

    Active Routes:
    Network Destination        Netmask          Gateway      Interface  Metric
              0.0.0.0          0.0.0.0      192.168.1.1    192.168.1.100    25
              0.0.0.0          0.0.0.0    158.65.110.2  158.65.110.149    20
            127.0.0.0        255.0.0.0        On-link        127.0.0.1    306
            127.0.0.1  255.255.255.255        On-link        127.0.0.1    306
      127.255.255.255  255.255.255.255        On-link        127.0.0.1    306
        158.65.110.0    255.255.255.0        On-link    158.65.110.149    276
      158.65.110.149  255.255.255.255        On-link    158.65.110.149    276
      158.65.110.255  255.255.255.255        On-link    158.65.110.149    276
          192.168.1.0    255.255.255.0        On-link    192.168.1.100    281
        192.168.1.100  255.255.255.255        On-link    192.168.1.100    281
        192.168.1.255  255.255.255.255        On-link    192.168.1.100    281
        192.168.56.0    255.255.255.0        On-link      192.168.56.1    266
        192.168.56.1  255.255.255.255        On-link      192.168.56.1    266
      192.168.56.255  255.255.255.255        On-link      192.168.56.1    266
            224.0.0.0        240.0.0.0        On-link        127.0.0.1    306
            224.0.0.0        240.0.0.0        On-link      192.168.56.1    266
            224.0.0.0        240.0.0.0        On-link    192.168.1.100    281
            224.0.0.0        240.0.0.0        On-link    158.65.110.149    276
      255.255.255.255  255.255.255.255        On-link        127.0.0.1    306
      255.255.255.255  255.255.255.255        On-link      192.168.56.1    266
      255.255.255.255  255.255.255.255        On-link    192.168.1.100    281
      255.255.255.255  255.255.255.255        On-link    158.65.110.149    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]158.65.110.20:1194
    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]: 74.69.213.160:65144 [wmassingham] Peer Connection Initiated with [AF_INET]74.69.213.160:65144
    Jan 12 15:11:20   openvpn[24053]: wmassingham/74.69.213.160:65144 MULTI: no dynamic or static remote --ifconfig address is available for wmassingham/74.69.213.160:65144
    Jan 12 15:11:22   openvpn[24053]: wmassingham/74.69.213.160:65144 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: 224.0.0.240 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 127.0.0.1 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 158.65.110.20 netmask 0xffff0000 broadcast 158.65.255.255 
       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: http://i.imgur.com/JO3jdvy.png



  • 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 -> https://doc.pfsense.org/index.php/OpenVPN_Remote_Access_Server