Tap mode remote clients cannot communicate with server side hosts

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
lefty1010
OpenVpn Newbie
Posts: 3
Joined: Sat Jun 04, 2022 8:08 pm

Tap mode remote clients cannot communicate with server side hosts

Post by lefty1010 » Sat Jun 04, 2022 8:36 pm

I have a new install of openvpn in tap mode initially based off of the pivpn installation script and I'm running into communications issues with the remote clients communicating to the server-side lan. The client connects successfully and is assigned an ip address from the defined pool. I see an ARP entry for the bridge interface of the vpn server in the client's ARP table, but no other server side host ARP entries. The vpn server shows the ARP entry for the client's tap interface in its ARP cache as well. However nothing on the server side lan, the vpn server included, can ping the client, and the client cannot ping anything on the server-side lan, the vpn server included. The client is not on a conflicting subnet as the server-side lan. I have tried playing around with various settings in my server.conf file to no avail, but here is my current version:

Code: Select all

dev tap0 
proto udp4
port 1194
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/pivpn_137c2ab6-3452-429b-825c-675ac4494c7b.crt
key /etc/openvpn/easy-rsa/pki/private/pivpn_137c2ab6-3452-429b-825c-675ac4494c7b.key
dh none
ecdh-curve prime256v1
topology subnet
local 192.168.1.99
server-bridge 192.168.1.99 255.255.255.0 192.168.1.190 192.168.1.192
mssfix
# Set your primary domain name server address for clients
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
# Prevent DNS leaks on Windows
# push "block-outside-dns"
# Override the Client default gateway by using 0.0.0.0/1 and
# 128.0.0.0/1 rather than 0.0.0.0/0. This has the benefit of
# overriding but not wiping out the original default gateway.
push "redirect-gateway def1"
client-to-client
# client-config-dir /etc/openvpn/ccd
keepalive 15 120
remote-cert-tls client
tls-version-min 1.2
tls-crypt /etc/openvpn/easy-rsa/pki/ta.key
cipher AES-256-CBC
auth SHA256
user openvpn
group openvpn
persist-key
persist-tun
# push "route 192.168.1.0 255.255.255 192.168.1.99"
push "route 0.0.0.0 128.0.0.0 192.168.1."
push "route 128.0.0.0 128.0.0.0 192.168.1.1"

crl-verify /etc/openvpn/crl.pem
status /var/log/openvpn-status.log 20
status-version 3
syslog
verb 3
#DuplicateCNs allow access control on a less-granular, per user basis.
#Remove # if you will manage access by user instead of device. 
#duplicate-cn
# Generated for use by PiVPN.io
Here is a tail of my openvpn.log file

Code: Select all

