@jra11500 

Thank you for your reply!

I did a quick test. I do have Wireguard set up, and it's working. For Wireguard, I did have port forwarding for port 51820 to ER605. It works either with or without that port forward. So, it seems like you are right.

However, for OpenVPN, I still cannot connect after disabling the port forwarding.

Just FYI, while I do have many other VPN options working already, this is just bugging me. It seems so simple, yet it's not working.

Regards,

Tim

  @Tim_Tang 

You don't need port forwarding at any time, regardless of whether your WAN IP is public or not. 

The OVPN will automatically open the port once you have configured the OVPN server on the Omada routers. 

I assume it would be a problem with your network environment. 

 Hi @Clive_A 

While you did not explicitly say it, you gave me a clue when you said OPVN will "automatically open the port". I suspected that when I created the OPVN configuration, I had my NAT forwarding enabled; hence, ER605 could not automatically open the port properly.

So, I deleted my ACL and OPVN configuration. Then, I created OPVN from scratch with the NAT port forwarding disabled. It worked. BUT there's more to the story!!

If I change the OPVN configuration to an unreachable DNS server, obviously, it stops working. But even when I tried to change the configuration back to the original working DNS address and generate a new .opvn profile, it refused to connect. I need to delete the OPVN configuration and start from scratch to get it working.

It seems that once OPVN server fails to connect, it will never establish connections, no matter how you change the configuration. You must delete and start from the top. AND there's more...

After creating a working new OPVN configuration, if I update the server IP address with hostname in the .opvn profile before import into the client, it will have a "Connection Lost" error. However, if I import the .opvn profile with the raw server IP address, it will connect. Only after making the initial connection, then I can modify the .opvn profile to hostname and re-import the profile. Now the client will use the hostname instead of a fixed IP address.

It seems that the OPVN configurations are very finicky. 

Just FYI, I always modify the .opvn profile to change the comp-lzo to adaptive as recommended by https://community.tp-link.com/en/business/forum/topic/653224

I did not try leaving at the default "no". 

Regards,

Tim

 Hi @Clive_A 

In my excitement about making progress, I forgot to mention something that's really important:

Thank you!!!

Tim

  @Tim_Tang 

Tim_Tang wrote

 Hi @Clive_A 

 

Regarding my unreachable DNS that's causing the Server Poll timeout, I'm using a Pi-Hole DNS server in my internal network. I like the VPN traffic to go through the Pi-Hole DNS. However, if I set the OPVN configuration on ER605 to point to the internal DNS server, I get a Server Poll timeout. I need to set the OPVN's DNS configuration to an external DNS address.

 

Currently, I have set my main internal LAN interface on ER605 to point to my internal Pi-Hole DNS server. So, all internal clients pointing to ER605 as their DNS server will get directed to my Pi-Hole DNS server. My questions are:

 

1) With OPVN's DNS set to an external DNS, will the OPVN traffic use my internal DNS because of my LAN interface setting? OR will it use the external DNS defined by the OPVN server?

 

2) Can I use dhcp-option [pi-hole-ip-address] in the .opvn profile? Will ER605's OPVN server recognize this option in the profile?

 

3) If neither of the above options works, are there any other ways to set ER605's OPVN server to route traffic using internal DNS?

 

Regards,

Tim

 

1. This might be a limitation with the OVPN. You can contact the OVPN team regarding that. It is not a problem with the Omada gears. I am pretty sure WireGuard can use the local DNS. I am using WG instead of VPN now, and I have set the DNS to my local DNS server.

2. Internal(LAN) DHCP has nothing to do with the VPN interface.

3. I don't think there is a way. You can contact the OVPN team regarding this.

  @Tim_Tang Hi,

I had the same problem when using the ER605 as a downlink behind a NAT device.

From my experience: when I set up an Asus router as the VPN router with the same configuration as the ER605, the OpenVPN handshake failed. The reason was that return traffic to the VPN client couldn’t find the correct path back.

The solution is to add a manual route. For example, configure a static route so that traffic to the public IP of your OpenVPN client goes back through your upstream gateway (e.g., 192.168.1.1). Without this, the route is altered by the NAT device, and the response cannot reach the client.