VPN bridging: Connected but nothing works

Need help configuring your VPN? Just post here and you'll get that help.

Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech

Forum rules
Please use the [oconf] BB tag for openvpn Configurations. See viewtopic.php?f=30&t=21589 for an example.
Post Reply
stitz
OpenVpn Newbie
Posts: 4
Joined: Sat Jan 22, 2022 8:13 pm

VPN bridging: Connected but nothing works

Post by stitz » Sun Jan 23, 2022 10:52 am

Hi

I'm having troubles setting up a bridged VPN connection. I've successfully achieved a routing VPN connection, but bridging is not working and I spent already several hours trying to solve the problem. This is now my last trial, I hope one of you can help me :|

How it is going so far:
  • The VPN server is running on ubuntu server 20.04.3 LTS. The server has a static ip 192.168.0.9, router with dhcp service is at 192.168.0.1
  • The local network is 192.168.0.0/24. I'm aware of that this is not ideal and I will change it once it works. The client is connected to a 192.168.43.0/24 subnet.
  • I can connect to the VPN server from outside the LAN (see log)
  • An ip address is assigned to the client (192.168.200)
  • I can't ping/ssh the VPN server nor any other device behind it
  • Traffic is not routed through the VPN
Below are various settings and logs:

Server Config

port 1194
proto udp
dev tap0
script-security 2
ca ca.crt
cert ***.crt
key ***.key
dh dh.pem
ifconfig-pool-persist /var/log/openvpn/ipp.txt
server-bridge 192.168.0.9 255.255.255.0 192.168.0.200 192.168.0.210
topology subnet
mssfix
push "route 0.0.0.0 0.0.0.0 192.168.0.9"
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
verb 3
explicit-exit-notify 1


I also tried (without luck):
  • Remove push "route 0.0.0.0 0.0.0.0 192.168.0.9"
  • Remove push "route 0.0.0.0 0.0.0.0 192.168.0.9", change to server-bridge nogw
  • Remove push "route 0.0.0.0 0.0.0.0 192.168.0.9", change to server-bridge
ip routes on server

default via 192.168.0.1 dev br0 proto static
192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.9


iptables on server

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- tap0 * 0.0.0.0/0 0.0.0.0/0
90 7752 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 9 packets, 1464 bytes)
pkts bytes target prot opt in out source destination


sysctl.conf on server

net.ipv4.ip_forward=1


ip a on server

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: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
link/ether 50:eb:f6:24:fd:04 brd ff:ff:ff:ff:ff:ff
altname enp0s31f6
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 50:eb:f6:24:fd:04 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.9/24 brd 192.168.0.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::52eb:f6ff:fe24:fd04/64 scope link
valid_lft forever preferred_lft forever
6: tap0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 100
link/ether 0e:83:41:5e:01:ec brd ff:ff:ff:ff:ff:ff


Doesn't matter if a client is connected or not, state of tap0 is always "DOWN". Is this the problem? If I try ip link set dev tap0 up, the state changes to "UNKNOWN".

Client Config

client
dev tap0
proto udp
remote 84.***.***.*** 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
cipher AES-256-CBC
verb 3
key-direction 1
script-security 2

<ca>
***
</ca>
<cert>
***
</cert>
<key>
***
</key>
<tls-auth>
***
</tls-auth>



Client log

