Random OpenVPN drops

Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking
Author Message
Nightbridge
DD-WRT User


Joined: 09 Jan 2017
Posts: 76
Location: Dublin

PostPosted: Sat Jul 16, 2022 13:50    Post subject: Random OpenVPN drops Reply with quote
Hi all, I have recently set up an OpenVPN Server/Client on two D-Link DIR-882 A1. The VPN looks to be working fine, but after a day or less from both server and client reboot I am getting a couple of minutes of no internet available through the VPN, it then resumes itself.
The following are the logs of both routers after a reboot. Anyone see something wrong?

PS now the routers are running v48494, I have tried yesterday with the brand new 49492 (MTU 1500, 1400 and 0) but the interruptions where way more frequent.

Thanks to everybody

Serverlog:
19700101 00:00:31 I net_iface_mtu_set: mtu 1400 for tun2
19700101 00:00:31 I net_iface_up: set tun2 up
19700101 00:00:31 I net_addr_v4_add: 192.168.3.1/24 dev tun2
19700101 00:00:32 Data Channel MTU parms [ L:1521 D:1450 EF:121 EB:389 ET:0 EL:3 ]
19700101 00:00:32 Socket Buffers: R=[163840->163840] S=[163840->163840]
19700101 00:00:32 I UDPv4 link local (bound): [AF_INET][undef]:1194
19700101 00:00:32 I UDPv4 link remote: [AF_UNSPEC]
19700101 00:00:32 MULTI: multi_init called r=256 v=256
19700101 00:00:32 IFCONFIG POOL IPv4: base=192.168.3.2 size=253
19700101 00:00:32 I Initialization Sequence Completed
19700101 00:00:36 MULTI: multi_create_instance called
19700101 00:00:36 <<CLIENT_IP>>:40126 Re-using SSL/TLS context
19700101 00:00:36 W <<CLIENT_IP>>:40126 WARNING: normally if you use --mssfix and/or --fragment you should also set --tun-mtu 1500 (currently it is 1400)
19700101 00:00:36 <<CLIENT_IP>>:40126 Control Channel MTU parms [ L:1521 D:1212 EF:38 EB:0 ET:0 EL:3 ]
19700101 00:00:36 <<CLIENT_IP>>:40126 Data Channel MTU parms [ L:1521 D:1450 EF:121 EB:389 ET:0 EL:3 ]
19700101 00:00:36 <<CLIENT_IP>>:40126 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'
19700101 00:00:36 <<CLIENT_IP>>:40126 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'
19700101 00:00:36 <<CLIENT_IP>>:40126 TLS: Initial packet from [AF_INET]<<CLIENT_IP>>:40126 sid=da17b1db 2ab60731
19700101 00:00:36 N <<CLIENT_IP>>:40126 VERIFY ERROR: depth=1 error=certificate is not yet valid: CN=dd-wrt-ca serial=10007000117001932921
19700101 00:00:36 N <<CLIENT_IP>>:40126 OpenSSL: error:1417C086:lib(20):func(380):reason(134)
19700101 00:00:36 N <<CLIENT_IP>>:40126 TLS_ERROR: BIO read tls_read_plaintext error
19700101 00:00:36 <<CLIENT_IP>>:40126 NOTE: --mute triggered...
19700101 00:00:36 <<CLIENT_IP>>:40126 2 variation(s) on previous 3 message(s) suppressed by --mute
19700101 00:00:36 <<CLIENT_IP>>:40126 SIGUSR1[soft tls-error] received client-instance restarting
20220716 14:22:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20220716 14:22:29 D MANAGEMENT: CMD 'state'
20220716 14:22:29 MANAGEMENT: Client disconnected
20220716 14:22:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20220716 14:22:29 D MANAGEMENT: CMD 'state'
20220716 14:22:29 MANAGEMENT: Client disconnected
20220716 14:22:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20220716 14:22:29 D MANAGEMENT: CMD 'state'
20220716 14:22:29 MANAGEMENT: Client disconnected
20220716 14:22:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20220716 14:22:29 MANAGEMENT: Client disconnected
20220716 14:22:29 NOTE: --mute triggered...
20220716 14:22:29 1 variation(s) on previous 3 message(s) suppressed by --mute
20220716 14:22:29 D MANAGEMENT: CMD 'status 2'
20220716 14:22:29 MANAGEMENT: Client disconnected
20220716 14:22:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20220716 14:22:29 D MANAGEMENT: CMD 'status 2'
20220716 14:22:29 MANAGEMENT: Client disconnected
20220716 14:22:29 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:14
20220716 14:22:29 D MANAGEMENT: CMD 'log 500'
20220716 14:22:29 MANAGEMENT: Client disconnected
20220716 14:22:42 MULTI: multi_create_instance called
20220716 14:22:42 <<CLIENT_IP>>:55236 Re-using SSL/TLS context
20220716 14:22:42 W <<CLIENT_IP>>:55236 WARNING: normally if you use --mssfix and/or --fragment you should also set --tun-mtu 1500 (currently it is 1400)
20220716 14:22:42 <<CLIENT_IP>>:55236 Control Channel MTU parms [ L:1521 D:1212 EF:38 EB:0 ET:0 EL:3 ]
20220716 14:22:42 <<CLIENT_IP>>:55236 Data Channel MTU parms [ L:1521 D:1450 EF:121 EB:389 ET:0 EL:3 ]
20220716 14:22:42 <<CLIENT_IP>>:55236 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'
20220716 14:22:42 <<CLIENT_IP>>:55236 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'
20220716 14:22:42 <<CLIENT_IP>>:55236 TLS: Initial packet from [AF_INET]<<CLIENT_IP>>:55236 sid=89e108b4 6ebc4f1e
20220716 14:22:42 <<CLIENT_IP>>:55236 VERIFY OK: depth=1 CN=dd-wrt-ca
20220716 14:22:42 <<CLIENT_IP>>:55236 VERIFY OK: depth=0 CN=client-dd-wrt
20220716 14:22:42 I <<CLIENT_IP>>:55236 peer info: IV_VER=2.5.5
20220716 14:22:42 I <<CLIENT_IP>>:55236 peer info: IV_PLAT=linux
20220716 14:22:42 I <<CLIENT_IP>>:55236 peer info: IV_PROTO=6
20220716 14:22:42 I <<CLIENT_IP>>:55236 peer info: IV_NCP=2
20220716 14:22:42 I <<CLIENT_IP>>:55236 peer info: IV_CIPHERS=CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM
20220716 14:22:42 I <<CLIENT_IP>>:55236 peer info: IV_LZ4=1
20220716 14:22:42 I <<CLIENT_IP>>:55236 peer info: IV_LZ4v2=1
20220716 14:22:42 I <<CLIENT_IP>>:55236 peer info: IV_LZO=1
20220716 14:22:42 I <<CLIENT_IP>>:55236 peer info: IV_COMP_STUB=1
20220716 14:22:42 I <<CLIENT_IP>>:55236 peer info: IV_COMP_STUBv2=1
20220716 14:22:42 I <<CLIENT_IP>>:55236 peer info: IV_TCPNL=1
20220716 14:22:42 W <<CLIENT_IP>>:55236 WARNING: 'link-mtu' is used inconsistently local='link-mtu 1421' remote='link-mtu 1434'
20220716 14:22:42 W <<CLIENT_IP>>:55236 WARNING: 'keysize' is used inconsistently local='keysize 128' remote='keysize 256'
20220716 14:22:43 <<CLIENT_IP>>:55236 Control Channel: TLSv1.3 cipher TLSv1.3 TLS_AES_256_GCM_SHA384 peer certificate: 2048 bit RSA signature: RSA-SHA256
20220716 14:22:43 I <<CLIENT_IP>>:55236 [client-dd-wrt] Peer Connection Initiated with [AF_INET]<<CLIENT_IP>>:55236
20220716 14:22:43 I client-dd-wrt/<<CLIENT_IP>>:55236 MULTI_sva: pool returned IPv4=192.168.3.2 IPv6=(Not enabled)
20220716 14:22:43 client-dd-wrt/<<CLIENT_IP>>:55236 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_695901dd31282d19.tmp
20220716 14:22:43 client-dd-wrt/<<CLIENT_IP>>:55236 MULTI: Learn: 192.168.3.2 -> client-dd-wrt/<<CLIENT_IP>>:55236
20220716 14:22:43 client-dd-wrt/<<CLIENT_IP>>:55236 MULTI: primary virtual IP for client-dd-wrt/<<CLIENT_IP>>:55236: 192.168.3.2
20220716 14:22:43 client-dd-wrt/<<CLIENT_IP>>:55236 Data Channel: using negotiated cipher 'CHACHA20-POLY1305'
20220716 14:22:43 client-dd-wrt/<<CLIENT_IP>>:55236 Data Channel MTU parms [ L:1434 D:1434 EF:34 EB:389 ET:0 EL:3 ]
20220716 14:22:43 client-dd-wrt/<<CLIENT_IP>>:55236 Outgoing Data Channel: Cipher 'CHACHA20-POLY1305' initialized with 256 bit key
20220716 14:22:43 client-dd-wrt/<<CLIENT_IP>>:55236 Incoming Data Channel: Cipher 'CHACHA20-POLY1305' initialized with 256 bit key
20220716 14:22:43 client-dd-wrt/<<CLIENT_IP>>:55236 SENT CONTROL [client-dd-wrt]: 'PUSH_REPLY redirect-gateway def1 route-gateway 192.168.3.1 topology subnet ping 10 ping-restart 120 ifconfig 192.168.3.2 255.255.255.0 peer-id 0 cipher CHACHA20-POLY1305' (status=1)
20220716 14:22:43 client-dd-wrt/<<CLIENT_IP>>:55236 PUSH: Received control message: 'PUSH_REQUEST'



