OpenVPN Bridging Woes (Can't Ping Server From Client)

Question

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.