2022-01-23 11:14:20 NOTE: --user option is not implemented on Windows
2022-01-23 11:14:20 NOTE: --group option is not implemented on Windows
2022-01-23 11:14:20 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-256-CBC' to --data-ciphers or change --cipher 'AES-256-CBC' to --data-ciphers-fallback 'AES-256-CBC' to silence this warning.
2022-01-23 11:14:20 OpenVPN 2.5.5 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Dec 15 2021
2022-01-23 11:14:20 Windows version 10.0 (Windows 10 or greater) 64bit
2022-01-23 11:14:20 library versions: OpenSSL 1.1.1l 24 Aug 2021, LZO 2.10
2022-01-23 11:14:20 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
2022-01-23 11:14:20 Need hold release from management interface, waiting...
2022-01-23 11:14:21 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
2022-01-23 11:14:21 MANAGEMENT: CMD 'state on'
2022-01-23 11:14:21 MANAGEMENT: CMD 'log all on'
2022-01-23 11:14:21 MANAGEMENT: CMD 'echo all on'
2022-01-23 11:14:21 MANAGEMENT: CMD 'bytecount 5'
2022-01-23 11:14:21 MANAGEMENT: CMD 'hold off'
2022-01-23 11:14:21 MANAGEMENT: CMD 'hold release'
2022-01-23 11:14:21 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2022-01-23 11:14:21 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2022-01-23 11:14:21 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2022-01-23 11:14:21 TCP/UDP: Preserving recently used remote address: [AF_INET]84.***.***.***:1194
2022-01-23 11:14:21 Socket Buffers: R=[65536->65536] S=[65536->65536]
2022-01-23 11:14:21 UDP link local: (not bound)
2022-01-23 11:14:21 UDP link remote: [AF_INET]84.***.***.***:1194
2022-01-23 11:14:21 MANAGEMENT: >STATE:1642932861,WAIT,,,,,,
2022-01-23 11:14:21 MANAGEMENT: >STATE:1642932861,AUTH,,,,,,
2022-01-23 11:14:21 TLS: Initial packet from [AF_INET]84.***.***.***:1194, sid=e56db453 44ba32ce
2022-01-23 11:14:21 VERIFY OK: depth=1, CN=***
2022-01-23 11:14:21 VERIFY OK: depth=0, CN=***
2022-01-23 11:14:21 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2022-01-23 11:14:21 [***] Peer Connection Initiated with [AF_INET]84.***.***.***:1194
2022-01-23 11:14:22 MANAGEMENT: >STATE:1642932862,GET_CONFIG,,,,,,
2022-01-23 11:14:22 SENT CONTROL [***]: 'PUSH_REQUEST' (status=1)
2022-01-23 11:14:22 PUSH: Received control message: 'PUSH_REPLY,route 0.0.0.0 0.0.0.0 192.168.0.9,route-gateway 192.168.0.9,ping 10,ping-restart 120,ifconfig 192.168.0.200 255.255.255.0,peer-id 0,cipher AES-256-GCM'
2022-01-23 11:14:22 OPTIONS IMPORT: timers and/or timeouts modified
2022-01-23 11:14:22 OPTIONS IMPORT: --ifconfig/up options modified
2022-01-23 11:14:22 OPTIONS IMPORT: route options modified
2022-01-23 11:14:22 OPTIONS IMPORT: route-related options modified
2022-01-23 11:14:22 OPTIONS IMPORT: peer-id set
2022-01-23 11:14:22 OPTIONS IMPORT: adjusting link_mtu to 1656
2022-01-23 11:14:22 OPTIONS IMPORT: data channel crypto options modified
2022-01-23 11:14:22 Data Channel: using negotiated cipher 'AES-256-GCM'
2022-01-23 11:14:22 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2022-01-23 11:14:22 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2022-01-23 11:14:22 interactive service msg_channel=884
2022-01-23 11:14:22 open_tun
2022-01-23 11:14:22 tap-windows6 device [tap-bridge] opened
2022-01-23 11:14:22 TAP-Windows Driver Version 9.24
2022-01-23 11:14:22 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.0.200/255.255.255.0 on interface {C47B1A12-D10D-452A-B693-18186B397D13} [DHCP-serv: 192.168.0.0, lease-time: 31536000]
2022-01-23 11:14:22 Successful ARP Flush on interface [25] {C47B1A12-D10D-452A-B693-18186B397D13}
2022-01-23 11:14:22 MANAGEMENT: >STATE:1642932862,ASSIGN_IP,,192.168.0.200,,,,
2022-01-23 11:14:22 IPv4 MTU set to 1500 on interface 25 using service
2022-01-23 11:14:27 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
2022-01-23 11:14:27 MANAGEMENT: >STATE:1642932867,ADD_ROUTES,,,,,,
2022-01-23 11:14:27 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 192.168.0.9
2022-01-23 11:14:27 Route addition via service succeeded
2022-01-23 11:14:27 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2022-01-23 11:14:27 Initialization Sequence Completed
2022-01-23 11:14:27 MANAGEMENT: >STATE:1642932867,CONNECTED,SUCCESS,192.168.0.200,84.***.***.***,1194,,


syslog on server

Jan 23 11:21:01 ***ovpn-***[1958]: 46.140.1.87:63877 peer info: IV_GUI_VER=OpenVPN_GUI_11


Where is my problem located? I'm very thankful for any advice!

Best,
Stitz

TinCanTech
OpenVPN Protagonist
Posts: 11137
Joined: Fri Jun 03, 2016 1:17 pm

Re: VPN bridging: Connected but nothing works

Post by TinCanTech » Sun Jan 23, 2022 1:38 pm

stitz wrote:
Sun Jan 23, 2022 10:52 am
Traffic is not routed through the VPN
stitz wrote:
Sun Jan 23, 2022 10:52 am
push "route 0.0.0.0 0.0.0.0 192.168.0.9"
stitz wrote:
Sun Jan 23, 2022 10:52 am
2022-01-23 11:14:27 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 192.168.0.9
2022-01-23 11:14:27 Route addition via service succeeded
Traffic is routed through the VPN

