[Beta 382] Asuswrt-Merlin 382.2 Beta is now available

[mister]

Dear all,
first of all many thanks for the great beta firmware.

I found a little bug. The VPN connection is not restored after a reboot with the correct client. E.g. if client 3 is active and you reboot, after rebooting client 1 is active and client 3 is deactivated....

 

[king006]

Hello everyone,

Thanks for the beta for the rt-ac68u! He works fine!
The QOS function for the guest network works well! But the QOS function doesn’t work if you have a custom DHCP server used for the guest network? (I used http://rtr.ca/merlin/enable_dhcp_for_guests.sh)

I manually add on the QOS Bandwidth Limiter option two subnets. (192.168.10.2/24 and 192.168.11.2/24) with a download speed of 20 and a upload speed of 5. The upload is limited to 5 with a speedtest but the download continues to the maximum of the provider?

What I am doing wrong?

Another question, I set enable_dhcp_for_guests.sh in
/jffs/scripts/ and make a startup script with:

#!/bin/sh
/jffs/scripts/enable_dhcp_for_guests.sh

That works, the script /jffs/scripts/enable_dhcp_for_guests.sh is running after a reboot. But after that the guests network is very unstable. (connection lost with te guest network about 5/10 seconds and that all the time)

Thank you!

 

[tavares]

I started a new server configuration. I can confirm there's no Internet on my VPN as well.
It was working on Alpha2. It seems internet redirect is broken in the RT-68u beta.

Yes, It seems that there is a problem with VPN on beta, I put again the Alpha2 and everything was ok.
I also think that there is a problem with the "Direct clients to redirect Internet traffic".

 

[Jan Adelsson]

Why i get this in my log?

Dec 30 17:26:18 kernel: net_ratelimit: 701 callbacks suppressed
Dec 30 17:26:18 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:18 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:18 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:18 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:18 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:18 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:18 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:18 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:18 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:18 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:26 kernel: net_ratelimit: 260 callbacks suppressed
Dec 30 17:26:26 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:26 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:26 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:26 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:26 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:26 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:26 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:26 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:26 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:26 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:31 kernel: net_ratelimit: 761 callbacks suppressed
Dec 30 17:26:31 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:31 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:31 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:31 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:31 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:31 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:31 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:31 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:31 kernel: TCP: time wait bucket table overflow
Dec 30 17:26:31 kernel: TCP: time wait bucket table overflow[/CODE]

 

[king006]

Yes, It seems that there is a problem with VPN on beta, I put again the Alpha2 and everything was ok.
I also think that there is a problem with the "Direct clients to redirect Internet traffic".

I also have problems with internet as I'm connected through the VPN server. (RT-68u)

 

[DonnyJohnny]

Me too have the problem with vpn. Client connected only with Intranet but no Internet.

No ping and the DNS in the VPN client is still the current DNS and not the router DNS.

Last log in server.
MULTI: bad source address from client [10.129.241.96], packet dropped

Log in client
OpenVPN ROUTE: failed to parse/resolve route for host/network: ::/0

Ac68u

 

[JacquesR]

OpenVPN working fine for me, also on 68U and the 382 beta.

 

[Vexira]

Three minor things:

1. * Reminder: The System time zone is different from your locale setting. I had this before and it is wrong, I even cannot change the time in the GUI anyway, right?
   
   
2. Let's Encrypt is only active when you're using the built-in DDNS, but I can't because Asus is to stupid to implement an optional external IP-Check. So it would be nice to give the domain-name once manually for Let's Encrypt to work.
   
   
3. Wireless - WPS only available for 2,4 GHz.

Go to system administration and set your time zone there, make sure you adjust for daylight saving time if necessary.

 

[metadethrax]

@RMerlin does this fix the slow down issue users were experiencing after a few hours with 382.1_2? It was on the rt3100.

Tried the beta on my AC68U with a PPPoE gigabit connection: same download speed issues introduced with the 382 official branch. With Ai Protection enabled, download speed drops to about 1/4, so I'm going from 900+ Mbps to 200-220 Mbps. Upload speed is not affected, still having the normal 500 Mbps. There is something fishy in this 382 firmware, at least with PPPoE connections. I guess 380.69 is the end of the line for me, at least until Merlin or Asus figure out what causes this outrageous speed drop.

 

[skeal]

Is this just me or what? Updated to the new Beta and I can't find any info on this QOS error.

Dec 31 06:09:49 kernel: ERR[update_qos_data_by_mac:3568] Failed to find udb entry by skb src-MAC!

The only google hits I get are snbforums when looking up this problem. Is this problem just informational and no problem or is it a sign of something else. I have restored to factory defaults and turned QOS off for a while and back on. Still have this error showing once in a while.

 

[TinMan11]

Tried the beta on my AC68U with a PPPoE gigabit connection: same download speed issues introduced with the 382 official branch. With Ai Protection enabled, download speed drops to about 1/4, so I'm going from 900+ Mbps to 200-220 Mbps. Upload speed is not affected, still having the normal 500 Mbps. There is something fishy in this 382 firmware, at least with PPPoE connections. I guess 380.69 is the end of the line for me, at least until Merlin or Asus figure out what causes this outrageous speed drop.

I too am using Oppose, definitely something fishy going on there. Did you factory reset after upgrading to 382? Or dirty flash? (Ie. no reset)

 

[m33ts4k0z]

Three minor things:

1. * Reminder: The System time zone is different from your locale setting. I had this before and it is wrong, I even cannot change the time in the GUI anyway, right?
   
   
2. Let's Encrypt is only active when you're using the built-in DDNS, but I can't because Asus is to stupid to implement an optional external IP-Check. So it would be nice to give the domain-name once manually for Let's Encrypt to work.
   
   
3. Wireless - WPS only available for 2,4 GHz.

1. Look up on google about the date that the DST is changing in your country and input it manually. This will make that message disappear.

2. For a certificate to be validated with Let's Encrypt, a way must exist for Let's Encrypt to actually verify that the web page is actually real and reachable over the Internet. It doesnt matter if you get a web address like i.e. : mygreatrouter.asuscomm.com since afterwards you can set up up to 100 SANs on the available line but all of them need to be reachable over the Internet. I uploaded my own certs from Let's Encrypt to the router because my Synology NAS creates them automatically. What is exactly the problem with using Asus DDNS?

3. You need to deactivate the WPS function in order to swap between bands.

 

[m33ts4k0z]

What are the requirements for let's encrypt to work? I am using namecheap for my DDNS and when I try using Let's encrypt, it doesn't appear to do anything. Nothing in the logs either. Back to using a regular cert for now I guess.

If you tried Asus DDNS service and Let's Encrypt works then it can be limited to them.

 

[snakebite3]

OpenVPN working fine for me, also on 68U and the 382 beta.

"Direct clients to redirect Internet traffic" works for you?

 

[king006]

OpenVPN working fine for me, also on 68U and the 382 beta.

Strange! Can you show a printscreen of your VPN settings?

"Direct clients to redirect Internet traffic" works for you?

I think that can not! As far as I can see the firewall on the ASUS router blocks the outgoing connection to the website/internet.

 

[stoli412]

Strange! Can you show a printscreen of your VPN settings?


I think that can not! As far as I can see the firewall on the ASUS router blocks the outgoing connection to the website/internet.

I’m also having problems with the VPN Server on 382.2 beta on the 86u. I manually re-entered my VPN Server settings exactly from 380.69 on the 68u. Clients can connect to the VPN and have LAN access but no WAN access. In the router log I see the firewall is dropping all traffic coming from VPN clients to the WAN.

I thought this may have been some configuration issue on my end since I’m both changing routers (68u to 86u) and going from 380.69 to 382.2, but it looks like others are having the same issue.

 

[eclp]

@RMerlin ...

I have two devices RT-AC88U, one revision A5 and one A2, Merlin 382.2 Beta is installed on both routers, both devices run in wireless mode as Routers (at separate Locations). Before I flashed the new beta firmware, Factory-Reset, after installing it again.
Why are there no "CONSOLE" entries in Rev. A2 but in Rev. A5?
Another question, what do the "dnsmasq: warning" in Rev. A5 messages mean?

RT-AC88U Rev. A2

Dec 31 16:02:15 kernel: CONSOLE: 116895.486 ampdu_dbg: ifsstat 0xa2 nav_stat 0x1 txop 110725
Dec 31 16:02:15 kernel: CONSOLE: 116895.486 ampdu_dbg: pktpend: 0 0 0 0 0 ap 1
Dec 31 16:02:15 kernel: CONSOLE: 116895.486 ampdu_dbg: txall 2 txbcn 0 txrts 0 rxcts 0 rsptmout 0 rxstrt 0
Dec 31 16:02:15 kernel: CONSOLE: 116895.486 ampdu_dbg: cwcur0-3 f f 7 3 bslots cur/0-3 14 0 0 0 0 ifs_boff 0
Dec 31 16:02:15 kernel: CONSOLE: 116895.486 ampdu_dbg: again1 ifsstat 0xa2 nav_stat 0x1
Dec 31 16:02:15 kernel: CONSOLE: 116895.486 ampdu_dbg: again2 ifsstat 0xa2 nav_stat 0x1
Dec 31 16:02:15 kernel: CONSOLE: 116895.486 wl1: wlc_ampdu_watchdog: cleaning up ini tid 0 due to no progress for 2 secs tx_in_transit 1
Dec 31 16:02:15 kernel: CONSOLE: 116895.486 wl1: wlc_ampdu_tx_send_delba: tid 0 initiator 1 reason 39
Dec 31 16:03:46 kernel: CONSOLE: 116986.058 wl1.0: wlc_send_bar: seq 0x26e tid 0
Dec 31 16:06:46 kernel: CONSOLE: 117165.486 ampdu_dbg: wl1.0 b8:53:ac:97:09:86 scb:0033dbd0 tid:0

RT-AC88U Rev. A5

Dec 31 15:55:21 dnsmasq[6791]: warning: no upstream servers configured
Dec 31 15:55:35 dnsmasq[6807]: warning: no upstream servers configured
Dec 31 15:55:21 dnsmasq[6791]: warning: no upstream servers configured
Dec 31 15:55:35 dnsmasq[6807]: warning: no upstream servers configured

 

[m33ts4k0z]

OVPN Works here as well even with Redirect Internet Traffic = ALL (RT88U). Here is the config file automatically generated by Torguard's ovpn config file tool choosing ASUS firmware:

client
dev tun
proto udp
remote frank.gr.torguardvpnaccess.com 1215
remote-cert-tls server
auth SHA512
key-direction 1
setenv CLIENT_CERT 0
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
770e8de5fc56e0248cc7b5aab56be80d
0e19cbf003c1b3ed68efbaf08613c3a1
a019dac6a4b84f13a6198f73229ffc21
fa512394e288f82aa2cf0180f01fb3eb
1a71e00a077a20f6d7a83633f5b4f47f
27e30617eaf8485dd8c722a8606d56b3
c183f65da5d3c9001a8cbdb96c793d93
6251098b24fe52a6dd2472e98cfccbc4
66e63520d63a000000036208c3142a
1068236a52142fbb7b3ed83d785e12a2
8261bccfb3bcb62a8d2f6d18f5df5f36
52e59c5627d8d9c8f7877c4d7b08e19a
5c363556ba68d392be78b75152dd55ba
0f74d45089e84f77f4492d886524ea6c
82b9f4dd83d46528d4f5c3b51cfeaf28
38d938bd0597c426b0e440434f2c451f
-----END OpenVPN Static key V1-----
</tls-auth>
resolv-retry infinite
nobind
tls-version-min 1.2
cipher AES-256-GCM
auth-user-pass
comp-lzo adaptive
tun-mtu-extra 32
<ca>
-----BEGIN CERTIFICATE-----
MIIEwTCCA6mgAwIBAgIJAKROjebUHo0gMA0GCSqGSIb3DQEBBQUAMIGbMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCRkwxEDAOBgNVBAcTB09ybGFuZG8xETAPBgNVBAoT
CFRvckd1YXJkMQwwCgYDVQQLEwNWUE4xEzARBgNVBAMTClRHLU9WUE4tQ0ExETAP
BgNVBCkTCFRvckd1YXJkMSQwIgYJKoZIhvcNAQkBFhVzeXNhZG1pbkB0b3JndWFy
ZC5uZXQwHhcNMTQwNDE3MTAwOTIzWhcNMjQwNDE0MTAwOTIzWjCBmzELMAkGA1UE
BhMCVVMxCzAJBgNVBAgTAkZMMRAwDgYDVQQHEwdPcmxhbmRvMREwDwYDVQQKEwhU
b3JHdWFyZDEMMAoGA1UECxMDVlBOMRMwEQYDVQQDEwpURy1PVlBOLUNBMREwDwYD
VQQpEwhUb3JHdWFyZDEkMCIGCSqGSIb3DQEJARYVc3lzYWRtaW5AdG9yZ3VhcmQu
bmV00000000NBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAws1hJzlbWKlm3DEO
XyQpmvtxwrsR4CIYMi8C6np5w74lTRYmGBcuuPqAT3ig2DnH9HNNFx1WWZbYO8pU
a1tdn7uYErJi4EP9/t2l3uXCNgoWYVdVP1j5EXIY1oacOv9srbNZHeWpxHIb1wZr
1i4sLsdaifOibgVZI91FATXGrVdFDaQb2OjyJrFW8b4xbC8pBJxQDzqPeu9mkVpu
OhBuU+dM+9h+8Bj0tpdAernEAt8CbHIywe9Rjm0JLrYmCPKuB5ldVgG3rYQWFa3X
YWjrWtr//nGM4f4WKOFc2PHWA2gI3JwdynTNLsB9NQi0N7hhR6lmtCMeqHlm0oAz
4Ad4gQIDAQABo4IBBDCCAQAwHQYDVR0OBBYEFJvAPA1gnlD/majxi+43jL0XDfqQ
MIHQBgNVHSMEgcgwgcWAFJvAPA1gnlD/majxi+43jL0XDfqQoYGhpIGeMIGbMQsw
CQYDVQQGEwJVUzELMAkGA1UECBMCRkwxEDAOBgNVBAcTB09ybGFuZG8xETAPBgNV
BAoTCFRvckd1YXJkMQwwCgYDVQQLEwNWUE4xEzARBgNVBAMTClRHLU9WUE4tQ0Ex
ETAPBgNVBCkTCFRvckd1YXJkMSQwIgYJKoZIhvcNAQkBFhVzeXNhZG1pbkB0b3Jn
dWFyZC5uZXSCCQCkTo3m1B6NIDAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUA
A4IBAQBRG46DnL/8EAPbi/eOQli5WO7lRHYyZJdlLUMlsnwkp6Ul6BMJq8q3UX3z
+pqDf3wzj94y/IpGQgE4l0fgAdwf/C7F533TSwU/vi+5PDWfwD2WmGqVmcmXn6Rp
9Fwr+oryRw8GfsVBLZHTkWF1RZrRAr8hWZhNySGFwSXlEIicvNy+9mlFhk2Nb46w
ioZKc1Lc7/okeXNWHPv6Dlm39TcNBpGX/xNoWBzqs1EtA1ZGvMcQHsKLfi3Nbaab
BYe08KWsfeZA+ih4BZ6y2E+x84NYHRebqijXTtHp35coyXllBL/+LBoZ86hKszEx
F3pjGU0+8NzvdPUbKndhzyPPnHF1
-----END CERTIFICATE-----
</ca>

 

[king006]

I’m also having problems with the VPN Server on 382.2 beta on the 86u. I manually re-entered my VPN Server settings exactly from 380.69 on the 68u. Clients can connect to the VPN and have LAN access but no WAN access. In the router log I see the firewall is dropping all traffic coming from VPN clients to the WAN.

I thought this may have been some configuration issue on my end since I’m both changing routers (68u to 86u) and going from 380.69 to 382.2, but it looks like others are having the same issue.

Thanks for testing! My log:

Dec 31 16:59:40 kernel: DROP IN=tun21 OUT=eth0 SRC=10.8.0.2 DST=17.248.145.211 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53840 DPT=443 SEQ=27694878 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040550010303060101080A2F514E530000000004020000) MARK=0x1
Dec 31 16:59:41 kernel: DROP IN=tun21 OUT=eth0 SRC=10.8.0.2 DST=17.248.145.81 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53852 DPT=443 SEQ=641561706 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040550010303060101080A2F514EE40000000004020000) MARK=0x1
Dec 31 16:59:41 kernel: DROP IN=tun21 OUT=eth0 SRC=10.8.0.2 DST=17.248.145.178 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53856 DPT=443 SEQ=2729921404 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040550010303060101080A2F514EF60000000004020000) MARK=0x1
Dec 31 16:59:41 kernel: DROP IN=tun21 OUT=eth0 SRC=10.8.0.2 DST=46.17.8.50 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53842 DPT=4444 SEQ=2946384967 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040550010303060101080A2F514F900000000004020000) MARK=0x1
Dec 31 16:59:41 kernel: DROP IN=tun21 OUT=eth0 SRC=10.8.0.2 DST=17.248.145.148 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53843 DPT=443 SEQ=1333241793 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040550010303060101080A2F514FA70000000004020000) MARK=0x1
Dec 31 16:59:41 kernel: DROP IN=tun21 OUT=eth0 SRC=10.8.0.2 DST=17.248.145.204 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53853 DPT=443 SEQ=2869663356 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040550010303060101080A2F514FE20000000004020000) MARK=0x1
Dec 31 16:59:41 kernel: DROP IN=tun21 OUT=eth0 SRC=10.8.0.2 DST=17.248.145.105 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53857 DPT=443 SEQ=579857362 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040550010303060101080A2F514FF60000000004020000) MARK=0x1
Dec 31 16:59:41 kernel: DROP IN=tun21 OUT=eth0 SRC=10.8.0.2 DST=17.248.145.149 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53854 DPT=443 SEQ=1608778742 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040550010303060101080A2F5150E10000000004020000) MARK=0x1
Dec 31 16:59:41 kernel: DROP IN=tun21 OUT=eth0 SRC=10.8.0.2 DST=17.248.145.111 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53858 DPT=443 SEQ=2296653628 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040550010303060101080A2F5150F30000000004020000) MARK=0x1
Dec 31 16:59:41 kernel: DROP IN=tun21 OUT=eth0 SRC=10.8.0.2 DST=17.248.145.106 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53844 DPT=443 SEQ=3771742616 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040550010303060101080A2F5151040000000004020000) MARK=0x1
Dec 31 16:59:41 kernel: DROP IN=tun21 OUT=eth0 SRC=10.8.0.2 DST=17.252.43.246 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53850 DPT=443 SEQ=919218667 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040550010303060101080A2F5151880000000004020000) MARK=0x1
Dec 31 16:59:41 kernel: DROP IN=tun21 OUT=eth0 SRC=10.8.0.2 DST=17.248.145.145 LEN=64 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=53851 DPT=443 SEQ=1139133888 ACK=0 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (02040550010303060101080A2F5151CC0000000004020000) MARK=0x1

