What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

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.
 
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?
 
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).
 
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.
 
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.
 

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