stitz
OpenVpn Newbie
Posts: 4
Joined: Sat Jan 22, 2022 8:13 pm

Re: VPN bridging: Connected but nothing works

Post by stitz » Sun Jan 23, 2022 6:53 pm

TinCanTech wrote:
Sun Jan 23, 2022 1:38 pm
Traffic is routed through the VPN
Thanks a lot for looking at my problem, but I don't think the traffic is routed through the VPN:
  • If I open for example https://whatismyipaddress.com/on the client while connected to the VPN, it shows the same ip address as if it is disconnected.
  • As I wrote previously, I can't ping or SSH the VPN Server nor anything behind it (other computers, gateway)
  • OpenVPN client log shows some KiB of incoming and outgoing data, not increasing while browsing random pages

stitz
OpenVpn Newbie
Posts: 4
Joined: Sat Jan 22, 2022 8:13 pm

Re: VPN bridging: Connected but nothing works

Post by stitz » Sun Jan 23, 2022 7:06 pm

Maybe it helps to show the result of executing "netstat -rnv" on the connected client?
(Sorry, the client system language is in german and so are the results below)

netstat -rnv

===========================================================================
Schnittstellenliste
6...9c b6 54 bf 0a 2a ......Realtek PCIe GBE Family Controller
7...d8 eb 97 b7 3a a6 ......ASIX AX88179 USB 3.0 to Gigabit Ethernet Adapter
3...........................Wintun Userspace Tunnel
25...00 ff c4 7b 1a 12 ......TAP-Windows Adapter V9
4...3c 77 e6 18 41 c1 ......Microsoft Wi-Fi Direct Virtual Adapter
15...3c 77 e6 18 41 c2 ......Microsoft Wi-Fi Direct Virtual Adapter #2
18...3c 77 e6 18 41 c7 ......Ralink RT3290 802.11bgn Wi-Fi Adapter
24...3c 77 e6 18 41 c8 ......Bluetooth Device (Personal Area Network)
1...........................Software Loopback Interface 1
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.43.1 192.168.43.208 55
0.0.0.0 0.0.0.0 192.168.0.9 192.168.0.200 281
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.200 281
192.168.0.200 255.255.255.255 Auf Verbindung 192.168.0.200 281
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.200 281
192.168.43.0 255.255.255.0 Auf Verbindung 192.168.43.208 311
192.168.43.208 255.255.255.255 Auf Verbindung 192.168.43.208 311
192.168.43.255 255.255.255.255 Auf Verbindung 192.168.43.208 311
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.200 281
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.43.208 311
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.43.208 311
===========================================================================
Ständige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Metrik
0.0.0.0 0.0.0.0 192.168.0.1 Standard
0.0.0.0 0.0.0.0 192.168.1.1 Standard
===========================================================================

IPv6-Routentabelle
===========================================================================
Aktive Routen:
If Metrik Netzwerkziel Gateway
1 331 ::1/128 Auf Verbindung
18 311 fe80::/64 Auf Verbindung
18 311 fe80::48f8:8510:e7fd:8fd/128
Auf Verbindung
1 331 ff00::/8 Auf Verbindung
18 311 ff00::/8 Auf Verbindung
===========================================================================
Ständige Routen:
Keine

TinCanTech
OpenVPN Protagonist
Posts: 11137
Joined: Fri Jun 03, 2016 1:17 pm

Re: VPN bridging: Connected but nothing works

Post by TinCanTech » Sun Jan 23, 2022 8:44 pm

stitz wrote:
Sun Jan 23, 2022 6:53 pm
I don't think the traffic is routed through the VPN
stitz wrote:
Sun Jan 23, 2022 7:06 pm
===========================================================================
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.43.1 192.168.43.208 55
0.0.0.0 0.0.0.0 192.168.0.9 192.168.0.200 281
Two default routes on a TAP network..

The reason it is called a default route is because there can be only one default.
  • do not route 0.0.0.0 via the VPN, instead see --redirect-gateway in the manual.
  • do not use a bridged network, simply use a standard tunnel.
You might also like to take a look at the howto as well.

stitz
OpenVpn Newbie
Posts: 4
Joined: Sat Jan 22, 2022 8:13 pm

Re: VPN bridging: Connected but nothing works

Post by stitz » Sat Jan 29, 2022 9:34 am

Yes, I saw that as well, I had to change the server.conf and also adjust the br0/tap0 config. After many hours/trials more, it finally works in bridged mode.
Thanks a lot for the hints, they helped a lot to not lose motivation to find a working setup!

Post Reply