OVPN Works here as well even with Redirect Internet Traffic = ALL (RT88U). Here is the config file automatically generated by Torguard's ovpn config file tool choosing ASUS firmware:

client
dev tun
proto udp
remote frank.gr.torguardvpnaccess.com 1215
remote-cert-tls server
auth SHA512
key-direction 1
setenv CLIENT_CERT 0
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
770e8de5fc56e0248cc7b5aab56be80d
0e19cbf003c1b3ed68efbaf08613c3a1
a019dac6a4b84f13a6198f73229ffc21
fa512394e288f82aa2cf0180f01fb3eb
1a71e00a077a20f6d7a83633f5b4f47f
27e30617eaf8485dd8c722a8606d56b3
c183f65da5d3c9001a8cbdb96c793d93
6251098b24fe52a6dd2472e98cfccbc4
66e63520d63ade7a0eacc36208c3142a
1068236a52142fbb7b3ed83d785e12a2
8261bccfb3bcb62a8d2f6d18f5df5f36
52e59c5627d8d9c8f7877c4d7b08e19a
5c363556ba68d392be78b75152dd55ba
0f74d45089e84f77f4492d886524ea6c
82b9f4dd83d46528d4f5c3b51cfeaf28
38d938bd0597c426b0e440434f2c451f
-----END OpenVPN Static key V1-----
</tls-auth>
resolv-retry infinite
nobind
tls-version-min 1.2
cipher AES-256-GCM
auth-user-pass
comp-lzo adaptive
tun-mtu-extra 32
<ca>
-----BEGIN CERTIFICATE-----
MIIEwTCCA6mgAwIBAgIJAKROjebUHo0gMA0GCSqGSIb3DQEBBQUAMIGbMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCRkwxEDAOBgNVBAcTB09ybGFuZG8xETAPBgNVBAoT
CFRvckd1YXJkMQwwCgYDVQQLEwNWUE4xEzARBgNVBAMTClRHLU9WUE4tQ0ExETAP
BgNVBCkTCFRvckd1YXJkMSQwIgYJKoZIhvcNAQkBFhVzeXNhZG1pbkB0b3JndWFy
ZC5uZXQwHhcNMTQwNDE3MTAwOTIzWhcNMjQwNDE0MTAwOTIzWjCBmzELMAkGA1UE
BhMCVVMxCzAJBgNVBAgTAkZMMRAwDgYDVQQHEwdPcmxhbmRvMREwDwYDVQQKEwhU
b3JHdWFyZDEMMAoGA1UECxMDVlBOMRMwEQYDVQQDEwpURy1PVlBOLUNBMREwDwYD
VQQpEwhUb3JHdWFyZDEkMCIGCSqGSIb3DQEJARYVc3lzYWRtaW5AdG9yZ3VhcmQu
bmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAws1hJzlbWKlm3DEO
XyQpmvtxwrsR4CIYMi8C6np5w74lTRYmGBcuuPqAT3ig2DnH9HNNFx1WWZbYO8pU
a1tdn7uYErJi4EP9/t2l3uXCNgoWYVdVP1j5EXIY1oacOv9srbNZHeWpxHIb1wZr
1i4sLsdaifOibgVZI91FATXGrVdFDaQb2OjyJrFW8b4xbC8pBJxQDzqPeu9mkVpu
OhBuU+dM+9h+8Bj0tpdAernEAt8CbHIywe9Rjm0JLrYmCPKuB5ldVgG3rYQWFa3X
YWjrWtr//nGM4f4WKOFc2PHWA2gI3JwdynTNLsB9NQi0N7hhR6lmtCMeqHlm0oAz
4Ad4gQIDAQABo4IBBDCCAQAwHQYDVR0OBBYEFJvAPA1gnlD/majxi+43jL0XDfqQ
MIHQBgNVHSMEgcgwgcWAFJvAPA1gnlD/majxi+43jL0XDfqQoYGhpIGeMIGbMQsw
CQYDVQQGEwJVUzELMAkGA1UECBMCRkwxEDAOBgNVBAcTB09ybGFuZG8xETAPBgNV
BAoTCFRvckd1YXJkMQwwCgYDVQQLEwNWUE4xEzARBgNVBAMTClRHLU9WUE4tQ0Ex
ETAPBgNVBCkTCFRvckd1YXJkMSQwIgYJKoZIhvcNAQkBFhVzeXNhZG1pbkB0b3Jn
dWFyZC5uZXSCCQCkTo3m1B6NIDAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUA
A4IBAQBRG46DnL/8EAPbi/eOQli5WO7lRHYyZJdlLUMlsnwkp6Ul6BMJq8q3UX3z
+pqDf3wzj94y/IpGQgE4l0fgAdwf/C7F533TSwU/vi+5PDWfwD2WmGqVmcmXn6Rp
9Fwr+oryRw8GfsVBLZHTkWF1RZrRAr8hWZhNySGFwSXlEIicvNy+9mlFhk2Nb46w
ioZKc1Lc7/okeXNWHPv6Dlm39TcNBpGX/xNoWBzqs1EtA1ZGvMcQHsKLfi3Nbaab
BYe08KWsfeZA+ih4BZ6y2E+x84NYHRebqijXTtHp35coyXllBL/+LBoZ86hKszEx
F3pjGU0+8NzvdPUbKndhzyPPnHF1
-----END CERTIFICATE-----
</ca>