Clientlog:
20220716 15:22:07 VERIFY OK: depth=0 CN=server-dd-wrt
20220716 15:22:21 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220716 15:22:21 D MANAGEMENT: CMD 'state'
20220716 15:22:21 MANAGEMENT: Client disconnected
20220716 15:22:21 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220716 15:22:21 D MANAGEMENT: CMD 'state'
20220716 15:22:21 MANAGEMENT: Client disconnected
20220716 15:22:21 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220716 15:22:21 D MANAGEMENT: CMD 'state'
20220716 15:22:21 MANAGEMENT: Client disconnected
20220716 15:22:21 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220716 15:22:21 D MANAGEMENT: CMD 'status 2'
20220716 15:22:21 MANAGEMENT: Client disconnected
20220716 15:22:22 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:16
20220716 15:22:22 D MANAGEMENT: CMD 'log 500'
20220716 15:22:22 MANAGEMENT: Client disconnected
20220716 15:22:37 N TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
20220716 15:22:37 N TLS Error: TLS handshake failed
20220716 15:22:37 TCP/UDP: Closing socket
20220716 15:22:37 I SIGUSR1[soft tls-error] received process restarting
20220716 15:22:37 Restart pause 5 second(s)
20220716 15:22:42 W WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
20220716 15:22:42 W NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
20220716 15:22:42 W WARNING: normally if you use --mssfix and/or --fragment you should also set --tun-mtu 1500 (currently it is 1400)
20220716 15:22:42 Control Channel MTU parms [ L:1521 D:1212 EF:38 EB:0 ET:0 EL:3 ]
20220716 15:22:42 Data Channel MTU parms [ L:1521 D:1450 EF:121 EB:389 ET:0 EL:3 ]
20220716 15:22:42 Local Options String (VER=V4): 'V4 dev-type tun link-mtu 1434 tun-mtu 1400 proto UDPv4 cipher CHACHA20-POLY1305 auth [null-digest] keysize 256 key-method 2 tls-client'
20220716 15:22:42 Expected Remote Options String (VER=V4): 'V4 dev-type tun link-mtu 1434 tun-mtu 1400 proto UDPv4 cipher CHACHA20-POLY1305 auth [null-digest] keysize 256 key-method 2 tls-server'
20220716 15:22:42 I TCP/UDP: Preserving recently used remote address: [AF_INET]<<SERVER_IP>>:1194
20220716 15:22:42 Socket Buffers: R=[163840->163840] S=[163840->163840]
20220716 15:22:42 I UDPv4 link local: (not bound)
20220716 15:22:42 I UDPv4 link remote: [AF_INET]<<SERVER_IP>>:1194
20220716 15:22:42 TLS: Initial packet from [AF_INET]<<SERVER_IP>>:1194 sid=f5ce619d c8a02575
20220716 15:22:42 VERIFY OK: depth=1 CN=dd-wrt-ca
20220716 15:22:42 VERIFY OK: depth=0 CN=server-dd-wrt
20220716 15:22:42 W WARNING: 'link-mtu' is used inconsistently local='link-mtu 1434' remote='link-mtu 1421'
20220716 15:22:42 W WARNING: 'keysize' is used inconsistently local='keysize 256' remote='keysize 128'
20220716 15:22:42 Control Channel: TLSv1.3 cipher TLSv1.3 TLS_AES_256_GCM_SHA384 peer certificate: 2048 bit RSA signature: RSA-SHA256
20220716 15:22:42 I [server-dd-wrt] Peer Connection Initiated with [AF_INET]<<SERVER_IP>>:1194
20220716 15:22:43 SENT CONTROL [server-dd-wrt]: 'PUSH_REQUEST' (status=1)
20220716 15:22:43 PUSH: Received control message: 'PUSH_REPLY redirect-gateway def1 route-gateway 192.168.3.1 topology subnet ping 10 ping-restart 120 ifconfig 192.168.3.2 255.255.255.0 peer-id 0 cipher CHACHA20-POLY1305'
20220716 15:22:43 Pushed option removed by filter: 'redirect-gateway def1'
20220716 15:22:43 NOTE: --mute triggered...
20220716 15:22:43 6 variation(s) on previous 3 message(s) suppressed by --mute
20220716 15:22:43 Outgoing Data Channel: Cipher 'CHACHA20-POLY1305' initialized with 256 bit key
20220716 15:22:43 Incoming Data Channel: Cipher 'CHACHA20-POLY1305' initialized with 256 bit key
20220716 15:22:43 net_route_v4_best_gw query: dst 0.0.0.0
20220716 15:22:43 net_route_v4_best_gw result: via 192.168.1.1 dev vlan2
20220716 15:22:43 I TUN/TAP device tun1 opened
20220716 15:22:43 do_ifconfig ipv4=1 ipv6=0
20220716 15:22:43 I net_iface_mtu_set: mtu 1400 for tun1
20220716 15:22:43 I net_iface_up: set tun1 up
20220716 15:22:43 I net_addr_v4_add: 192.168.3.2/24 dev tun1
20220716 15:22:43 net_route_v4_add: <<SERVER_IP>>/32 via 192.168.1.1 dev [NULL] table 0 metric -1
20220716 15:22:43 W WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
20220716 15:22:43 I Initialization Sequence Completed
Sponsor
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 9157

