1
Here is my problem:
I am trying to set up OpenVPN on my home network, to use as a secure tunnel for traffic from insecure networks when away from home, and also to access machines on my home LAN. The OpenVPN server on my LAN is a machine running Arch Linux, and is separate from my firewall, which is currently running M0n0wall. The client I would like to use is a laptop, also running Arch Linux.
I am trying to use bridging mode, which would give my laptop an address on my home LAN, allowing it to act exactly like it was actually connected to my LAN.
Currently, I am trying to test the configuration by putting my laptop behind a gateway, so it is on a separate subnet from my main LAN subnet (I am doing this because I don't have easy access to an outside network, and I'd rather debug problems here than waiting until I'm in a hotel miles away).
Relevant parameters:
Main LAN subnet: 192.168.77.0/24
VPN server IP: 192.168.77.203
Gateway: 192.168.77.2
Testing subnet: 192.168.0.0/24
Laptop (client) IP: 192.168.0.100
Testing gateway (to main LAN): 192.168.0.1
Here is my server's config file:
port 1194
proto udp
dev tap0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/caliborn.crt
key /etc/openvpn/caliborn.key # This file should be kept secret
dh /etc/openvpn/dh2048.pem
server-bridge 192.168.77.203 255.255.255.0 192.168.77.9 192.168.77.19
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth /etc/openvpn/ta.key 0 # This file is secret
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
log /etc/openvpn/openvpn.log
verb 4
And here is the client's config:
client
dev tap0
proto udp
remote 192.168.77.203 1194
resolv-retry infinite
nobind
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
log /etc/openvpn/openvpn.log
ca /etc/openvpn/ca.crt
cert /etc/openvpn/rama.crt
key /etc/openvpn/rama.key
ns-cert-type server
tls-auth ta.key 1
comp-lzo
verb 4
I use the bridge-start script from http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html to setup a bridge on the server prior to starting the VPN.
When the VPN is not connected, I can ping the server (192.168.77.203) from the client (192.168.0.100) just fine, but as soon as I connect the VPN, I lose all connectivity from the client. The VPN appears to be connected to the server, but I cannot even ping the server!
Here is the output of route on the client while the VPN is connected:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.0.1 0.0.0.0 UG 202 0 0 enp0s25
192.168.0.0 * 255.255.255.0 U 202 0 0 enp0s25
192.168.77.0 * 255.255.255.0 U 0 0 0 tap0
And the results of ip route on the client:
default via 192.168.0.1 dev enp0s25 metric 202
192.168.0.0/24 dev enp0s25 proto kernel scope link src 192.168.0.100 metric 202
192.168.77.0/24 dev tap0 proto kernel scope link src 192.168.77.9
Output of ip addr on client, while connected:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:1c:25:93:93:50 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.100/24 brd 192.168.0.255 scope global enp0s25
valid_lft forever preferred_lft forever
inet6 fe80::21c:25ff:fe93:9350/64 scope link
valid_lft forever preferred_lft forever
3: wlp3s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether 00:21:5c:08:7d:37 brd ff:ff:ff:ff:ff:ff
17: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
link/ether 8a:f4:df:21:a6:2d brd ff:ff:ff:ff:ff:ff
inet 192.168.77.9/24 brd 192.168.77.255 scope global tap0
valid_lft forever preferred_lft forever
inet6 fe80::88f4:dfff:fe21:a62d/64 scope link
valid_lft forever preferred_lft forever
And here is the output of ip addr on the server, while the VPN is up:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
link/ether 00:1c:c0:b5:de:b0 brd ff:ff:ff:ff:ff:ff
inet6 fe80::21c:c0ff:feb5:deb0/64 scope link
valid_lft forever preferred_lft forever
3: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 100
link/ether 86:50:bb:c1:46:91 brd ff:ff:ff:ff:ff:ff
inet6 fe80::8450:bbff:fec1:4691/64 scope link
valid_lft forever preferred_lft forever
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:1c:c0:b5:de:b0 brd ff:ff:ff:ff:ff:ff
inet 192.168.77.203/24 brd 192.168.77.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::21c:c0ff:feb5:deb0/64 scope link
valid_lft forever preferred_lft forever
So it looks like packets addressed to the main LAN subnet should go through the tunnel, but when i run tcpdump -i tap0 on the client while trying to ping the server, all I see is ARP requests, with no responses. I would think that I would at least be able to ping the server, which I am connected to.
One more thing that may be relevent: In the client's log, I see the following:
Thu Jul 11 20:54:18 2013 us=872367 OPTIONS IMPORT: --ifconfig/up options modified
Thu Jul 11 20:54:18 2013 us=872423 OPTIONS IMPORT: route-related options modified
Thu Jul 11 20:54:18 2013 us=872480 WARNING: --remote address [192.168.77.203] conflicts with --ifconfig subnet [192.168.77.9, 255.255.255.0] -- local and remote addresses cannot be inside of the --ifconfig subnet. (silence this warning with --ifconfig-nowarn)
Thu Jul 11 20:54:18 2013 us=877646 TUN/TAP device tap0 opened
Thu Jul 11 20:54:18 2013 us=877701 TUN/TAP TX queue length set to 100
Thu Jul 11 20:54:18 2013 us=877726 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu Jul 11 20:54:18 2013 us=877768 /usr/bin/ip link set dev tap0 up mtu 1500
Thu Jul 11 20:54:18 2013 us=878607 /usr/bin/ip addr add dev tap0 192.168.77.9/24 broadcast 192.168.77.255
Thu Jul 11 20:54:18 2013 us=880894 Initialization Sequence Completed
Thu Jul 11 20:56:18 2013 us=649132 [caliborn] Inactivity timeout (--ping-restart), restarting
Thu Jul 11 20:56:18 2013 us=649823 TCP/UDP: Closing socket
Thu Jul 11 20:56:18 2013 us=649917 SIGUSR1[soft,ping-restart] received, process restarting
Thu Jul 11 20:56:18 2013 us=649966 Restart pause, 2 second(s)
Thu Jul 11 20:56:20 2013 us=650168 Re-using SSL/TLS context
Thu Jul 11 20:56:20 2013 us=650308 LZO compression initialized
Thu Jul 11 20:56:20 2013 us=651988 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]
Thu Jul 11 20:56:20 2013 us=652071 Socket Buffers: R=[212992->131072] S=[212992->131072]
Thu Jul 11 20:56:20 2013 us=652124 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Thu Jul 11 20:56:20 2013 us=652192 Local Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532,proto UDPv4, comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'
Thu Jul 11 20:56:20 2013 us=652228 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532, proto UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'
Thu Jul 11 20:56:20 2013 us=652285 Local Options hash (VER=V4): '13a273ba'
Thu Jul 11 20:56:20 2013 us=652335 Expected Remote Options hash (VER=V4): '360696c5'
Thu Jul 11 20:56:20 2013 us=652377 UDPv4 link local: [undef]
Thu Jul 11 20:56:20 2013 us=652420 UDPv4 link remote: [AF_INET]192.168.77.203:1194
Thu Jul 11 20:57:20 2013 us=211669 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Thu Jul 11 20:57:20 2013 us=211761 TLS Error: TLS handshake failed
Thu Jul 11 20:57:20 2013 us=211938 TCP/UDP: Closing socket
Thu Jul 11 20:57:20 2013 us=212012 SIGUSR1[soft,tls-error] received, process restarting
So it seems, in addition to the error about the subnet conflict, the client is timing out and reconnecting around once per minute. It seems that being connected to the VPN stops any traffic flow between the client and any other host on the network, and that after the VPN times out because of this, it can reconnect and start the whole process over.
I'll be happy to provide any additional info to anyone who thinks they may know what the problem is.
1The issue is probably that the server IP OpenVPN is connecting to (192.168.77.203) falls within the VPN client subnet (192.168.77.0/24). Try connect the client to 192.168.0.1 and have the gateway NAT packets to the VPN server. Also provide the output of
ip addr
andip route
on the client when connected. – mgorven – 2013-07-12T01:49:41.517Thanks for the reply, I added the info to the post. There is a message to that effect in the client's log, but I don't understand why that would cause this kind of problem. Is it really just completely impossible to test a VPN connection without going off-site to a different network? – jkcarbon – 2013-07-12T02:13:34.687
Because the client thinks that the route to the VPN server for encapsulated packets is via the VPN, which gets sent via the VPN, repeat ad nauseam. You should be able to test this by having your gateway machine NAT packets to the VPN server so that the endpoint the client is connecting to doesn't fall inside the VPN client subnet. – mgorven – 2013-07-12T16:57:16.883
This isn't a problem with you not being offsite. Your VPN server needs an IP address which isn't in 192.168.77.0/24, and that IP address is the tunnel endpoint. Of course, once you're offsite, your firewall may be providing one (via NAT). – derobert – 2013-07-12T18:46:42.263