Jun  4 20:53:27 pivpn ovpn-server[672]: Consider setting groups/curves preference with tls-groups instead of forcing a specific curve with ecdh-curve.
Jun  4 20:53:27 pivpn ovpn-server[672]: 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.
Jun  4 20:53:27 pivpn ovpn-server[672]: OpenVPN 2.5.1 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2021
Jun  4 20:53:27 pivpn ovpn-server[672]: library versions: OpenSSL 1.1.1n  15 Mar 2022, LZO 2.10
Jun  4 20:53:27 pivpn ovpn-server[672]: NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Jun  4 20:53:27 pivpn ovpn-server[672]: net_route_v4_best_gw query: dst 0.0.0.0
Jun  4 20:53:27 pivpn ovpn-server[672]: net_route_v4_best_gw result: via 192.168.1.1 dev br0
Jun  4 20:53:27 pivpn ovpn-server[672]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Jun  4 20:53:27 pivpn ovpn-server[672]: CRL: loaded 1 CRLs from file /etc/openvpn/crl.pem
Jun  4 20:53:27 pivpn ovpn-server[672]: ECDH curve prime256v1 added
Jun  4 20:53:27 pivpn ovpn-server[672]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun  4 20:53:27 pivpn ovpn-server[672]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun  4 20:53:27 pivpn ovpn-server[672]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun  4 20:53:27 pivpn ovpn-server[672]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun  4 20:53:27 pivpn ovpn-server[672]: TUN/TAP device tap0 opened
Jun  4 20:53:27 pivpn ovpn-server[672]: Socket Buffers: R=[180224->180224] S=[180224->180224]
Jun  4 20:53:27 pivpn ovpn-server[672]: UDPv4 link local (bound): [AF_INET]192.168.1.99:1194
Jun  4 20:53:27 pivpn ovpn-server[672]: UDPv4 link remote: [AF_UNSPEC]
Jun  4 20:53:27 pivpn ovpn-server[672]: GID set to openvpn
Jun  4 20:53:27 pivpn ovpn-server[672]: UID set to openvpn
Jun  4 20:53:27 pivpn ovpn-server[672]: MULTI: multi_init called, r=256 v=256
Jun  4 20:53:27 pivpn ovpn-server[672]: IFCONFIG POOL IPv4: base=192.168.1.190 size=3
Jun  4 20:53:27 pivpn ovpn-server[672]: Initialization Sequence Completed
Jun  4 20:53:27 pivpn ovpn-server[672]: event_wait : Interrupted system call (code=4)
Jun  4 20:53:27 pivpn ovpn-server[672]: Closing TUN/TAP interface
Jun  4 20:53:27 pivpn ovpn-server[672]: SIGTERM[hard,] received, process exiting
Jun  4 20:53:27 pivpn ovpn-server[691]: Consider setting groups/curves preference with tls-groups instead of forcing a specific curve with ecdh-curve.
Jun  4 20:53:27 pivpn ovpn-server[691]: 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.
Jun  4 20:53:27 pivpn ovpn-server[691]: OpenVPN 2.5.1 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2021
Jun  4 20:53:27 pivpn ovpn-server[691]: library versions: OpenSSL 1.1.1n  15 Mar 2022, LZO 2.10
Jun  4 20:53:27 pivpn ovpn-server[691]: NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Jun  4 20:53:27 pivpn ovpn-server[691]: net_route_v4_best_gw query: dst 0.0.0.0
Jun  4 20:53:27 pivpn ovpn-server[691]: net_route_v4_best_gw result: via 192.168.1.1 dev br0
Jun  4 20:53:27 pivpn ovpn-server[691]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Jun  4 20:53:27 pivpn ovpn-server[691]: CRL: loaded 1 CRLs from file /etc/openvpn/crl.pem
Jun  4 20:53:27 pivpn ovpn-server[691]: ECDH curve prime256v1 added
Jun  4 20:53:27 pivpn ovpn-server[691]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun  4 20:53:27 pivpn ovpn-server[691]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun  4 20:53:27 pivpn ovpn-server[691]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun  4 20:53:27 pivpn ovpn-server[691]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun  4 20:53:27 pivpn ovpn-server[691]: TUN/TAP device tap0 opened
Jun  4 20:53:27 pivpn ovpn-server[691]: Socket Buffers: R=[180224->180224] S=[180224->180224]
Jun  4 20:53:27 pivpn ovpn-server[691]: UDPv4 link local (bound): [AF_INET]192.168.1.99:1194
Jun  4 20:53:27 pivpn ovpn-server[691]: UDPv4 link remote: [AF_UNSPEC]
Jun  4 20:53:27 pivpn ovpn-server[691]: GID set to openvpn
Jun  4 20:53:27 pivpn ovpn-server[691]: UID set to openvpn
Jun  4 20:53:27 pivpn ovpn-server[691]: MULTI: multi_init called, r=256 v=256
Jun  4 20:53:27 pivpn ovpn-server[691]: IFCONFIG POOL IPv4: base=192.168.1.190 size=3
Jun  4 20:53:27 pivpn ovpn-server[691]: Initialization Sequence Completed
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 TLS: Initial packet from [AF_INET]redacted:34787, sid=5e809578 f94d25ba
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 VERIFY OK: depth=1, CN=Easy-RSA CA
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 VERIFY KU OK
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 Validating certificate extended key usage
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 VERIFY EKU OK
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 VERIFY OK: depth=0, CN=user
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_VER=2.5.7
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_PLAT=win
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_PROTO=6
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_NCP=2
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-256-CBC
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_LZ4=1
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_LZ4v2=1
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_LZO=1
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_COMP_STUB=1
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_COMP_STUBv2=1
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_TCPNL=1
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_GUI_VER=OpenVPN_GUI_11
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 peer info: IV_SSO=openurl,crtext
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 256 bit EC, curve: prime256v1
Jun  4 20:53:36 pivpn ovpn-server[691]: redacted:34787 [user] Peer Connection Initiated with [AF_INET]redacted:34787
Jun  4 20:53:36 pivpn ovpn-server[691]: user/redacted:34787 MULTI_sva: pool returned IPv4=192.168.1.190, IPv6=(Not enabled)
Jun  4 20:53:36 pivpn ovpn-server[691]: user/redacted:34787 Data Channel: using negotiated cipher 'AES-256-GCM'
Jun  4 20:53:36 pivpn ovpn-server[691]: user/redacted:34787 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jun  4 20:53:36 pivpn ovpn-server[691]: user/redacted:34787 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jun  4 20:53:36 pivpn ovpn-server[691]: user/redacted:34787 SENT CONTROL [user]: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,block-outside-dns,redirect-gateway def1,route 0.0.0.0 128.0.0.0 192.168.1.,route 128.0.0.0 128.0.0.0 192.168.1.1,route-gateway 192.168.1.99,ping 15,ping-restart 120,ifconfig 192.168.1.190 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Jun  4 20:53:37 pivpn ovpn-server[691]: user/redacted:34787 MULTI: Learn: 00:ff:73:0e:a2:bf@0 -> user/redacted:34787
Jun  4 20:57:41 pivpn ovpn-server[621]: Consider setting groups/curves preference with tls-groups instead of forcing a specific curve with ecdh-curve.
Jun  4 20:57:41 pivpn ovpn-server[621]: 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.
Jun  4 20:57:41 pivpn ovpn-server[621]: OpenVPN 2.5.1 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2021
Jun  4 20:57:41 pivpn ovpn-server[621]: library versions: OpenSSL 1.1.1n  15 Mar 2022, LZO 2.10
Jun  4 20:57:41 pivpn ovpn-server[621]: NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Jun  4 20:57:41 pivpn ovpn-server[621]: net_route_v4_best_gw query: dst 0.0.0.0
Jun  4 20:57:41 pivpn ovpn-server[621]: net_route_v4_best_gw result: via 192.168.1.1 dev br0
Jun  4 20:57:41 pivpn ovpn-server[621]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Jun  4 20:57:41 pivpn ovpn-server[621]: CRL: loaded 1 CRLs from file /etc/openvpn/crl.pem
Jun  4 20:57:41 pivpn ovpn-server[621]: ECDH curve prime256v1 added
Jun  4 20:57:41 pivpn ovpn-server[621]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun  4 20:57:41 pivpn ovpn-server[621]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun  4 20:57:41 pivpn ovpn-server[621]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun  4 20:57:41 pivpn ovpn-server[621]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun  4 20:57:41 pivpn ovpn-server[621]: TUN/TAP device tap0 opened
Jun  4 20:57:41 pivpn ovpn-server[621]: Socket Buffers: R=[180224->180224] S=[180224->180224]
Jun  4 20:57:41 pivpn ovpn-server[621]: UDPv4 link local (bound): [AF_INET]192.168.1.99:1194
Jun  4 20:57:41 pivpn ovpn-server[621]: UDPv4 link remote: [AF_UNSPEC]
Jun  4 20:57:41 pivpn ovpn-server[621]: GID set to openvpn
Jun  4 20:57:41 pivpn ovpn-server[621]: UID set to openvpn
Jun  4 20:57:41 pivpn ovpn-server[621]: MULTI: multi_init called, r=256 v=256
Jun  4 20:57:41 pivpn ovpn-server[621]: IFCONFIG POOL IPv4: base=192.168.1.190 size=3
Jun  4 20:57:41 pivpn ovpn-server[621]: Initialization Sequence Completed
Jun  4 20:57:41 pivpn ovpn-server[621]: event_wait : Interrupted system call (code=4)
Jun  4 20:57:41 pivpn ovpn-server[621]: Closing TUN/TAP interface
Jun  4 20:57:41 pivpn ovpn-server[621]: SIGTERM[hard,] received, process exiting
Jun  4 20:57:41 pivpn ovpn-server[662]: Consider setting groups/curves preference with tls-groups instead of forcing a specific curve with ecdh-curve.
Jun  4 20:57:41 pivpn ovpn-server[662]: 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.
Jun  4 20:57:41 pivpn ovpn-server[662]: OpenVPN 2.5.1 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2021
Jun  4 20:57:41 pivpn ovpn-server[662]: library versions: OpenSSL 1.1.1n  15 Mar 2022, LZO 2.10
Jun  4 20:57:41 pivpn ovpn-server[662]: NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Jun  4 20:57:41 pivpn ovpn-server[662]: net_route_v4_best_gw query: dst 0.0.0.0
Jun  4 20:57:41 pivpn ovpn-server[662]: net_route_v4_best_gw result: via 192.168.1.1 dev br0
Jun  4 20:57:41 pivpn ovpn-server[662]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Jun  4 20:57:41 pivpn ovpn-server[662]: CRL: loaded 1 CRLs from file /etc/openvpn/crl.pem
Jun  4 20:57:41 pivpn ovpn-server[662]: ECDH curve prime256v1 added
Jun  4 20:57:41 pivpn ovpn-server[662]: Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun  4 20:57:41 pivpn ovpn-server[662]: Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun  4 20:57:41 pivpn ovpn-server[662]: Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun  4 20:57:41 pivpn ovpn-server[662]: Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun  4 20:57:41 pivpn ovpn-server[662]: TUN/TAP device tap0 opened
Jun  4 20:57:41 pivpn ovpn-server[662]: Socket Buffers: R=[180224->180224] S=[180224->180224]
Jun  4 20:57:41 pivpn ovpn-server[662]: UDPv4 link local (bound): [AF_INET]192.168.1.99:1194
Jun  4 20:57:41 pivpn ovpn-server[662]: UDPv4 link remote: [AF_UNSPEC]
Jun  4 20:57:41 pivpn ovpn-server[662]: GID set to openvpn
Jun  4 20:57:41 pivpn ovpn-server[662]: UID set to openvpn
Jun  4 20:57:41 pivpn ovpn-server[662]: MULTI: multi_init called, r=256 v=256
Jun  4 20:57:41 pivpn ovpn-server[662]: IFCONFIG POOL IPv4: base=192.168.1.190 size=3
Jun  4 20:57:41 pivpn ovpn-server[662]: Initialization Sequence Completed
Jun  4 20:58:15 pivpn ovpn-server[662]: redacted:62325 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun  4 20:58:15 pivpn ovpn-server[662]: redacted:62325 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun  4 20:58:15 pivpn ovpn-server[662]: redacted:62325 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Jun  4 20:58:15 pivpn ovpn-server[662]: redacted:62325 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Jun  4 20:58:15 pivpn ovpn-server[662]: redacted:62325 TLS: Initial packet from [AF_INET]redacted:62325, sid=536cbce4 2b6f7927
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 VERIFY OK: depth=1, CN=Easy-RSA CA
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 VERIFY KU OK
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 Validating certificate extended key usage
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 VERIFY EKU OK
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 VERIFY OK: depth=0, CN=user
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_VER=2.5.7
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_PLAT=win
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_PROTO=6
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_NCP=2
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:AES-256-CBC
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_LZ4=1
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_LZ4v2=1
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_LZO=1
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_COMP_STUB=1
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_COMP_STUBv2=1
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_TCPNL=1
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_GUI_VER=OpenVPN_GUI_11
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 peer info: IV_SSO=openurl,crtext
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 256 bit EC, curve: prime256v1
Jun  4 20:58:16 pivpn ovpn-server[662]: redacted:62325 [user] Peer Connection Initiated with [AF_INET]redacted:62325
Jun  4 20:58:16 pivpn ovpn-server[662]: user/redacted:62325 MULTI_sva: pool returned IPv4=192.168.1.190, IPv6=(Not enabled)
Jun  4 20:58:16 pivpn ovpn-server[662]: user/redacted:62325 Data Channel: using negotiated cipher 'AES-256-GCM'
Jun  4 20:58:16 pivpn ovpn-server[662]: user/redacted:62325 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jun  4 20:58:16 pivpn ovpn-server[662]: user/redacted:62325 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jun  4 20:58:16 pivpn ovpn-server[662]: user/redacted:62325 SENT CONTROL [user]: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,redirect-gateway def1,route 0.0.0.0 128.0.0.0 192.168.1.,route 128.0.0.0 128.0.0.0 192.168.1.1,route-gateway 192.168.1.99,ping 15,ping-restart 120,ifconfig 192.168.1.190 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
Jun  4 20:58:16 pivpn ovpn-server[662]: user/redacted:62325 MULTI: Learn: 00:ff:73:0e:a2:bf@0 -> user/redacted:62325
Here is my openvpn-status log showing the connected user:

