Find My Peplink - Use "detected" IP vs. actual WAN interface IP

Hi,

Find my peplink is super helpful, but I have a situation where I’d like to have the option to use the “Incontrol detected IP” vs. the WAN’s actual interface IP. Verizon’s LTE network overloads private IP’s to publicly routable IPs, so the WAN IP on the device is not the same as what the outside world sees.

I’m not trying to use this to get back into my router from this IP, rather I am trying to update a firewall whitelist on a PBX in a Flash (Asterisk) server with the public IP, so that I can allow traffic in from phones behind the Verizon connection. PIAF has a script that will automatically check a defined FQDN to keep an updated whitelist

once we set up the FQDN for a remote user, localdynamic DNS update clients can be used to automate the process of keeping IP addresses current. Then, every few minutes, we’ll let your server check whether there’s been a change in any users’ dynamic IP addresses. If so, we’ll simply refresh the IP addresses of all FQDNs using an IPtables restart to bring the phones back to life.

I’d love if there was a checkbox, or some other way to choose between the interface or the detected IP when enabling Find My Peplink on InControl. This would allow me to create a super simple backup connection over Verizon whenever our wired WAN goes down (and not have to scramble to whitelist IP’s, or do a bunch of tunneling).

Does this sound like something that is doable?


1 Like

This is a very valid request as the entire 100.64.0.0/10 block are actually private addresses that are reserved for service providers using a Carrier-grade NAT

1 Like

Eddy and I also discussed the same topic recently. We will make such enhancement to the Find My Peplink service. It is filed in bug 14705 (https://bugzilla.peplink.com/show_bug.cgi?id=14705). However, the InControl detected IP will be returned only for products with single WAN or only one WAN is used at a time (i.e. BR1, FH, Surf SOHO, APs). It is because if a device has multiple public IPs, the detected IP could change. It is not good for the DNS to “randomly” return only one of the public IPs.

1 Like

Thanks, Michael. I see your point about limiting the scope.

I think the Balance One may be another good candidate, though that may be tricky since it has two WAN’s by default. I can also see this being useful on any router’s USB port. At least for the U.S., that would be highly likely to end up with a private IP. Most carriers here implement a similar NAT strategy to Verizon.

1 Like

In order to support multiple WAN products, we have to modify the firmware to detect all WANs’ public IP and report to IC2. After discussing with Eddy, we agreed to make the change in future firmware releases.

When a device is loaded with future firmware, a WAN’s Find My Peplink address (e.g. wan1.serial-num.mypep.link) will always be its public IP, regardless it is NAT’d or not.

But for the Find My Peplink device address (e.g. serial-num.mypep.link), I am still thinking what should be returned when IC2 knows all WANs’ WAN IP and public IPs. Should all healthy WANs’ public IPs be returned? Or just keep the existing implementation (i.e. only return WAN IPs which are public)?

1 Like

Hi,
I was wondering if wan1.serial-num.mypep.link wan2. Etc ever got implemented?
It would be super useful.
Thanks.
Jonathan

Yes! Just click the Details link on a WAN’s status screen. You will find the WAN’s FMP address.

1 Like

Hi @Michael,
Thats excellent!
I didn’t notice that before, was it on a recent firmware upgrade?

Many thanks,
Jonathan

It is available since FMP was released…

1 Like

I think this is within-topic:
With a multi-WAN device (in this case an HD2) the “InControl Detected IP” by IC is none of the WAN interface IPs (all public) but rather the IP address of a fusionhub instance connecting to the HD2 - which seems messed-up.

I remember a carrier in US applies NAT to devices even though their WAN IP is a public one. So the IC2 detected IP could be different from the WAN’s IP.

1 Like

Not the case in these (two so far) instances - the static IPs are publically adressable (no NAT).

Based on your feedback above, sound like the InControl2’s traffic from HD2 has routed the FusionHub. Hence, FusionHub public IP is detected. Have you enabled Send All Traffic To (Advanced > SpeedFusion) or route all traffic to SpeedFusion tunnel with outbound policy?

1 Like

Please send us its s/n and we will look into it.

1 Like

In short: No :slight_smile:

s/n of the two units exhibiting the issue have been sent to Michael by PM.

[Update:] It may be somewhat random - after rebooting the HD2, IC2 now reports a HughesNet IP address as the “detected IP” (WAN1 of the unit is connected via a satellite link, the cellular connections are via Verizon static IP addresses).

In all cases the xxxx.mypep.link domain name resolves properly, to the two public IP addresses (in these cases, the Verizon static IP addresses).

Thus a secondary question is - does this matter? What is the significance or use of the IC2 “InControl Detected IP” address?

1 Like

It is telling you how and from where the InControl2 detects the device. It shouldn’t affect the FindMyPeplink feature.

1 Like

Does it also identify which IP address IC2 uses to communicate with the device, or is that more dynamically determined?

The communication between device and InControl2 is initiated by the device as below:

Device —UDP 5246—> InControl2

If the UDP 5246 sent from WAN1, then InControl2 will detect the public IP of WAN1. The communication will be going through WAN1.

1 Like

How does the device determine which WAN connection on which to send the UDB 5246? E.g., if there are significantly different characteristics from one WAN to the next?
Case in point: WAN1 being a wired connection to a satellite modem, vs. other WANs being cellular connections.

It is depending on the Outbound Policy you configured.

1 Like