Non aviation content. Play nice – No religion, no politics and no axe grinding please.
By Colonel Panic
#1741986
Thanks both; I'll recheck things tomorrow when I go out - frustratingly 3G coverage here is so poor that I can't even hot-spot off my phone.

My LAN is 192.168.2.1-254, with the USG in charge of DHCP within 100-254. Most "resident" devices have been allocated specific IPs in the range 1-99; 1-19=Unifi, 20-39=Apple, 50-59= RaspberryPi stuff, 60-69=cctv etc etc. The hope is that this will make the creation of VLANs easier when & if I ever get around to trying to set them up ...
By Colonel Panic
#1742713
#manycappucinoslater I can access my home network via a VPN on my iOS device (when connected to public wifi or via 4G), but I can't with my laptop. This suggests that the VPN settings within the USG are correct (or nearly so), but within SysPref/Network/VPN I have made an error. Can anyone see anything wrong with the screenshots below?

TIA


Image


Image


Image


Image


Image
User avatar
By stevelup
#1742718
When you initially set up the VPN, you are asked what type (you can choose L2TP over IPSEC, Cisco IPSEC or IKEv2) - did what you chose there match the config on the USG?
By Colonel Panic
#1742722
I chose L2TP; these are the three screens the video tutorials showed I needed to set up.

Is it still a case of the error being subnet related? My LAN is 192.168.2.x, with DHCP on 192.168.2.100-254.

Image


Image


Image
User avatar
By stevelup
#1742724
You've got your credentials / secret the right way round?

The password for JJB_VPN in the top box, and the shared secret in the bottom box?
By rjc101
#1742726
If you can connect, but not actually get to your LAN via the VPN.... In the VPN setup on the Mac, click advanced, first page and tick the "send all traffic over the VPN connection".

You can tweak the USG to not need this to happen, by allocating the IP range issued by the VPN to be within the LAN IP range, but it's a faff. The GUI doesn't let you, so you need to create a file to apply the setting manually. I have to do that to route specific traffic out of one of connections.
Colonel Panic liked this
By Colonel Panic
#1742728
I'm happy that I have the passwords the right way around, yes. I forgot to mention that when the laptop connects to/via the VPN (which it does), the IP shown in SysPref/Network/VPN is 192.168.3.1 - so that bit looks right ... It is just I can't then access anything, whether that be internal (192.16.8.2.50) or external (forums.flyer.co.uk).
User avatar
By JonathanB
#1742752
Hmmm, must look at sorting out a VPN on my USG... :)

(Although I can SSH in to a RPi at the moment anyway and am playing with Docker/Traefik)
Colonel Panic liked this
By Colonel Panic
#1745907
Could I just clarify a very basic aspect of VPNs?

My LAN is 192.168.2.1-254, and my VLN provided addresses are in the range 192.168.3.1-6 . My VPN starts up and connects (& allocates me 192.168.3.1), but I can't then access anything.

If, say, a NAS or a RaspberryPi is at 192.168.2.90, when the VPN connects (with me then being on 192.168.3.1) do I just type 192.168.2.90 into the address bar, or do I have to add a :something to that address? Also, do devices on the LAN's 2.x subnet need to be "told" to accept communications to/from the 3.x subnet? I ask because I haven't done so for anything yet - nor know how that would be done.

I had thought / assumed (dangerous, I know), that once connected I could then access anything on the LAN as if I were physically on the LAN ...
User avatar
By stevelup
#1745912
It is certainly creating a complication having your VPN in a separate subnet.

I've never used USG for this purpose though so can't give any specific advice.

But yes, ultimately, the USG needs to know that you want to allow traffic from one net to another. But more importantly, the VPN tunnel needs to know that the 192.168.2.x stuff should be tunnelled in the first place. Otherwise your remote devices won't even try and shove stuff for 192.168.2.x down the tunnel in the first place.

Do you know how you ended up with the VPN stuff in a separate network? It would be a lot easier if your VPN just connected you with a 192.168.2.x address.
User avatar
By stevelup
#1745913
The USG document says 'L2TP doesn't have a route distribution method. If the setting on the client device to route "all" traffic through the tunnel is not enabled, it will be necessary to add the manual routes on the client, to point to the USG's local networks. Search in each specific client device's documentation on how to enable sending all traffic over the VPN connection.'
By rjc101
#1745914
The UniFi GUI won't allow the VPN IP client pool be in the main subnet, you can however get round that by creating a config file - I do this to route specific traffic out of my backup broadband connection with a config.gateway.json file on the UniFi controller to make it sticky if the USG reboots.

The alternative is to tell the client to send all traffic over the VPN - then when it hits the USG it is routed correctly and everything works fine.
By Colonel Panic
#1745921
My LAN is 192.168.2.1-254, with DHCP on 192.168.2.100-254 . That works fine.

In all of the "how to" blogs/videos I have seen, they seem to suggest that the VPN should be on a different subnet - but I have never understood why.

I have just tried changing DHCP to 192.168.2.110-254, and setting the VPN range to 192.168.2.100/29 (which then says it would allocate 192.168.2.97 - 192.168.2.102 ) but it comes back with an error saying
"There was an error saving the USG_VPN [which is my chosen VPN name] network. IP/Subnet overlaps with 192.168.2.1/24 defined in LAN"
which confused me ... partly because there has never been anything assigned to .97 - .102 in the look up table (so no chance of a conflict)
By Colonel Panic
#1745924
rjc101 wrote:The UniFi GUI won't allow the VPN IP client pool be in the main subnet, you can however get round that by creating a config file - I do this to route specific traffic out of my backup broadband connection with a config.gateway.json file on the UniFi controller to make it sticky if the USG reboots.

Hmmm, sounds scary :shock:

The alternative is to tell the client to send all traffic over the VPN - then when it hits the USG it is routed correctly and everything works fine.

I thought I had done this - see below?

Image