I was able to set up the OpenVPN server with egc's guide. After booting the router, Status > OpenVPN shows CONNECTED SUCCESS.
When I test from my phone (on cellular connection), it successfully connects, but immediately starts throwing "read UDPV6 [ECONNREFUSED]: Connection refused (fd=4,code=111)"
If I refresh Status > OpenVPN right after connecting, it's all blank, like the server isn't running. It only comes back after rebooting the router.
Here's syslog starting from me checking VPN status before connecting:
Code:
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: CMD 'state'
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client disconnected
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: CMD 'state'
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client disconnected
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: CMD 'state'
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client disconnected
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client disconnected
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: NOTE: --mute triggered...
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: 1 variation(s) on previous 3 message(s) suppressed by --mute
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: CMD 'status 2'
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client disconnected
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: CMD 'status 2'
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client disconnected
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: CMD 'log 500'
Nov 18 11:02:44 DD-WRT daemon.notice openvpn[1487]: MANAGEMENT: Client disconnected
Nov 18 11:02:59 DD-WRT daemon.notice openvpn[1487]: MULTI: multi_create_instance called
Nov 18 11:02:59 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 Re-using SSL/TLS context
Nov 18 11:02:59 DD-WRT daemon.warn openvpn[1487]: 172.58.165.165:48552 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Nov 18 11:02:59 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 Control Channel MTU parms [ L:1521 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Nov 18 11:02:59 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 Data Channel MTU parms [ L:1521 D:1450 EF:121 EB:389 ET:0 EL:3 AF:14/121 ]
Nov 18 11:02:59 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1421,tun-mtu 1400,proto UDPv4,auth [null-digest],keysize 128,key-method 2,tls-server'
Nov 18 11:02:59 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1421,tun-mtu 1400,proto UDPv4,auth [null-digest],keysize 128,key-method 2,tls-client'
Nov 18 11:02:59 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 TLS: Initial packet from [AF_INET]172.58.165.165:48552, sid=6b889bb7 542bf62f
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 VERIFY OK: depth=1, CN=egcs-ca
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 VERIFY OK: depth=0, CN=egcs-client1
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 peer info: IV_VER=2.6_master
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 peer info: IV_PLAT=android
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 peer info: IV_TCPNL=1
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 peer info: IV_MTU=1600
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 peer info: IV_NCP=2
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 peer info: IV_CIPHERS=CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 peer info: IV_PROTO=470
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 peer info: IV_LZO_STUB=1
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 peer info: IV_COMP_STUB=1
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 peer info: IV_COMP_STUBv2=1
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 peer info: IV_GUI_VER=de.blinkt.openvpn_0.7.41
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 peer info: IV_SSO=openurl,webauth,crtext
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: 172.58.165.165:48552 [egcs-client1] Peer Connection Initiated with [AF_INET]172.58.165.165:48552
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: egcs-client1/172.58.165.165:48552 MULTI_sva: pool returned IPv4=10.8.0.2, IPv6=(Not enabled)
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: egcs-client1/172.58.165.165:48552 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_16570e572080f6d9.tmp
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: egcs-client1/172.58.165.165:48552 MULTI: Learn: 10.8.0.2 -> egcs-client1/172.58.165.165:48552
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: egcs-client1/172.58.165.165:48552 MULTI: primary virtual IP for egcs-client1/172.58.165.165:48552: 10.8.0.2
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: egcs-client1/172.58.165.165:48552 Data Channel: using negotiated cipher 'CHACHA20-POLY1305'
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: egcs-client1/172.58.165.165:48552 Data Channel MTU parms [ L:1434 D:1434 EF:34 EB:389 ET:0 EL:3 AF:14/121 ]
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: egcs-client1/172.58.165.165:48552 Outgoing Data Channel: Cipher 'CHACHA20-POLY1305' initialized with 256 bit key
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: egcs-client1/172.58.165.165:48552 Incoming Data Channel: Cipher 'CHACHA20-POLY1305' initialized with 256 bit key
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: egcs-client1/172.58.165.165:48552 SENT CONTROL [egcs-client1]: 'PUSH_REPLY,redirect-gateway def1,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher CHACHA20-P
Nov 18 11:03:00 DD-WRT daemon.notice openvpn[1487]: egcs-client1/172.58.165.165:48552 PUSH: Received control message: 'PUSH_REQUEST'
Nov 18 11:03:00 DD-WRT user.info : _evalpid:/sbin/service hotplug_net start
Screenshot of current VPN settings is attached.
Please let me know if you need any more information. Thanks!
Last edited by Metostopholes on Tue Nov 29, 2022 2:24; edited 1 time in total
Joined: 18 Mar 2014 Posts: 12922 Location: Netherlands
Posted: Sat Nov 19, 2022 17:49 Post subject:
That is a build with kernel 4.4 which should be fine.
Your settings on the server side seems fine.
It looks like you have set console_debug, I have seen some weird things with that enabled so try with disabling: nvram set console_debug=0
Can you show a screenshot of the OpenVPN Status page before connecting and after connecting of the client.
After connecting show the output from CLI (telnet/Putty) of: ps | grep openvpn
On the client side add these lines to the openvpn config:
pull-filter ignore "route-ipv6"
pull-filter ignore "ifconfig-ipv6"
block-ipv6
Show the whole config file of the client so that we can see if there is any clue in that.
Show the whole log of the client after connecting.
What is the external IP address of the client, does it has a public IPv4 address, it could be that you only have an IPv6 address or that your provider is doing Ipv4 over Ipv6 which can be problematic.
#This is beta build 0.08, use it with care
#OpenVPN client config generated, check if settings are correct see: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=327398, made by egc
client
#windows-driver wintun # only for Windows 10 OpenVPN 2.5.x
verb 3
nobind
persist-key
persist-tun
float
remote-cert-tls server
auth-nocache
tun-mtu 1400 # lowered default can be commented to let OpenVPN decide
#Replace remote address with actual WAN or DDNS address
remote 65.79.136.40 443
dev tun
proto udp4
auth none
data-ciphers CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM
pull-filter ignore "route-ipv6"
pull-filter ignore "ifconfig-ipv6"
block-ipv6
<ca>
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
REDACTED
-----END PRIVATE KEY-----
</key>
Screenshots of status page before and after connecting, and client log attached.
Now, the IPv6 issue might be it. I'm connecting from my phone. When I look in a networking app, it says there's no IPv4, just v6 (2607:fb90:a101:3a68:ad3:c151:806d:47f6). When I go to a website that lists your IP, it shows a v4 (172.58.142.36). Not sure how to interpret that. I am usually going to be connecting from mobile. Is there a way to make it play nice with IPv6?
Are you using port 443 or blocked it with Firewall?
UDPv4 [ECONNREFUSED]: Connection refused (code=111)
The error you see usually means that something blocking your traffic. _________________ Netgear R7800 PPPoE Main Router
Network IPV4 - Isolated Vlan's with IoT Devices. Unifi AC-Pro x 3 AP's, Router Wi-Fi Disabled. OVPN Server With Paid Commercial Wireguard Client's. Gateway Mode, DNSMasq, Static Leases & DHCP, Pi-Hole DNS & Running Unbound.
No one can build you the bridge on which you, and only you, must cross the river of life!
Joined: 18 Mar 2014 Posts: 12922 Location: Netherlands
Posted: Mon Nov 21, 2022 11:56 Post subject:
There are actually two problems.
As already noted by@foz111 your connection form you phone is blocked maybe because yo do not get an IPv4 address.
You should try with your phone on wifi from e.g. a neighbour or friend tot test if it is working at all.
If this really is an IPv6 only provider (T-mobile is one I know off, but check with your provider) you can not reach a hard coded IPv4 address at all, you should be able reach a DDNS address as there is a translation from DNS to IPv4 address.
So try with using a DDNS address for your router.
Furthermore IPv4 over IPv6 has serious MTU problems.
So you should lower MTU to 1280 or 1278 sometimes you have to go even lower, MTU should be set on Client and Server.
Yes, the mobile provider is T-Mobile. Also I checked my home ISP, and they do not support IPv6, ONLY IPv4.
So I've been trying some things. I set up a 6in4 tunnel using this tutorial, but it made no difference. Also no change if using IP address or DDNS url.
Lower MTU settings do make a difference, and after some trial and error the cutoff point is 1040. It it's above that, the OpenVPN server crashes as we've seen.
If MTU is set to 1040 or lower, the client appears to connect and the VPN server doesn't crash, but it can't authenticate. Eventually on both sides it gives errors that TLS Handshake didn't happen in time (see attached screenshots).
I won't have access to another network to test from until later this week, but I will let you know what happens there.
Sorry, it took longer than planned to get access to an outside network. For various reasons, I wasn't able to save the logs from testing there.
Testing gave the exact same results as from my mobile network. Over 1040 MTU and the OpenVPN server crashed. MTU of 1040 or lower and TLS handshake times out.
Websites that list public IP showed v4 and v6 addresses on this outside network, so I'm not sure how that was configured. If I disabled IPv6 in the network adapter (this was from a Windows client), those websites only showed a v4 address, but all tests were still the same.
Sorry for the lack of logs. Please let me know if there's other things to test here.
Try another port would be my first port of call.
As long as you're not using https (443) it should work but takes seconds to change and retest.
With the server crashing just seems odd so maybe a port bind issue causing crash? _________________ Netgear R7800 PPPoE Main Router
Network IPV4 - Isolated Vlan's with IoT Devices. Unifi AC-Pro x 3 AP's, Router Wi-Fi Disabled. OVPN Server With Paid Commercial Wireguard Client's. Gateway Mode, DNSMasq, Static Leases & DHCP, Pi-Hole DNS & Running Unbound.
No one can build you the bridge on which you, and only you, must cross the river of life!
Joined: 18 Mar 2014 Posts: 12922 Location: Netherlands
Posted: Mon Nov 28, 2022 11:03 Post subject:
I would certainly try @foz111 suggestion.
It is really weird that the OpenVPN server is crashing, something which I have seldom seen, if you have bad settings the server will not start but it starts normally and then crashes upon connection.
To further narrow the problem can you upgrade to the next build 50841 and see if the problem returns.
Can you set on the crashing server in Additional Configuration: verb 11
and after the crash see if syslog has some output, from the command line (telnet/putty):
grep -i openvpn /var/log/messages