Using VPN and local LAN netowork IP versus out and about WAN/LAN IP

[Holbs]

I use the Ubiquiti UDM router for it's enhanced network options.
I also use the onboard Teleport VPN (I believe built upon the newer Wireguard VPN service) that is built into the Ubiquiti UDM which I set up as 192.168.4.xxx network.
When I am in my local LAN at home, I do not use the VPN. My smartphone autoconnects to the primary LAN IP of 192.168.1.xxx
When I am mobile while driving or grocery shoppping, I am on the cellular network and my Teleport VPN works great.
However, when I am at work WiFi, the VPN gets....angry at me or something and doesn't like to connect. We also use 192.168.1.xxx at work.

Maybe this is my confusion about using local LAN VPN server. Or maybe it's an Ubiquiti Teleport way of doing things. When on cellular network, I check my UDM client list and my smartphone's IP address is not 192.168.4.xxx of the VPN network subnet but rather 192.168.1.xxx of the main subnet. I assume, when outside of local network on someone's local WiFi (starbucks, my work, other people's work office), it's a possible IP network conflict because both local and work WiFi networks could be using the same 192.168.1.xxx

I do not understand why the smartphone always lands on the 192.168.1.xxx instead of the VPN subnet of 192.168.4.xxx
Is this just how VPN works?
If so...what is the resolution? Change my IP address range at home to 10.10.xxx.xxx ?
Trying to remember what customers do when using VPN at work with remote locations. They do use increasing numerical values for every site. Example: main=192.168.10.xxx while remote1=192.168.20.xxx and remote 2=192.168.30.xxx

 

[tech_junkie]

I use the Ubiquiti UDM router for it's enhanced network options.
I also use the onboard Teleport VPN (I believe built upon the newer Wireguard VPN service) that is built into the Ubiquiti UDM which I set up as 192.168.4.xxx network.
When I am in my local LAN at home, I do not use the VPN. My smartphone autoconnects to the primary LAN IP of 192.168.1.xxx
When I am mobile while driving or grocery shoppping, I am on the cellular network and my Teleport VPN works great.
However, when I am at work WiFi, the VPN gets....angry at me or something and doesn't like to connect. We also use 192.168.1.xxx at work.

Maybe this is my confusion about using local LAN VPN server. Or maybe it's an Ubiquiti Teleport way of doing things. When on cellular network, I check my UDM client list and my smartphone's IP address is not 192.168.4.xxx of the VPN network subnet but rather 192.168.1.xxx of the main subnet. I assume, when outside of local network on someone's local WiFi (starbucks, my work, other people's work office), it's a possible IP network conflict because both local and work WiFi networks could be using the same 192.168.1.xxx

I do not understand why the smartphone always lands on the 192.168.1.xxx instead of the VPN subnet of 192.168.4.xxx
Is this just how VPN works?
If so...what is the resolution? Change my IP address range at home to 10.10.xxx.xxx ?
Trying to remember what customers do when using VPN at work with remote locations. They do use increasing numerical values for every site. Example: main=192.168.10.xxx while remote1=192.168.20.xxx and remote 2=192.168.30.xxx

Ok, this type of VPN has similar pitfalls that were encountered in ipv10 (still in testing) which it doesn't check the client's current subnets before assigning the ip4 address that might cause a network conflict as it will show on the device's arp table on it. Your best solution is to use a different ip pool that will not cause a conflict in the client's arp table (your phone) when its connected to a wifi network (that might have the same networking pool).

So the short answer solution will be changing your networking at your router to something they are not using, or exactly the same. but in reality, these connection type naturally assumes the network is at xxx.xxx.1.xxx.
So if you change the network ip address to 192.168.1.x going to map to the 1024 bit offset and assign it a 192.168.3.x address. When you assigned the 192.168.4 network, The bit offset creates vpn connections at 192.168.1.x with a subnet of 255.255.255.255 If the client connected to a network with the same net scheme as the vpn ip, the client machine inherts 255.255.255.255 subnet on all net ip of the same. Since 255.255.255.255 is one ip only the other ip address already assigned by wifi is not net-workable when the subnet is inherited. This is why you encountered this issue.

 

[TonyR]

