What's new

Need help to configure openVPN server on RT-AX58U with Merlins v. 386.3_0

  • 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!

akbor

Occasional Visitor
Hi,

I just upgraded from my old, hard-boiled RT-AC87U to RT-AX58U with Merlins v. 386.3_0 and cannot get openVPN server working over the WAN side. From my LAN the client connects to the server and everything seems to be normal. But from outside the LAN the client gets no connection.

What I have configured:

[WAN]->[DDNS]:
Code:
Enable the DDNS Client: Yes
DDNS Status: Active
DDNS Registration Result: Registration is successful.
Method to retrieve WAN IP: internal
Server: www.asus.com
Host Name: myname.asuscomm.com
Forced update interval (in days): 21
Webui SSL Certificate: Free Certificate from Let's Encrypt

[VPN]->[VPN server]:
Code:
VPN Server - OpenVPN
Server instance: Server 1
Enable OpenVPN Server : ON
VPN Details: General
Client will use VPN to access: Both (LAN and WAN)
Applied: username / password
VPN Status: OpenVPN Server 1 - Running

I'm not sure if that's necessary, but I also configured a port forwarding for openVPN from the LAN address of my router to the WAN side
[WAN]->[Virtual Server/Port Forwarding]:
Code:
Enable Port Forwarding: ON
Service Name: Open VPN Server
External Port: 1194
Internal Port: -
Internal IP Address: 192.168.1.1
Protocol: UDP
Source IP: -

I exported then an OpenVPN configuration file "client1.ovpn", copied it to my smatrphone, imported it in in the app "OpenVPN connect", entered the username and the password. And I can only connect from LAN, a connection from outside/WAN is not possible, due to a server timeout:

Code:
17:24:32.494 -- ----- OpenVPN Start -----
17:24:32.495 -- EVENT: CORE_THREAD_ACTIVE
17:24:32.501 -- OpenVPN core 3.git:released:662eae9a:Release android arm64 64-bit PT_PROXY
17:24:32.504 -- Frame=512/2048/512 mssfix-ctrl=1250
17:24:32.508 -- UNUSED OPTIONS
4 [resolv-retry] [infinite]
5 [nobind]
7 [ncp-ciphers] [AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC]
17:24:32.510 -- EVENT: RESOLVE
17:24:32.611 -- Contacting 100.64.37.xxx:1194 via UDP
17:24:32.612 -- EVENT: WAIT
17:24:32.619 -- Connecting to [myname.asuscomm.com]:1194 (100.64.37.xxx) via UDPv4
17:24:42.505 -- Server poll timeout, trying next remote entry...
17:24:42.505 -- EVENT: RECONNECTING
17:24:42.510 -- EVENT: RESOLVE
17:24:42.517 -- Contacting 100.64.37.xxx:1194 via UDP
17:24:42.519 -- EVENT: WAIT
17:24:42.525 -- Connecting to [myname.asuscomm.com]:1194 (100.64.37.xxx) via UDPv4

I think, exactly these settings (maybe without a port forwarding, I'm not sure) were working on my old router since years and I was happy.

I see, that my DDNS name was resolved correctly, the WAN IP is correct, but the openVPN server doesn't answer over the WAN/Internet. Did I configured wrong port forwarding settings? Do I something else wrong? Could anyone help please?

Best regards
 
Last edited:
The OpenVPN server does NOT require port forwarding of any kind. It will simply open the requested port on the WAN once the OpenVPN server process is started.

Are you sure the WAN ip is a *public* IP and NOT a private IP (including CGNAT)?

P.S. Just noticed "100.64.37.xxx" in the log, which is CGNAT (i.e., a private IP)! You can NOT remotely access a private IP.
 
The OpenVPN server does NOT require port forwarding of any kind.
Thanks, then I remember correct, that I didn't configure any port forwarding rule at my old router. I deleted the rule, even if it isn't the reason of my problem.
Are you sure the WAN ip is a *public* IP and NOT a private IP (including CGNAT)?

P.S. Just noticed "100.64.37.xxx" in the log, which is CGNAT (i.e., a private IP)! You can NOT remotely access a private IP.
Damn, you are right. But on my old router openVPN connections from outside worked on this way. Why? Or did it just overlap so stupid, that my ISP changed the WAN adresses from public space to CGNAT (even didn't knew this term, had to google) and I upgraded the router +/- at the same time without to check that openVPN doen't work anymore? :rolleyes: Can this problem be solved, or I cannot run any kind of server with access from the Internet in my local network (FTP, VPN, etc.) anymore? I gues, I have to contact my ISP with this issue? I am very curious on their answer.
 
Last edited:
Your ISP may be using a mixture of public and CGNAT addresses. If you clone the WAN MAC address of your old router onto your new one (WAN - Internet Connection) you may be able to get your old public IP address back.

Otherwise you'll need to speak to your ISP and ask them to assign a public IP address to you.
 
Just tried to clone the MAC from my old RT-AC87U. I got a new IP (my ISP is a TV cable provider, I get usually the same IP) but from the same 100.64.37.xxx range :( Probably I should have done it immediately after the router change, a week has passed since that :( So I have no other choice than to contact my ISP...
 
One more stupid question: if there is no way to connect to a server running in the LAN from WAN/Internet over the CGNAT, how do my apps for Yeelight, Roborock and so on bypass this NAT, or rather resolve the correct IP?
 
I don't know anything about Yeelight or Roborock but typically IoT devices will use a cloud server as a proxy for the connection. So you're not actually connecting directly to the IoT device.
 
OK, thanks, have just contacted my ISP, asked for possibility to give me back my old public address, or to make some port forwarding rule for my openVPN server in their NAT.

Update 02.08.2021: today I've got a call from the ISP, I should check the settings. I just looked up and my router reports now another IP from a public range (185.35.211.xxx) and I can connect to my openVPN server from outside of my LAN. So I have to admit, I wronged my ISP with my previous statements. But I've never had such a suitable reaction and so quickly, I honestly have to admit that. Probably the ticket went to exactly the right person. :eek:
 
Last edited:

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top