Moving away from pptp in favor of openvpn
-
Currently I have pptp vpn implemented in our network. PFsense is our router/firewall which also included the pptp vpn solution.
We have a class C network for our internal usage ie: 10.xx.xx.xx/24
We have other VPN technologies connecting our office to a bigger Class A network 10.0.0.0/8
What I've read so far is I will have to dedicate a separate network for my Road-warrior clients ie: 192.168.x.x/24
Because I have no control over the Class A network and its routing tables, I need to stay inside the Class C network which is provided to me.
With pptp this worked without any issue, I just reserved a range of ip address in my class C network and use them for pptp clients.
It looks to me OpenVPN works differently and I cannot make it work like pptp does.Would there be a solution that fits my profile? I would also prefer staying with TUN type because I don't see any solution for Android to support TAP.
-
Why do you think you need to stay inside your local /24 ??
Why do you think it matters what IP the road warriors have? I would prob stay away from 192.168.1 .2 as your tunnel network - just because its likely to be used in the remote networks.
As long as your local clients don't have firewalls blocking access from your tunnel network, you should be click click up and running.
-
Why do you think you need to stay inside your local /24 ??
To access devices inside my C class network is no problem at all, but ones I would like to access any device inside the class A network it would fail.
The class A network doesn't know about my new private network, so it wouldn't know how to route the traffic back. -
what?
So lets call your local lan 10.0.1.0/24, and lets say you use 192.168.42.0/24 as your tunnel network. So your RW vpn client gets say 192.168.42.6/24 as its IP.
So he wants to talk to 10.0.1.12/24 – his box says oh that network is down the tunnel.. He goes down the tunnel to pfsense, pfsense says oh your want to talk to 10.0.1.12, that is connected to my lan network - sends the traffic to 10.0.1.12.. This box at 10.0.1.12 says 192.168.42.6 --- well that is not my network, so sends reply back to its gateway (pfsense)... Which says oh that network is down the tunnel and send the traffic back to RW client using the tunnel.
Unless your bridging your openvpn connection to your lan - this is how it would work. If you used a network inside your lan IP without bridging - how would some client know to send the traffic back to pfsense? It would just say oh that is my local network and put it back out the wire, where pfsense would never see it.
So are you currently bridging your vpn connection to your lan?
What do you mean access IPs in the class A?? You mean the network the vpn client is on?? From what your RW vpn client box, or network behind pfsense? Are you setting your clients to route all traffic down the tunnel? Then no client would not be able to access the class A network its own in this sort of setup.
Are you trying to setup a site to site connection, or a road warrior type connection?
-
Since your /24 is part of 10.0.0.0/8 I have to assume that the other sites in your organisation have been alocated various parts of 10.0.0.0/8 (not the whole it - otherwise your LAN subnet would conflict with 10.0.0.0/8).
Let's say your current subnet is 10.11.12.0/24 - then the easy solution is to get those who are allocating out the 10.0.0.0/8 around the organisation to actually give you 10.11.12.0/23 - then you get the size of 2 class C subnets routed to you. You can use the second one for OpenVPN.
If they won't do anything for you, then you habe to stay within 10.11.12.0-255 addresses, as that is all that the rest of your intranet will route back to you.
If you don't need so many address for your local LAN, then split:
10.11.12.0/25 - local LAN
10.11.12.128/25 - OpenVPN clients -
Since your /24 is part of 10.0.0.0/8 I have to assume that the other sites in your organisation have been alocated various parts of 10.0.0.0/8 (not the whole it - otherwise your LAN subnet would conflict with 10.0.0.0/8).
Let's say your current subnet is 10.11.12.0/24 - then the easy solution is to get those who are allocating out the 10.0.0.0/8 around the organisation to actually give you 10.11.12.0/23 - then you get the size of 2 class C subnets routed to you. You can use the second one for OpenVPN.
If they won't do anything for you, then you habe to stay within 10.11.12.0-255 addresses, as that is all that the rest of your intranet will route back to you.
If you don't need so many address for your local LAN, then split:
10.11.12.0/25 - local LAN
10.11.12.128/25 - OpenVPN clientsYour assumptions are correct, and splitting the class C subnet is a way which could work (ive though about it).
Splitting is a lot of work for me as it would mean that i would need to reconfigure lots of devices and external devices (connected via other vpn's).
Ive also been thinking of setting up a second pfsense box and attache the WAN interface to my LAN side so all the clients will be masqueraded, but in the end I would still prefer to use a single pfsense instead of managing multiple ones.So if I rephrase the question, would it be possible to solve it without splitting the class C network and without installing an additional device?
-
If the Road Warrior clients only need to initiate connections to resources across the VPN to your site/s (i.e. they don't provide any remote services that you want to connect to from your site), then this might be possible:
- NAT the incoming OpenVPN road warrior links/clients onto your LAN
Conceptually then, the road warriors would be seen as having a LAN address that is at your site. The rest of your network will deal with the routing without change.
I haven't actually tried to do that on pfSense - someone else can advise if it is possible and how :)
- NAT the incoming OpenVPN road warrior links/clients onto your LAN
-
- NAT the incoming OpenVPN road warrior links/clients onto your LAN
That's one of the solutions I have looked for but couldn't find how to do so.
Another point is I wouldn't know which client connected because of the NAT but that would be acceptable if I would get it working