If so...what is the resolution? Change my IP address range at home to 10.10.xxx.xxx ?

Yep, I'd try that.....

 

[tech_junkie]

I would recommend 10.10.1.xxx so your network base address pool will interpret correctly in the Teleport software. If you don't use 192.168.1.xxx

 

[SpacemanSpiff]

Similar content over here

 

[bp2008]

I do not understand why the smartphone always lands on the 192.168.1.xxx instead of the VPN subnet of 192.168.4.xxx

Depends on the configuration really. Most VPNs in my experience assign an address from their own little subnet and just do some routing to make the traffic work. But I guess Teleport VPN may be doing a lower level transparent bridge or something.

Anyway, your problem is what you suspected. If your phone's ipv4 address at the remote location is in the same subnet as you use at home, it will not know how to route traffic correctly to reach your home IPs. Your home's subnet should be changed to something you are unlikely to encounter anywhere else. 10.10.1.x is probably fine

The first post by @tech_junkie there is mostly over my head, lol. Maybe this bit offset thing is something weird that only the Teleport VPN does? I've never used that VPN.

 

[tech_junkie]

The first post by @tech_junkie there is mostly over my head, lol. Maybe this bit offset thing is something weird that only the Teleport VPN does? I've never used that VPN.

Its typically not implemented. But Ubiquiti's Teleport seems to be using a form of ipv10, and one of its issues does exactly what the OP's malfunction does. They should change their software so VPN VLAN can be manually configured or configured as a fallback when VPN ipv10 auto VLAN causes a conflict.

 

[Holbs]

Its typically not implemented. But Ubiquiti's Teleport seems to be using a form of ipv10, and one of its issues does exactly what the OP's malfunction does. They should change their software so VPN VLAN can be manually configured or configured as a fallback when VPN ipv10 auto VLAN causes a conflict.

so I should upgrade to ipv11 on Google Play? just kidding
that previous posting is what I read before. I was just confused if it was VPN in general or specific to Teleport VPN that I have VPN set for 192.168.4.xxx but actually lands on 192.168.1.xxx . I thought having VPN on it's own subnet would suffice from any IP conflict. So.... I can not use any 192.168.xxx.xxx for the VPN subnet as due to either Ubiquiti Teleport VPN or the use of ipv10 will cause conflict between main & remote sites.
I've been meaning to totally revamp my home network setup anyways.... 10.10.xxx.xxx here I come!

 

[tech_junkie]

so I should upgrade to ipv11 on Google Play? just kidding
that previous posting is what I read before. I was just confused if it was VPN in general or specific to Teleport VPN that I have VPN set for 192.168.4.xxx but actually lands on 192.168.1.xxx . I thought having VPN on it's own subnet would suffice from any IP conflict. So.... I can not use any 192.168.xxx.xxx for the VPN subnet as due to either Ubiquiti Teleport VPN or the use of ipv10 will cause conflict between main & remote sites.
I've been meaning to totally revamp my home network setup anyways.... 10.10.xxx.xxx here I come!

The problem is specific to teleport. If you had originally assigned your network as 192.168.1.xxx you would have never knew of this auto alias conflict. Because the VPN ip would be 192.168.2.xxx (for IPV4 auto VLANrules) or 192.168.3.xxx (IPV10 auto VLAN rules) depending on layer negotiation used in the vpn software.


But at the same token, if you actually went to a class on devices that assign Auto VLANs, they will tell you to set up networking at xxx.xxx.1.xxx so auto VLAN assigns networks without conflicts.

 

[Holbs]

So it is specific to teleport vpn. Good to know. While the teleport VPN is very easy to set up I know I am going through either teleport cloud or ubiquiti cloud, which I'm not exactly thrilled with. One day, I could see building my own wireguard VPN server via home assistant or such and skip the cloud all together. But for now with how busy everything is going on I will stick with teleport VPN. @tech_junkie don't you ever go anywhere because you have really a Fountain of Knowledge that could be rather useful here

 

[JNDATHP]

Are you sure that the UDM Pro native VPN uses the cloud?

On our USG, it is a straight shot from our mobile devices to the USG using the WAN IP or, in our case, a domain name with Dynu that refreshes the domain name’s public IP.

 

