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 subnetClient 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 adaptiveClient 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. . . . . . . . : EnabledClient route table:```
IPv4 Route TableActive 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 276OpenVPN 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=940Server 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