Code: Select all

TITLE	OpenVPN 2.5.1 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on May 14 2021
TIME	2022-06-04 21:22:29	1654374149
HEADER	CLIENT_LIST	Common Name	Real Address	Virtual Address	Virtual IPv6 Address	Bytes Received	Bytes Sent	Connected Since	Connected Since (time_t)	Username	Client ID	Peer ID	Data Channel Cipher
CLIENT_LIST	user	redacted:59985	192.168.1.190		845742	12488	2022-06-04 20:58:15	1654372695	UNDEF	0	0	AES-256-GCM
HEADER	ROUTING_TABLE	Virtual Address	Common Name	Real Address	Last Ref	Last Ref (time_t)
ROUTING_TABLE	00:ff:73:0e:a2:bf@0	user	redacted:59985	2022-06-04 21:22:17	1654374137
GLOBAL_STATS	Max bcast/mcast queue length	1
I have ensured ip forwarding is enabled, and I have attempted adding iptables rules permitting traffic through the tap and br0 interfaces, but I'm not entirely sure whether that mattered, as when I list the rules, I don't see the rules I had entered.
My rules were:
sudo iptables -A INPUT -i tap0 -j ACCEPT
sudo iptables -A FORWARD -i br0 -j ACCEPT
sudo iptables -A INPUT -i br0 -j ACCEPT