[Holbs]

Are you sure that the UDM Pro native VPN uses the cloud?

On our USG, it is a straight shot from our mobile devices to the USG using the WAN IP or, in our case, a domain name with Dynu that refreshes the domain name’s public IP.

I thought the built-in Teleport VPN was only available on the UDM series routers?

 

[tech_junkie]

I thought the built-in Teleport VPN was only available on the UDM series routers?

Hardware:
A Dream Machine or Dream Machine Pro running 1.12.0 or later.
A Dream Router or Dream Machine Pro Special Edition running 2.4.0 or later.
firmware:
Running UniFi Network version 7.1 or later.

Otherwise, you have to use a static or ddns like the older ones.

 

[The Automation Guy]

As a non-professional IT person, it is my understanding that you definitely need unique IP ranges for the local network, the network you are connecting from, and the tunnel network of the VPN. Because your work and home networks both use the same address schemes, you are likely experiencing issues due to this.

Although it is not going to be fun, I think the best solution is to change your home IP address scheme to something else that isn't shared with your work network.

 

[Holbs]

I tried 1.2.3.4 for home network and it now evetything works!
kidding

 

[SpacemanSpiff]

I tried 1.2.3.4 for home network and it now evetything works!
kidding

Well THAT'S some advice I can count on!!

 

[tech_junkie]

As a non-professional IT person, it is my understanding that you definitely need unique IP ranges for the local network, the network you are connecting from, and the tunnel network of the VPN. Because your work and home networks both use the same address schemes, you are likely experiencing issues due to this.

Although it is not going to be fun, I think the best solution is to change your home IP address scheme to something else that isn't shared with your work network.

well the issue is the op didn't start the network's address at the subnet of 192.168.1.xxx like you suppose to do on auto vlan systems. The VPN's auto vlan picks the first available net after xxx.xxx.0.xxx which in the OP's case, assigns it the same ip scheme in the remote network causing a conflict. You don't set up different ip network schemes for the locations on client only VPNs, just network tunnels.

BTW, he should have solved this by now.

 

[tech_junkie]

So it is specific to teleport vpn. Good to know. While the teleport VPN is very easy to set up I know I am going through either teleport cloud or ubiquiti cloud, which I'm not exactly thrilled with. One day, I could see building my own wireguard VPN server via home assistant or such and skip the cloud all together. But for now with how busy everything is going on I will stick with teleport VPN. @tech_junkie don't you ever go anywhere because you have really a Fountain of Knowledge that could be rather useful here

Thanks.
The advantage of the Teleport VPN is it manages and changes certs often (per remote session I believe) with its own cert signing server system. So it runs SSL like it was supposed to be ran back when it was first conceived. Originally, SSL certs were suppose to change at every cookie session. But back then, the people who thought its entropy was good for a few years at least, so they went that route with it.

 

[SpacemanSpiff]

Thanks.
The advantage of the Teleport VPN is it manages and changes certs often (per remote session I believe) with its own cert signing server system. So it runs SSL like it was supposed to be ran back when it was first conceived. Originally, SSL certs were suppose to change at every cookie session. But back then, the people who thought its entropy was good for a few years at least, so they went that route with it.

Ahh yes.... systems suddenly become inaccessible, frenzied diagnostics ensue to quickly restore access, it seems like days go by while trying to isolate the issue. Then, within an hour of the first report, you find out the self signed certificate you generated 12 years ago expired, generate another certificate good for 15 years and vow that you'll remember the 'next time'.

Good times... good times

 

[tech_junkie]

Ahh yes.... systems suddenly become inaccessible, frenzied diagnostics ensue to quickly restore access, it seems like days go by while trying to isolate the issue. Then, within an hour of the first report, you find out the self signed certificate you generated 12 years ago expired, generate another certificate good for 15 years and vow that you'll remember the 'next time'.

Good times... good times

It sucks that the devices are littered with these self signed SSL.
Because the SSL system wasn't originally designed to be self signed, and was suppose to be limited to a limited time or the user's session.
At lease the teleport uses session based CA certs by its own 3rd party signing server. Which I'm impressed that someone actually is using SSL correctly with their hardware (for a change).