OpenVPN server not letting me to connect

AlejandroME · October 22, 2019, 3:35pm

Hello everyone,

I am trying to configure a VPN server for accessing my internal network from Internet. I have the following setup:

Device: Ubiquiti EdgeRouter X
OpenVPN version: 2.4.5
OpenWRT Version: 18.06.4
Overall network config: one OpenVPN client instance using a paid VPN provider (tun0), another instance as a server (tun1).

I've generated the PKI infrastructure following the official guide and I configured the server roughly following this guide.

Now, I've distributed the OVPN file to my devices (an iPhone and an Android phone) and when I try to connect I get a timeout.
Looking at the OpenVPN server logs I find this:

Tue Oct 22 08:37:06 2019 us=924379 MULTI: multi_create_instance called
Tue Oct 22 08:37:06 2019 us=925215 XXX.XXX.XXX.XXX:44942 Re-using SSL/TLS context
Tue Oct 22 08:37:06 2019 us=926188 XXX.XXX.XXX.XXX:44942 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Tue Oct 22 08:37:06 2019 us=926685 XXX.XXX.XXX.XXX:44942 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
Tue Oct 22 08:37:06 2019 us=927218 XXX.XXX.XXX.XXX:44942 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Tue Oct 22 08:37:06 2019 us=927433 XXX.XXX.XXX.XXX:44942 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Tue Oct 22 08:37:06 2019 us=927784 XXX.XXX.XXX.XXX:44942 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:44942, sid=1817a028 a5c0a1b1
Tue Oct 22 08:37:16 2019 us=813821 MULTI: multi_create_instance called
Tue Oct 22 08:37:16 2019 us=814546 XXX.XXX.XXX.XXX:44945 Re-using SSL/TLS context
Tue Oct 22 08:37:16 2019 us=815517 XXX.XXX.XXX.XXX:44945 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Tue Oct 22 08:37:16 2019 us=815794 XXX.XXX.XXX.XXX:44945 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
Tue Oct 22 08:37:16 2019 us=816165 XXX.XXX.XXX.XXX:44945 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Tue Oct 22 08:37:16 2019 us=816346 XXX.XXX.XXX.XXX:44945 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Tue Oct 22 08:37:16 2019 us=816663 XXX.XXX.XXX.XXX:44945 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:44945, sid=32716985 92e31a61
Tue Oct 22 08:37:27 2019 us=613809 MULTI: multi_create_instance called
Tue Oct 22 08:37:27 2019 us=614494 XXX.XXX.XXX.XXX:44944 Re-using SSL/TLS context
Tue Oct 22 08:37:27 2019 us=615470 XXX.XXX.XXX.XXX:44944 Control Channel MTU parms [ L:1621 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Tue Oct 22 08:37:27 2019 us=615754 XXX.XXX.XXX.XXX:44944 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
Tue Oct 22 08:37:27 2019 us=616126 XXX.XXX.XXX.XXX:44944 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Tue Oct 22 08:37:27 2019 us=616306 XXX.XXX.XXX.XXX:44944 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1541,tun-mtu 1500,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Tue Oct 22 08:37:27 2019 us=616656 XXX.XXX.XXX.XXX:44944 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:44944, sid=50b5823f 9060029f
Tue Oct 22 08:38:06 2019 us=155030 XXX.XXX.XXX.XXX:44942 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Oct 22 08:38:06 2019 us=155432 XXX.XXX.XXX.XXX:44942 TLS Error: TLS handshake failed
Tue Oct 22 08:38:06 2019 us=156050 XXX.XXX.XXX.XXX:44942 SIGUSR1[soft,tls-error] received, client-instance restarting

Now, I know that the TLS error seems to be related with something on the firewall, but it has been impossible to me to find which is the rule/zone config that is messing up with the communication between the client and the server.

This is the content of my /etc/config/firewall:

config rule
	option name 'Allow-VPNS-Inbound'
	option target 'ACCEPT'
	option proto 'udp'
	option src 'wan'
	option dest_port 'YYYY'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'
	option enabled '0'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option flow_offloading '1'
	option flow_offloading_hw '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option network 'lan'

config zone
	option name 'wan'
	option output 'ACCEPT'
	option masq '1'
	option mtu_fix '1'
	option input 'ACCEPT'
	option forward 'ACCEPT'
	option network 'wan wan6'

config include
	option path '/etc/firewall.user'

config zone
	option forward 'REJECT'
	option output 'ACCEPT'
	option input 'REJECT'
	option masq '1'
	option mtu_fix '1'
	option network 'USTX'
	option name 'vpnoutzone'

config zone
	option name 'VPNServer'
	option input 'ACCEPT'
	option forward 'ACCEPT'
	option output 'ACCEPT'
	option network 'vpns0'
	option log '1'
	option masq '1'

config forwarding
	option dest 'lan'
	option src 'VPNServer'

config forwarding
	option dest 'wan'
	option src 'lan'

config forwarding
	option dest 'vpnoutzone'
	option src 'lan'

The first rule above was the one created, according to the guide that I followed, for allowing incoming VPN traffic.

And finally this is my OpenVPN server config:

config openvpn 'myvpnserver'
	option enabled '1'
	option dev 'tun1'
	option port 'YYYY'
	option proto 'udp'
	option status '/var/log/openvpn_status.log'
	option log '/tmp/openvpnserver.log'
	option verb '4'
	option mute '5'
	option keepalive '10 120'
	option persist_key '1'
	option persist_tun '1'
	option user 'nobody'
	option group 'nogroup'
	option key '/etc/somewhere/XXXXXX.key'
	option ca '/etc/somewhere/XXXX.crt'
	option dh '/etc/somewhere/XXXXXXX.pem'
	option cert '/etc/somewhere/XXXXXXX.crt'
	option mode 'server'
	option tls_server '1'
	option server '192.168.3.0 255.255.255.0'
	option topology 'subnet'
	option route_gateway 'dhcp'
	option client_to_client '1'
	list push 'persist-key'
	list push 'persist-tun'
	list push 'user nobody'
	list push 'user nogroup'
	list push 'topology subnet'
	list push 'route-gateway dhcp'
	list push 'redirect-gateway def1'
	list push 'route 192.168.2.0 255.255.255.0'
	list push 'comp-lzo no'
	list push 'redirect-gateway def1'

Could you please point me in the right direction with this behavior? What am I doing wrong?

A test that I've made recently was trying to connect from my computer, connected to the local network and it connects to the VPN successfully, leading me to think that it's indeed related to a firewall rule.

I appreciate any insight on this.

Thanks!

trendy · October 22, 2019, 4:38pm

I would not use masquerade on the vpnserver firewall zone.
And I would allow both forwardings between vpnserver and lan.
Just to be on the safe side though use the OpenWrt guide for OpenVPN.
https://openwrt.org/docs/guide-user/services/vpn/openvpn/basic

AlejandroME · October 22, 2019, 11:26pm

I've done what you instructed and the problem still persists with the same error

What I did:

Disabled masquerade on the VPN Firewall zone
Ensured bidirectional forwardings between VPNServer-LAN-VPNServer
Generated TLS PSK according to the official instructions
Configured the PSK in the Server config and distributed the key in the client profiles

I'm still getting the same. What else can I discard before trying something new? I compared the VPNServer config against the suggested one in the official docs and the only thing that difers was the TLS PSK.

vgaetera · October 23, 2019, 7:43am

Make the server use TCP and set up PBR.

trendy · October 23, 2019, 8:06am

Even better, disable temporarily the VPN client to verify that this is the culprit before making any changes.

AlejandroME · October 23, 2019, 12:53pm

I'll give this a shot and I'll get back to you shortly.

In the meantime, can I ask what's the reason for using TCP in the server and not UDP?

trendy · October 23, 2019, 1:09pm

PBR has issues with UDP as I recall from a previous post.

vgaetera · October 23, 2019, 1:35pm

This seems to be related to the connection tracking and/or interface binding.
I did not test TCP personally, but I can confirm the issue with OpenVPN server + client over UDP.
On the other hand, WireGuard server + OpenVPN client over UDP works fine with appropriate routing policy.

AlejandroME · October 23, 2019, 1:39pm

I was hesitant to try Wireguard as an alternative to the VPN server that I'm trying to set up because I was trying to figure it out (and learn) a little bit about OVPN.

Also, I've read about the PBR when having a Client and a Server but I ignored that, in part believing that setting up a different port for the server should suffice (I know, nothing to do with the routing).

I'll try the PBR as soon as I get home.

Thanks again!

AlejandroME · November 1, 2019, 7:04pm

Sorry for the late response. Lots of things going on.

I configured PBR + OpenVPN Server in TCP mode and it worked!

Thank you so much for the guidance

system · November 11, 2019, 7:04pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.