PostPosted: Sun Jul 17, 2022 4:39    Post subject: Reply with quote
I'm not sure what you're saying. Is the problem the router is rebooting itself unexpectedly, or is this a purposeful reboot and it just takes too long for the VPN to get reestablished?

If it's the latter, this isn't abnormal. Until the time is set by the ntp client, the VPN's certs't can be verified as to validity (i.e., whether the current date/time falls within the range of the creation and expiration dates).

That's why you're seeing the following in the syslog of the OpenVPN server when the OpenVPN client attempts to connect (note the date/time of 19700101).

Code:
19700101 00:00:36 <<CLIENT_IP>>:40126 TLS: Initial packet from [AF_INET]<<CLIENT_IP>>:40126 sid=da17b1db 2ab60731
19700101 00:00:36 N <<CLIENT_IP>>:40126 VERIFY ERROR: depth=1


Once the time is updated, the connection is finally established.

_________________
ddwrt-ovpn-split-basic.sh (UPDATED!) * ddwrt-ovpn-split-advanced.sh (UPDATED!) * ddwrt-ovpn-client-killswitch.sh * ddwrt-ovpn-client-watchdog.sh * ddwrt-ovpn-remote-access.sh * ddwrt-ovpn-client-backup.sh * ddwrt-mount-usb-drives.sh * ddwrt-blacklist-domains.sh * ddwrt-wol-port-forward.sh * ddwrt-dns-monitor.sh (NEW!)
Nightbridge
DD-WRT User


