Bridge mode Failed to start

Tinker

I apologize in advance for any typos or lack of information. It is 2 am and I have been staring at this stuff for the past 4 hours to no avail. I have been trying to follow this guide: https://www.emaculation.com/doku.php/bridged_openvpn_server_setup

To no avail. I had to modify the openvpn-bridge file to remove all of the ^M characters for new lines to get it to work properly. Now I am stuck with an error message on launch which says

Failed to start OpenVPN connection to server. See 'systemctl status openvpn@server.service' for details

When I run that command, I get this output:

openvpn@server.service - OpenVPN connection to server
   Loaded: loaded (/lib/systemd/system/openvpn@.service; enabled-runtime; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Tue 2020-08-18 07:59:24 BST; 1s ago
     Docs: man:openvpn(8)
           https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
           https://community.openvpn.net/openvpn/wiki/HOWTO
  Process: 994 ExecStartPre=/bin/sh /etc/openvpn/openvpn-bridge start (code=exited, status=0/SUCCESS)
  Process: 995 ExecStart=/usr/sbin/openvpn --daemon ovpn-server --status /run/openvpn/server.status 10 --cd /etc/openvpn --config /etc/openvpn/server.conf --writepid /run/openvpn/server.pid (code=exited, status=1/FAILURE)
  Process: 996 ExecStopPost=/bin/sh /etc/openvpn/openvpn-bridge stop (code=exited, status=0/SUCCESS)
 Main PID: 995 (code=exited, status=1/FAILURE)

I suspect it has something to do with the server.conf files stored in /etc/openvpn/server.conf. That file is as shown in the tutorial and below

port 1194
proto udp
dev tap0
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/openvpnserver.crt
key /etc/openvpn/easy-rsa/pki/private/openvpnserver.key
dh /etc/openvpn/easy-rsa/pki/dh.pem
remote-cert-tls client
server-bridge 192.168.5.100 255.255.255.0 192.168.5.101 192.168.5.110
client-to-client
keepalive 10 120
tls-auth /etc/openvpn/easy-rsa/pki/private/ta.key 0
cipher AES-256-GCM
compress lz4-v2
push "compress lz4-v2"
persist-key
persist-tun
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
verb 3

Any ideas on what could be wrong with this configuration?

Tinker

Didn’t mean to post again. I tried to edit the original and it posted a second time. And now I can’t delete this comment

TinCanTech

See your openvpn --log

Tinker

TinCanTech wrote See your openvpn --log

After looking at this I spent several more hours and got the bridged configuration to launch correctly. However, I was still unable to connect to the vpn or ping out from the pi. This was only the case after the service was enabled. Disabling the service did not allow the pi to reconnect to the internet. This ip a outputs are shown below.

The ip a output before the service was started

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:19:ad:6a brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:4c:f8:3f brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global noprefixroute wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::4221:739a:d57f:652/64 scope link 
       valid_lft forever preferred_lft forever

The ip a output after the service was started. I used my laptop to ping the pi. Using tcpdump I was able to see the ping arrive on wlan0 and see the outgoing arp request on eth0, tap0, and br0 interfaces.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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: eth0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    link/ether b8:27:eb:19:ad:6a brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:4c:f8:3f brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global noprefixroute wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::4221:739a:d57f:652/64 scope link 
       valid_lft forever preferred_lft forever
4: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 100
    link/ether 0a:49:d0:a7:c3:24 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::849:d0ff:fea7:c324/64 scope link 
       valid_lft forever preferred_lft forever
5: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 0a:49:d0:a7:c3:24 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 brd 192.168.1.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::849:d0ff:fea7:c324/64 scope link 
       valid_lft forever preferred_lft forever

The ip a output after shutting the service back down. The same situation with pinging from my laptop persisted. The arp request was seen on the eth0 interface.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    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: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether b8:27:eb:19:ad:6a brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:4c:f8:3f brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global noprefixroute wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::4221:739a:d57f:652/64 scope link 
       valid_lft forever preferred_lft forever

I think I need to bridge the wlan0 interface instead of the eth0 interface because the internet comes in through the wlan0 interface. Simply changing the openvpn-bridge script did nothing to bridge the wlan0 to the br0 and tap0 interfaces that the script created.

I tried to share internet from my desktop through the ethernet port to the pi and then do the bridge on eth0. That came with a series of other connectivity issues so I stopped.

I'm at a bit of a loss of how to proceed. Do I need to create a new post since the issue is now a bit different?

TinCanTech

Post what-ever you please ..

Tinker

My apologies TinCanTech. I just realized I never included the requested information. That said, I abandoned this project on the PI as it was interfering with my ability to use my octopi controlled 3D printer. I was able to get the whole system up and running on a VM as intended in the initial guide. I think my current issue is unsolvable. The reason I was setting up this particular VPN configuration was to play a game called Eon Altar with my friends who recently moved. I think the game relies on layer two broadcasts (though I didn’t think to verify that with something like wire shark) to initiate connection to the host computer. So playing the game via VPN would require a TAP vpn server with IOS clients and IOS doesn’t support layer 2 tunnels. If you do have any suggestions, they would be welcome.

I was able to get PCs to connect to the server and pinging each other. I tried to get phones connected by sharing the PC’s internet connection via hotspot to the phone. Unfortunately, the iPhone’s packets didn’t seem to be passing through the VPN tunnel. Likely because hotspot users are in their own subnet. Additionally, the client PCs seemed to still be routing some traffic through the original internet connection.

TinCanTech

Tinker wrote My apologies TinCanTech. I just realized I never included the requested information

I did not request any information.

Tinker wrote So playing the game via VPN would require a TAP vpn server with IOS clients and IOS doesn’t support layer 2 tunnels. If you do have any suggestions, they would be welcome

OpenVPN are working on something for that very problem but it will not be coming soon.

Tinker wrote Unfortunately, the iPhone’s packets didn’t seem to be passing through the VPN tunnel. Likely because hotspot users are in their own subnet

There are lots of hotspot users who successfully use OpenVPN.