DSL-AC68U (gnuton 384.17) - TLS Error: Routing local OpenVPN Server through router based PIA OpenVPN Client

flaschengeist

New Around Here
Hi all,

i am currently facing a few issues trying to route a locally running OpenVPN Server through my VPN Client activated on my DSL-AC68U running gnuton 384.17.
I want to route the OpenVPN Server (and all client connected to it without losing access to local lan) through the VPN Client.

When there is a client already connected and i active the routing (policy based, strict) everythings works just fine: The traffic gets routed through the VPN and local lan access is still possible.
But when i activate the VPN Client and a new client wants to connect (or an already connected client wants to reconnect), there is no connection to the OpenVPN Server possible.

Once i delete the strict policy routing, the clients are able to connect normally again.

Error Log of the OpenVPN Server with activated routing through VPN Client:

Sep 21 17:07:27 openvpn openvpn[627]: 1.1.1.1:50341 TLS: Initial packet from [AF_INET]1.1.1.1:50341, sid=a9612a61 84e9d961
Sep 21 17:08:27 openvpn openvpn[627]: 1.1.1.1:50341 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sep 21 17:08:27 openvpn openvpn[627]: 1.1.1.1:50341 TLS Error: TLS handshake failed
Sep 21 17:08:27 openvpn openvpn[627]: 1.1.1.1:50341 SIGUSR1[soft,tls-error] received, client-instance restarting

1.1.1.1 is a remote ip different from the host network.

OpenVPN Server configuration (192.168.1.x):

local 192.168.1.x
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 192.168.1.1"
client-to-client
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem
explicit-exit-notify


I used the the following script to install the server: https://github.com/Nyr/openvpn-install

OpenVPN Client configuration:

client
dev tun
proto udp
remote x.x.x.x (remote ip) 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
ignore-unknown-option block-outside-dns
block-outside-dns
verb 3
<ca>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----

-----END PRIVATE KEY-----
</key>
<tls-crypt>
-----BEGIN OpenVPN Static key V1-----

-----END OpenVPN Static key V1-----
</tls-crypt>


VPN Client configuration on the router (.ovpn imported from PIA's openvpn.zip):

client
dev tun
proto udp
remote de-frankfurt.privacy.network 1198
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-128-cbc
auth sha1
tls-client
remote-cert-tls server
auth-user-pass
compress
verb 1
reneg-sec 0
<crl-verify>
-----BEGIN X509 CRL-----

-----END X509 CRL-----
</crl-verify>
<ca>
-----BEGIN CERTIFICATE-----

-----END CERTIFICATE-----
</ca>

disable-occ



Any suggestions how to fix the problem?

Thanks in advance.
 

flaschengeist

New Around Here
Still no luck after digging a bit deeper. These are the current (unmodified) VPN Client options on the router:

VPN Client 1 configuration:

# Automatically generated configuration
daemon ovpn-client1
client
dev tun11
txqueuelen 1000
proto udp
remote de-frankfurt.privacy.network 1198
connect-retry-max 15
nobind
persist-key
persist-tun
compress
ncp-ciphers AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
cipher AES-128-CBC
auth SHA1
route-noexec
script-security 2
route-delay 2
route-up vpnrouting.sh
route-pre-down vpnrouting.sh
verb 1
reneg-sec 0
ca ca.crt
auth-user-pass up
crl-verify crl.pem
up updown.sh
down updown.sh
status-version 2
status status 5

# Custom Configuration
resolv-retry infinite
tls-client
remote-cert-tls server


DNS (client1-dns.sh, 192.168.1.x is the OpenVPN Server which is supposed to be strictly routed through VPN Client 1):
/usr/sbin/iptables -t nat -N DNSVPN1
/usr/sbin/iptables -t nat -A DNSVPN1 -s 192.168.1.x -j DNAT --to-destination 10.0.0.243
/usr/sbin/iptables -t nat -I PREROUTING -p udp -m udp --dport 53 -j DNSVPN1
/usr/sbin/iptables -t nat -I PREROUTING -p tcp -m tcp --dport 53 -j DNSVPN1


Firewall (client1-fw.sh):
iptables -I OVPN -i tun11 -j DROP
iptables -t mangle -I PREROUTING -i tun11 -j MARK --set-mark 0x01/0x7
iptables -t nat -I POSTROUTING -s 192.168.1.0/255.255.255.0 -o tun11 -j MASQUERADE
for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
echo 0 > $i
done


tun11 is the interface for the VPN Client 1:
102: tun11: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/none
inet 10.25.112.2/24 brd 10.25.112.255 scope global tun11



So i guess it meight either be a DNS or a NAT problem?
 

eibgrad

Senior Member
Sounds to me like a classic situation when running an OpenVPN server and client on the same machine.

Once the OpenVPN client is active, it changes the default gateway on the router to the VPN (PIA). And therefore anything dependent on the default gateway for routing is affected. That includes the OpenVPN server. Prior to the activation of the OpenVPN client, the incoming packets and replies on the OpenVPN server were being routed over the WAN. But once the OpenVPN client is activated, now the replies from the OpenVPN server get routed out the OpenVPN client. And that's not allowed by the stateful firewall (specifically reverse-path filtering) which requires that all traffic for a given connection must use the *same* network interface for both inbound and outbound (e.g., WAN<->WAN, VPN<->VPN). Once the OpenVPN server switches to the VPN for its replies due to the OpenVPN client, the connection between the remote OpenVPN client and the OpenVPN server is lost; the reply packets are dropped, and you get a TLS error on that connection.

IOW, as configured, everything is doing *exactly* as you told it to do! It's just that the results are not what you were expecting.

The reason things improve when PBR (policy based routing) is enabled is because PBR is typically implemented by NOT letting the OpenVPN client (PIA) change the default gateway to the VPN (specifically using the route-noexec directive, as seen in your config). The primary/main routing table continues to use the WAN/ISP as its default gateway, and the OpenVPN server functions normally. The router establishes a secondary routing table w/ the VPN as its default gateway, and marks packets according to your criteria so those packets are routed through that secondary routing table and over the VPN.

In a nutshell, the behavior exhibited w/ the OpenVPN server is a direct result of how the default gateway gets configured, which itself is dependent on whether there's an concurrent OpenVPN client, and whether it is or isn't using PBR.

Fact is, *any* type of remote access will be affected the same way (the router's GUI, ssh server, etc.), even clients on the LAN that are bound to the OpenVPN client (PIA) and are the target of port forwarding over the WAN (e.g., RDP).
 

flaschengeist

New Around Here
eibgrad, thank you for the clarification. This totally makes sense. I was able to fix the routing problem.

Actually, after thinking of what you said i googled further and found someone on stackexchange who was facing the same problem. For all those to follow.. read this:

So, the solution was quite simple.
Furthermore and since i am using a DSL-AC68U, the VPN speeds are quite slow due to missing hardware acceleration support. Thus, i put the VPN Client on the same machine as the VPN Server. Everything is running smoothly now.
 

eibgrad

Senior Member
You might find the following helpful as well.


IOW, there's more than one way to deal w/ the problem. Just depends on what makes the most sense for your situation.
 
Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top