Code: Select all

sudo iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Here is my network interfaces file defining the bridge:

Code: Select all

cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*
# This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface
 auto lo br0
 iface lo inet loopback

 # Set up interfaces manually, avoiding conflicts with, e.g., network manager
 iface eth0 inet manual

 iface tap0 inet manual

 # Bridge setup
 iface br0 inet static
    bridge_ports eth0 tap0
        address 192.168.1.99
        broadcast 192.168.1.255
        netmask 255.255.255.0
        gateway 192.168.1.1
Any suggestions for getting client communications to the server-side LAN would be greatly appreciated!
Top
lefty1010
OpenVpn Newbie
Posts: 3
Joined: Sat Jun 04, 2022 8:08 pm

Re: Tap mode remote clients cannot communicate with server side hosts

Post by lefty1010 » Sun Jun 05, 2022 1:02 pm

Upon further investigation, I took a packet capture on the vpn server. On the server-lan side I see icmp packets in and out from a host on the lan to the vpn server captured on the br0 bridge interface. I see bi-directional communications as expected, as this communication works fine:

Code: Select all

sudo tcpdump -i br0 proto 1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:46:23.565586 IP 192.168.1.221 > pivpn: ICMP echo request, id 12556, seq 1, length 64
13:46:23.565747 IP pivpn > 192.168.1.221: ICMP echo reply, id 12556, seq 1, length 64
13:46:24.568879 IP 192.168.1.221 > pivpn: ICMP echo request, id 12556, seq 2, length 64
13:46:24.568945 IP pivpn > 192.168.1.221: ICMP echo reply, id 12556, seq 2, length 64
I then tried to ping from the remote client to the vpn server while still capturing on the br0 bridge interface, and I did not see the echos come in.
I then captured on the tap0 interface and I do see the echoes come in, but the VPN server doesn't send anything in reply:

