OpenVPN vs. Client LAN
-
Hi all,
like others, I have problems accessing the Clients in pfSense's LAN after connecting via OpenSSH. However I fear that the solution to my problem is much easier than the one to the problems others have encountered. I'm pretty new to this stuff so please bare with me :)
I set up OpenVPN as a replacement for L2TP/IPSec which (like others) I couldn't get working. I did everything as described in the tutorial in the docs and can connect without problems.
The OpenVPN configuration is:
VPN Network: 192.168.2.0/24
Local Network: 192.168.1.0/24Pfsense is 192.168.1.1 and the clients I want to reach are in 192.168.1.0/24 as well.
Now, after connecting, I have a new network adapter with the IP 192.168.2.6 and gateway 192.168.2.5. All well. However as my OpenSSH Client Laptop is also in a LAN using the subnet 192.168.1.0/24, when I enter 192.168.1.1 (trying to reach pfSense for example) I obviously get the page of my Home router instead of pfSense.
So there is some kind of conflict that I need to resolve. Is the only way to do this to change for example the pfSense LAN to 192.168.3.1/24 ?
Thanks for any help you can provide.
-
Is the only way to do this to change for example the pfSense LAN to 192.168.1.3/24 ?
192.168.1.3/24 is still the same subnet like 192.168.1.0/24.
-
whups sorry, twister, ofc I meant 192.168.3.1/24
-
Yes, choose another piece of private address space for pfSense LAN.
Anybody who installs a system that has any chance of ever needing remote VPN connections coming in, should use "random" bits of private address space for their LANs…
In fact, even if you are not going to have VPN coming in, you might want to do VPN out from a client on your pfSense LAN to someone else who has a "default" LAN on 192.168.1.0/24 or 192.168.0.0/24... so you also want to have picked different private address space.
There has to be some installation default, but IMHO 99% of people should change it.10.x.y.0/24
172.[16-31].y.0/24
are options away from any of 192.168.. -
Thanks for the answers and sorry for the late reply:
I divided the class C subnet into 2 subnets, Home-LANs (192.168.0.0 - 192.168.127.254) and Server-LANs (192.168.128.0 - 192.168.254.254).
Certainly not the best solution for big cooperate VPNs, however sufficient and comfortable for my case.ADIT: Another solution would be to use "dirty NAS tricks" as described here:
http://www.nimlabs.org/dirtynat.html
http://serverfault.com/questions/548888/connecting-to-a-remote-server-through-a-vpn-when-the-local-network-subnet-addresHowever I still don't have access to Server-Side LAN clients when connected via OpenVPN. I'm going to investigate / research this further.
In the mean time If you have any hints, please let me know.Regards
-
I divided the class C subnet into 2 subnets, Home-LANs (192.168.0.0 - 192.168.127.254) and Server-LANs (192.168.128.0 - 192.168.254.254).
How many hosts are you having and realistically expecting to have in each of those two subnets :o ???
-
How many hosts are you having and realistically expecting to have in each of those two subnets :o ???
Well each LAN won't need need more than a /24 subnet (i.e. in this case the Home-LAN clients will all be in 192.168.1.0/24 and the Server-LAN clients will be in 192.168.128.0/24)
But I thought it would be nice to split the Class C Subnet exactly in half.
I also added a few Links for a Dirty NAS Tricks workaround in my previous post.
-
I divided the class C subnet into 2 subnets, Home-LANs (192.168.0.0 - 192.168.127.254) and Server-LANs (192.168.128.0 - 192.168.254.254).
There is no such thing any more as class A,B.C stuff. You can split your subnets at whatever CIDR bit count you like. According to the addresses you have typed, it seems you have split the whole of 192.168.0.0/16 into 2 /17 pieces.
That is (128*256)-2=32766 clients in each subnet.
That should be enough for any reasonable corporate subnet! If you have anywhere near that many clients in the same layer 2 broadcast domain, it is going to be swamped with the broadcast traffic.Maybe you don't realise the numbers you have put in?
And that has not got you away from 192.168.0.0/24 and 192.168.1.0/24
If you really want private subnets with lots of addresses then go to 10 or 172 networks, like:
10.42.0.0/16
10.43.0.0/16 -
Well each LAN won't need need more than a /24 subnet (i.e. in this case the Home-LAN clients will all be in 192.168.1.0/24 and the Server-LAN clients will be in 192.168.128.0/24)
Yes… So, instead you have basically killed OpenVPN for any client that needs to connect remotely from 192.168/16 subnet.
-
According to the addresses you have typed, it seems you have split the whole of 192.168.0.0/16 into 2 /17 pieces.
That is (128*256)-2=32766 clients in each subnet.
That should be enough for any reasonable corporate subnet! If you have anywhere near that many clients in the same layer 2 broadcast domain, it is going to be swamped with the broadcast traffic.Maybe you don't realise the numbers you have put in?
And that has not got you away from 192.168.0.0/24 and 192.168.1.0/24
If you really want private subnets with lots of addresses then go to 10 or 172 networks, like:
10.42.0.0/16
10.43.0.0/16huh?^^ Yea that's exactly what I did, and I'm totally happy with it^^ as you guys said correctly, VPN doesn't allow the Clients and the Servers subnet to be the same, so you recommended to move the Servers LAN to a different subnet.
All I said that is that, from all the possible subnets I could have assigned for the server LAN, I chose to split the 192.168.0.0/16 subnet into two /17 subnets because its nicely symmetric and stuff and assign the server LAN to 192.168.128.0/24. I should emphasize that this is a "virtual boundary", i.e. it does NOT mean that my home LAN is the whole /17 subnet and the server is the whole /17 subnet. They have a /24 subnet each in their respective /17 subnet.
It would have sufficed to move the Server LAN to 192.168.2.0/24 or something but this way I know that when I see a IP from the second half of the /16 subnet that this is a Server-Side Client. And I thought that 192.168.2.0/24 was to close to the default 192.168.1.0/24 LAN and might cause collisions when connecting from the Uni, Hotel or other public LAN.So the choice to split the /16 into exactly 2 was completely arbitrary and works and I'm happy with it.
The only issue I have left that I still can't access the LAN Clients in the Server 192.168.128.0/24 net when connected via OpenVPN, I'm still investigating this.
Yes… So, instead you have basically killed OpenVPN for any client that needs to connect remotely from 192.168/16 subnet.
What do you mean by that? AFAIK it will only collide now if the VPN client is in the 192.168.128.0/24 net, which (in my case) is sufficiently unlikely.
-
What you have done is to guarantee an IP space collision with anyone else you have to connect to who happens to be on 192.168.X.X. This is, essentially, everyone.
Want to set up OpenVPN so you can VPN in from the road? It'll break from any LAN using 192.168.X.X which is, essentially, everywhere.
Here are some random suggestions:
10.162.93.0
172.19.80.0
192.168.232.0172.19.80.0 is perfect. I'd use 172.19.80.0/20. Give your segments 172.19.80.0/24, 172.19.81.0/24, 172.19.82.0/24 … 172.19.95.0/24
ETA: It looks like we're misreading you and you assigned /24s. You are better off keeping the address space you occupy as small as possible while reasonably anticipating all future needs at the site. Notice that the scheme I recommend lets you cover the entire network with one route: 172.19.80.0/20, and gives you 16 /24 networks to work with. The odds of you ever colliding with anyone else (who didn't do something idiotic like use 172.16.0.0/12) are very minimal. If you think there is no way you'll ever need 16 subnets, by all means allocate out of a /21 or /22. Or just go from 80 to 81 to 82, etc and it'll get as big as it gets.