Joined: 09 Jan 2017
Posts: 76
Location: Dublin

PostPosted: Sun Jul 17, 2022 10:51    Post subject: Reply with quote
Hi, no actually the routers don’t reboot themselves, this was just a reboot I did manually to show the starting logs. Everything looks normal but devices connected to the client stop accessing the WAN fo a while and if I check the wifi connection I can “no internet access”.
After a while everything starts working again.
eibgrad
DD-WRT Guru


Joined: 18 Sep 2010
Posts: 9157

PostPosted: Sun Jul 17, 2022 17:21    Post subject: Reply with quote
Nightbridge wrote:
Hi, no actually the routers don’t reboot themselves, this was just a reboot I did manually to show the starting logs. Everything looks normal but devices connected to the client stop accessing the WAN fo a while and if I check the wifi connection I can “no internet access”.
After a while everything starts working again.


What can sometimes happen is that clients have long standing connections that they *assume* are still valid, even after the router is rebooted. So the client just keeps trying to use them until it finally realizes those connections are gone and NOT coming back, then reinitializes those connections. But that process can take some time.

I experience the same thing when using my own OpenVPN client connected to a commercial OpenVPN provider. For maximum stealthiness, I will FORCE a restart of the OpenVPN client every 4 hours. Since I randomize the servers, that typically changes the server and public IP. But it has an undesirable side-effect; it invalidates any long standing connections for those clients bound to the VPN! Those clients will likewise go through a period of "no internet access" until they finally realize they need to reestablish those connections.