Code: Select all

sudo tcpdump -i tap0 proto 1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:47:12.174481 IP 192.168.1.190 > pivpn: ICMP echo request, id 1, seq 1658, length 40
13:47:17.069193 IP 192.168.1.190 > pivpn: ICMP echo request, id 1, seq 1659, length 40
13:47:21.977271 IP 192.168.1.190 > pivpn: ICMP echo request, id 1, seq 1660, length 40
13:47:26.984709 IP 192.168.1.190 > pivpn: ICMP echo request, id 1, seq 1661, length 40
This has me suspecting that perhaps my tap0 interface is not associated to my br0 bridge properly? Although I'm confused as to why the vpn server wouldn't reply to the echoes out of tap0 when the requests came in as such. My bridge config is listed above, but I'll put it back here for reference:

Code: Select all

cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*
# This file describes the network interfaces available on your system
 # and how to activate them. For more information, see interfaces(5).

 # The loopback network interface
 auto lo br0
 iface lo inet loopback

 # Set up interfaces manually, avoiding conflicts with, e.g., network manager
 iface eth0 inet manual

 iface tap0 inet manual

 # Bridge setup
 iface br0 inet static
    bridge_ports eth0 tap0
        address 192.168.1.99
        broadcast 192.168.1.255
        netmask 255.255.255.0
        gateway 192.168.1.1