And your VPN settings inside the ASUS router/VPN server?

 

[stoli412]

OVPN Works here as well even with Redirect Internet Traffic = ALL (RT88U). Here is the config file automatically generated by Torguard's ovpn config file tool choosing ASUS firmware:

client
dev tun
proto udp
remote frank.gr.torguardvpnaccess.com 1215
remote-cert-tls server
auth SHA512
key-direction 1
setenv CLIENT_CERT 0
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
770e8de5fc56e0248cc7b5aab56be80d
0e19cbf003c1b3ed68efbaf08613c3a1
a019dac6a4b84f13a6198f73229ffc21
fa512394e288f82aa2cf0180f01fb3eb
1a71e00a077a20f6d7a83633f5b4f47f
27e30617eaf8485dd8c722a8606d56b3
c183f65da5d3c9001a8cbdb96c793d93
6251098b24fe52a6dd2472e98cfccbc4
66e63520d63ade7a0eacc36208c3142a
1068236a52142fbb7b3ed83d785e12a2
8261bccfb3bcb62a8d2f6d18f5df5f36
52e59c5627d8d9c8f7877c4d7b08e19a
5c363556ba68d392be78b75152dd55ba
0f74d45089e84f77f4492d886524ea6c
82b9f4dd83d46528d4f5c3b51cfeaf28
38d938bd0597c426b0e440434f2c451f
-----END OpenVPN Static key V1-----
</tls-auth>
resolv-retry infinite
nobind
tls-version-min 1.2
cipher AES-256-GCM
auth-user-pass
comp-lzo adaptive
tun-mtu-extra 32
<ca>
-----BEGIN CERTIFICATE-----
MIIEwTCCA6mgAwIBAgIJAKROjebUHo0gMA0GCSqGSIb3DQEBBQUAMIGbMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCRkwxEDAOBgNVBAcTB09ybGFuZG8xETAPBgNVBAoT
CFRvckd1YXJkMQwwCgYDVQQLEwNWUE4xEzARBgNVBAMTClRHLU9WUE4tQ0ExETAP
BgNVBCkTCFRvckd1YXJkMSQwIgYJKoZIhvcNAQkBFhVzeXNhZG1pbkB0b3JndWFy
ZC5uZXQwHhcNMTQwNDE3MTAwOTIzWhcNMjQwNDE0MTAwOTIzWjCBmzELMAkGA1UE
BhMCVVMxCzAJBgNVBAgTAkZMMRAwDgYDVQQHEwdPcmxhbmRvMREwDwYDVQQKEwhU
b3JHdWFyZDEMMAoGA1UECxMDVlBOMRMwEQYDVQQDEwpURy1PVlBOLUNBMREwDwYD
VQQpEwhUb3JHdWFyZDEkMCIGCSqGSIb3DQEJARYVc3lzYWRtaW5AdG9yZ3VhcmQu
bmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAws1hJzlbWKlm3DEO
XyQpmvtxwrsR4CIYMi8C6np5w74lTRYmGBcuuPqAT3ig2DnH9HNNFx1WWZbYO8pU
a1tdn7uYErJi4EP9/t2l3uXCNgoWYVdVP1j5EXIY1oacOv9srbNZHeWpxHIb1wZr
1i4sLsdaifOibgVZI91FATXGrVdFDaQb2OjyJrFW8b4xbC8pBJxQDzqPeu9mkVpu
OhBuU+dM+9h+8Bj0tpdAernEAt8CbHIywe9Rjm0JLrYmCPKuB5ldVgG3rYQWFa3X
YWjrWtr//nGM4f4WKOFc2PHWA2gI3JwdynTNLsB9NQi0N7hhR6lmtCMeqHlm0oAz
4Ad4gQIDAQABo4IBBDCCAQAwHQYDVR0OBBYEFJvAPA1gnlD/majxi+43jL0XDfqQ
MIHQBgNVHSMEgcgwgcWAFJvAPA1gnlD/majxi+43jL0XDfqQoYGhpIGeMIGbMQsw
CQYDVQQGEwJVUzELMAkGA1UECBMCRkwxEDAOBgNVBAcTB09ybGFuZG8xETAPBgNV
BAoTCFRvckd1YXJkMQwwCgYDVQQLEwNWUE4xEzARBgNVBAMTClRHLU9WUE4tQ0Ex
ETAPBgNVBCkTCFRvckd1YXJkMSQwIgYJKoZIhvcNAQkBFhVzeXNhZG1pbkB0b3Jn
dWFyZC5uZXSCCQCkTo3m1B6NIDAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUA
A4IBAQBRG46DnL/8EAPbi/eOQli5WO7lRHYyZJdlLUMlsnwkp6Ul6BMJq8q3UX3z
+pqDf3wzj94y/IpGQgE4l0fgAdwf/C7F533TSwU/vi+5PDWfwD2WmGqVmcmXn6Rp
9Fwr+oryRw8GfsVBLZHTkWF1RZrRAr8hWZhNySGFwSXlEIicvNy+9mlFhk2Nb46w
ioZKc1Lc7/okeXNWHPv6Dlm39TcNBpGX/xNoWBzqs1EtA1ZGvMcQHsKLfi3Nbaab
BYe08KWsfeZA+ih4BZ6y2E+x84NYHRebqijXTtHp35coyXllBL/+LBoZ86hKszEx
F3pjGU0+8NzvdPUbKndhzyPPnHF1
-----END CERTIFICATE-----
</ca>

Just to clarify, are we talking about the same thing? I have no issues with the OpenVPN client on the router...that’s working as expected. I’m having issues with the OpenVPN server. If clients connect to the OpenVPN server on my router, they can reach the LAN but not the WAN...the firewall is dropping all the traffic.