Trying to set up a failover RDP access [DDNS]

Hello,

Looking for help setting up the RDP access to a single server.

The way it was set up prior to adding the cellular wan was that remote user would just type in the static IP of the Comcast interface and with port forwarding access the desktop of the server.
Now, with the addition of T-Mobile cell wan as failover option, is there a way that I can have them accessing the same server when primary is not available. They would not know that they need to use a secondary static IP address.
Sorry about such a rookie question :slight_smile: and thank you in advance for any help!!!

One simple way to set this up would be to register a DNS/DDNS record for both the primary and backup connections and instruct your users…

Something like:
rdp-primary.domainname.com = comcast
rdp-backup.domainname.com = tmobile

If your connections are setup as Active / Standby, that should keep users from connecting to cellular while the primary is available.

Some sort of external health checking service(like a load balancer) would be required to automatically update a DNS record between two values.

I agree with erickufrin about having two DDNS names, one for each WAN connection. However, first check, using the cellular public IP address, that it works at all. I say this because you may find that the cell connection is not as simple as a cable connection.

Thank you to both of you.

Does the issue with cell go away over static IP or it doesn’t matter?

I have raised this issue with peplink several times, in several ways but made no progress.
My view of this is that the DDNS feature of the peplinks is fundamentally flawed. Not “broken”, but doing the wrong thing correctly.
Core issue is that if you set up the same ddns name on wan and cell, and you have both wan and cell active then it is random which one reports at any given moment.
Also, it tends to get stuck - take wan up and down five or six times and it may be reporting the wrong wan. i.e. wan is down, cell is up, ddns is reporting WAN ip
My request was to be able to set up one ddns not on on wan and cellular, but on the device.
Part of this setup would be to prioritize the wans.
Example:
store1234.dyndns.org
WAN pri 1
CELL pri 2

so - if wan is up, cell is standby then it reports WAN public IP
If wan is down and cell is up it reports cell public ip
if wan and cell is up then it reports WAN IP (because that is what I want)
Since it does not work this way we use the findmypeplink host name in incontrol as a substitute.
It is not perfect, particularly if you have both wan and cell active, but it is far more reliable. Give that a try

Using two different DDNS names defeats the entire purpose of DDNS for a multi wan device. you WANT to have one name properly resolving to the correct wan public IP.

@jmpfas For the issues you outlined above was the reason why I suggested multiple DDNS – because unpredictability/unreliability of when DDNS gets updated could lead to meany support calls.

@sadamsky - having a static IP address on your cellular connection will be required for the inbound port-forward to function. Yes. Its helps to have static public IP.

Often times cellular networks use 10.x.x.x network for cellular IP’s which are not publicly routable.

Welcome to the forum!

My preferred way to do this is with PepVPN. I host a free fusionhub appliance in Vultr.com (vultr costs $5/month), that gives me a public static IP. Then i port forward from that IP to the internal service (normally CCTV on buses or public use vehicles in my case) over PepVPN back to the LAN IP of the device connected to the Peplink router.

That way, no matter what WAN link is actually up and available on the Peplink, the remote users all connect to the same IP. Then I point a custom dns name/entry at that IP to make it easier to remember (like bus211-cameras.mydomainname.com).

2 Likes

Yes, this has been the subject of numerous requests, dating back at least six years …





Why not remove the DDNS settings from the WAN pages and move it to Network --> Misc. Settings. Then, allow the user to set parameters as to how the DDNS update message(s) should be sent.

Addressing the stated issue raised by @sadamsky I’m going to take the liberty of moving this thread to Feature Requests.

Maybe we can get one of the nice folks @ Peplink to take the initiative to move this forward? (Note: We are not talking about inbound load balancing here – just simple DDNS updates based on specified criteria. And sometimes IC2 is simply not an option.)

I personally like (and use) the fusionhub strategy. I also like simplicity and saving money

In the absence of a fusionhub with a public IP and a forwarding set-up, here’s (just) a thought:

  1. IC2 provides a DDNS service (e.g., one of our routers, a BR1, is known as something like xxxx.mypep.link). The active interface that IC2 is connected to is known as ic2-detected.xxxx.mypep.link. Its associated address is maintained by IC2, and keeps resolving to the current IP address (the TTL for the resolution is a short period). When the primary interface changes, so does the resolution of the FQDN ic2-detected.xxxx.mypep.link.

  2. This happens without any reboot or other DDNS setup requirement. I have tested it once on a BR1 just now, flipping between the two SIM cards, and employ it generally for a bunch of routers with changeable IP addresses. But in our cases we don’t care which interface a connection arrives at, as long as it arrives at some interface :slight_smile:

  3. As long as the IC2 connection is direct (not via a VPN or the like where the breakout IP address would be the one picked up by IC2) and is from a routable IP address the IC2-provided FQDN could satisfy your needs: it would resolve to the active interface. Then use CNAME records to bring it within your own domain naming scheme.

  4. If you have multiple active interfaces then you can employ an outbound rule to prioritize which interface the IC2 registration connections will employ (UDP on port 5246), and if the first fails then it will drop to the next one. We use that strategy to ensure that the IC2 connection does not fall prey to default routing across VPNs (which is how some of the equipment is set up).

As I said - just a thought (I have not employed this in any critical setting).

Cheers,

Z

1 Like

thank you all for your valuable recommendations