Code: Select all

ifconfig br0
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.99  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::ba27:ebff:fe97:6f09  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:97:6f:09  txqueuelen 1000  (Ethernet)
        RX packets 81247  bytes 16883182 (16.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6629  bytes 837614 (817.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Code: Select all

ifconfig tap0
tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::c4cc:33ff:fe8d:2952  prefixlen 64  scopeid 0x20<link>
        ether c6:cc:33:8d:29:52  txqueuelen 1000  (Ethernet)
        RX packets 7035  bytes 943699 (921.5 KiB)
        RX errors 0  dropped 8  overruns 0  frame 0
        TX packets 159  bytes 8708 (8.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
Note that the RX dropped frames are not associated to my icmp attempts as those do not increment as I let the pings run from the client and as such can be ignored. I also do not see the TX packets counter increment which makes sense, as I don't see echo replies in the packet capture.

If I look at the bridge interface via brctl it only lists the eth0 interface. Would anyone know why the tap0 interface is not showing in the list of interfaces when it is defined in my interfaces file? I am suspecting that this is my issue. The packets come in on the tap0 but as it is not bridged with the ethernet interface, there's no path for the traffic to the server-lan.

Code: Select all

sudo brctl show
bridge name	bridge id		STP enabled	interfaces
br0		8000.b827eb976f09	no		eth0
Top
TinCanTech
OpenVPN Protagonist
Posts: 11139
Joined: Fri Jun 03, 2016 1:17 pm

Re: Tap mode remote clients cannot communicate with server side hosts

Post by TinCanTech » Sun Jun 05, 2022 2:03 pm

lefty1010 wrote: ↑
Sun Jun 05, 2022 1:02 pm
 If I look at the bridge interface via brctl it only lists the eth0 interface
That is the reason ..

I guess your setup is not correct.
Top
lefty1010
OpenVpn Newbie
Posts: 3
Joined: Sat Jun 04, 2022 8:08 pm

Re: Tap mode remote clients cannot communicate with server side hosts

Post by lefty1010 » Sun Jun 05, 2022 4:06 pm

I was able to resolve the issue using the bridge setup script. Everything is working as expected now.
Top
Post Reply

Return to “Configuration”