IOW, rebooting the router or doing anything that disturbs long standing connections is bound to cause these types of interruptions. That's precisely why you do NOT want to causally reboot the router as if it's no big deal. I know some ppl do so on a nightly basis believing it increases stability, but at least that's during a period of little to no activity.

_________________
ddwrt-ovpn-split-basic.sh (UPDATED!) * ddwrt-ovpn-split-advanced.sh (UPDATED!) * ddwrt-ovpn-client-killswitch.sh * ddwrt-ovpn-client-watchdog.sh * ddwrt-ovpn-remote-access.sh * ddwrt-ovpn-client-backup.sh * ddwrt-mount-usb-drives.sh * ddwrt-blacklist-domains.sh * ddwrt-wol-port-forward.sh * ddwrt-dns-monitor.sh (NEW!)
Nightbridge
DD-WRT User


Joined: 09 Jan 2017
Posts: 76
Location: Dublin

PostPosted: Mon Jul 18, 2022 11:44    Post subject: Reply with quote
Hi, sorry for the late reply. I have created this VPN for a friend, I am rebooting quite often as I am making some small changes here and there to see if I can get some more stability.
In my own case for example, I have an OpenVPN server on a WRT1200AC and the client on a WRT1900ACS, but I never reboot them, it can happen a couple of times during the year and that's it, but the connection is always great, I have never experienced this "hiccups".
I have a question please, for this friend I have followed entirely the guide, and I have this firewall rule:

Code:
iptables -t nat -I POSTROUTING -s 192.168.3.0/24 -o $(get_wanface) -j MASQUERADE


in my configuration instead I have this one:

Code:
iptables -t nat -A POSTROUTING -s 192.168.3.0/24 -j MASQUERADE


how do they differ exactly?

Many thanks
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12834
Location: Netherlands

PostPosted: Mon Jul 18, 2022 15:45    Post subject: Reply with quote
Page 11 of the OpenVPN Server setup guide:
Quote:
Allow Clients WAN access (internet)
Enable
This will allow VPN clients to have a way out of the router to the internet, so effectively giving VPN clients internet access.
This adds the firewall rule:
iptables -t nat -A POSTROUTING -s $(nvram get openvpn_net)/$(nvram get openvpn_tunmask) -o $(get_wanface) -j MASQUERADE


So neither rule does look exactly like the official rule but all will work.

In this case there is no functional difference between -I and -A.

Your own rule lacks the out interface which can have unwanted side effects but will work to enable Internet for your VPN clients.

In most cases just using the GUI to do the work for you is the recommended way Smile

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Nightbridge
DD-WRT User


Joined: 09 Jan 2017
Posts: 76
Location: Dublin

PostPosted: Mon Jul 18, 2022 15:50    Post subject: Reply with quote
Thanks @egc, so I can completely remove the firewall rule and just have this enabled?

"Allow Clients WAN access (internet)"
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12834
Location: Netherlands

PostPosted: Mon Jul 18, 2022 16:06    Post subject: Reply with quote
Nightbridge wrote:
Thanks @egc, so I can completely remove the firewall rule and just have this enabled?

"Allow Clients WAN access (internet)"


Exactly, but like I said all rules actually work.

About the hiccups at your friends, his D-Link DIR-882 A1 (Ralink/Mediatek) are not the most stable routers, I would first research where the hiccups originate.
Check if it is a wireless problem (my first idea) or a WAN problem?

Without actually seeing what goes on when the hiccups occur we can not say much about it.

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Nightbridge
DD-WRT User


Joined: 09 Jan 2017
Posts: 76
Location: Dublin

PostPosted: Mon Jul 18, 2022 16:13    Post subject: Reply with quote
Hi @egc, thanks again for your replies.
Yeah, at the beginning I thought it was a wireless issue, but I have set an OpenVPN client on his iPhone so that he can connect to the VPN when he is out and he is facing the same issues (so probably this is a server side issue).

Any idea what could I check? I can't see anything bad in the OpenVPN server logs.

Thank you
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12834
Location: Netherlands

PostPosted: Mon Jul 18, 2022 16:21    Post subject: Reply with quote
Maybe it is his Iphone, who knows?

Like I said without actually having logs which show anything when the problem occur we cannot say much.

The VPN troubleshooting guide has some general tips.
Have a look there.

Make sure SFE is turned off and MTU is 1400 at both client and server.

You can always try TCP4 instead of UDP4.

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087


Last edited by egc on Mon Jul 18, 2022 18:19; edited 1 time in total
Nightbridge
DD-WRT User


Joined: 09 Jan 2017
Posts: 76
Location: Dublin

PostPosted: Mon Jul 18, 2022 18:18    Post subject: Reply with quote
Yes, that's my configuration indeed.
I have another question please, the server/client configurations I said have been taken from the guide. But there are a couple of mismatch for server/client. Like:

Code:

Server:
CVE-2019-14899 Mitigation: DISABLED
...
Encryption Cipher: "Not set"

Client:
CVE-2019-14899 Mitigation: ENABLED
...
Encryption Cipher: "CHACHA20-POLY1305"


Can't these discrepancies create problems?
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12834
Location: Netherlands

PostPosted: Tue Jul 19, 2022 6:57    Post subject: Reply with quote
The server should have CVE mitigation (always) disabled, Client is your choice (explained in small print in the guide)

Encryption cipher is obsolete and will be deprecated in future OpenVPN upgrades it is there for legacy purposes.

Normally do Not set this

Important are the data-ciphers (and the order in which they appear) you want the safest and the fastest and that is ChachaPoly so set that as first data cipher in client and server.
As only the newest clients have ChachaPoly you also set the other data ciphers
Of course if you control both server and clients and all are new you can just only use ChachaPoly

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Nightbridge
DD-WRT User


Joined: 09 Jan 2017
Posts: 76
Location: Dublin

PostPosted: Tue Jul 19, 2022 18:09    Post subject: Reply with quote
OK, thanks. I have disabled the CVE mitigation and the Encryption cipher. About the data-ciphers when I have removed the AES ones the server/client routers where still working great, but the iPhone stopped working (I have updated the ovpn file accordingly), so I needed to add them back.
Will test during next days is I achieved more stability. Thanks for your help.
egc
DD-WRT Guru


Joined: 18 Mar 2014
Posts: 12834
Location: Netherlands

PostPosted: Tue Jul 19, 2022 18:25    Post subject: Reply with quote
Yes the iPhone has an older client will probably not support chachapoly.

That is why you add more dataciphers on the server side but start with chachapoly

_________________
Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399
Install guide R7800/XR500: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614
Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Nightbridge
DD-WRT User


Joined: 09 Jan 2017
Posts: 76
Location: Dublin

PostPosted: Wed Jul 20, 2022 17:58    Post subject: Reply with quote
Cool, thanks @egc.
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> Advanced Networking All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum