multiple client sites: which architecture to choose
-
Let me add another question here:
Shouldn't the SG-2100 use hardware encryption for OpenVPN?
I enabled the general encryption under "System", but I can't choose any hardware support in the OpenVPN server config itself.The dashboard shows supported hw encryption.
-
@sgw To make your life easier I would go with Wireguard VPN for this setup since you have pfSense+ Appliances. Much easier to setup and maintain.
-
@keyser said in multiple client sites: which architecture to choose:
@sgw To make your life easier I would go with Wireguard VPN for this setup since you have pfSense+ Appliances. Much easier to setup and maintain.
Thanks for the suggestion. I hesitate to go that way ... I use wireguard for some VPNs already but for this project I see too many question marks.
-
@sgw We each have our preferred ways :-)
To me OpenVPN is much to cumbersome with certificate management/renewal/maintenance to avoid disconnects (which if you forget and do not have a backdoor, becomes a HUGE undertaking) -
@keyser said in multiple client sites: which architecture to choose:
@sgw We each have our preferred ways :-)
To me OpenVPN is much to cumbersome with certificate management/renewal/maintenance to avoid disconnects (which if you forget and do not have a backdoor, becomes a HUGE undertaking)I haven't decided yet, as I am still collecting information and try to come up with a solution for the needs there.
I see some benefits in the wireguard way ... sure, but I am more experienced in setting up OpenVPN for setups like this. At least I understand it better IMO ... not knowing everything, as this thread shows ;-)The customer has around 60 sites to connect to ... all some kind of RDP-users dialing into their terminal service, and needing remote support from time to time.
Sure, right now I only have to come up with a working draft to connect ONE test site ...
wireguard: I have to think about assigning subnets to the clients: remember: I have to enable my customer to access several IPs optionally (one PC + maybe a printer + card terminal or so)
But I am open to the suggestion, sure.
-
@sgw Yeah, you need to think the design over. If 256 sites will forever be enough, I would fx. Take 172.31.x.x/16 as the subnets for this setup and use 172.31.0.x/24 for the server site, 172.31.1.x/24 for the first client site and so on.
By using Wireguard you are using routed tunnels, that way you can address all routing with one statement (172.31.0.0/16 -> ) in all sites - and it opens the door to client sites talking to each other without changes in routing if you need it (only a firewall rules issues). -
@keyser sounds valid ... thanks! I might try to set that up in my test environment ... before suggesting wg to the customer.
-
@keyser do you maybe have a link to an article or howto somewhere doing a similar setup?
-
@sgw unfortunately not :-(
-
@sgw said in multiple client sites: which architecture to choose:
The SG-1100 should provide DHCP to the devices in its LAN (usually one PC and something like a card terminal etc), and enable the PC to run RDP sessions over OVPN, accessing a specific VM in the server LAN behind that main pfSense.
So the PC which is connecting to the RDP server is in a separate LAN (I call it RDP-LAN) behind the VPN client (SG-1100)?
This means the clients network look somewhat this:
RDP-LAN - SG-1100 - upstream router - internetAnd all devices which need to communicate with the server side reside within the RDP-LAN?
You also mentioned a printer in the upper post, so I'm unsure.If I can get rid of problematic NAT: fine. Otherwise I will try it with a standard setup and see what I get.
Sure you can do all with routes, and this would be the cleaner solution, but depending on your needs, natting may be easier to set up and maybe don't need to touch the other parts of clients network.
-
@viragomann said in multiple client sites: which architecture to choose:
So the PC which is connecting to the RDP server is in a separate LAN (I call it RDP-LAN) behind the VPN client (SG-1100)?
This means the clients network look somewhat this:
RDP-LAN - SG-1100 - upstream router - internetAnd all devices which need to communicate with the server side reside within the RDP-LAN?
You also mentioned a printer in the upper post, so I'm unsure.The idea is to send preconfigured SG-1100 appliances to the paying customers of my customer. They plug a small switch into the LAN-port, and connect a PC and optional devices like a network printer and a card terminal ("bankomat" in german language ... ) to that switch.
The SG-1000 is configured to establish the VPN connection to the main server LAN of my customer where the RDP-services run. So the various shops using the software my customer provides are able to run RDP sessions protected and routed via VPN. Right?
Yes, I have to solve how the PCs there connect to their own LAN as well. Must be done with some routing, I assume.
The easier solution might be to only install OpenVPN client software to the PCs there. That would solve the routing issues. But my customer would prefer to use physical appliances: this way it's easier to let the end customers pay a small fee per month (they "see" what they pay for ...).
My customer wants to be able to access the peripheral devices for debugging purposes. That needs the switch (maybe I can use the internal ports of the SG1000 for that).
This is just a draft, I think it could be done this way ... but might be wrong.
thanks for brainstorming with me
-
@sgw
Since you have several dozens client devices, I try to find a way to realize this with as view individual settings as possible. Therefore I'm asking several questions to learn what you need to achieve.
And as I already mentioned, natting some traffic can make the setup much easier. However, you have to decide if it fits your needs.I think, it could work this way:
Basics:
Use a small an unusual clients LAN network and set the mask as small as necessary. I'll call it clientLAN.
As well configure an unusual VPN network pool.I don't explain the VPN, since you mentioned you know, how to configure it.
Server:
On the server site you may have to add some routes.
Add an additional network segment to the servers sites firewall, which you connect the pfSense to running the VPN server. This is the transit network.On the server sites router you need to add a static route for the VPN tunnel network and point it to pfSense.
On pfSense I assume, that the other router is the default gateway. So there are no routes needed.As I understood your requirements you also need access from the office network to the clientLAN. So you would also need a route on the office router to direct the VPN tunnel to the servers router (assuming they are connected anyhow).
Client:
Assumption: there is a DHCP server running in the shops LAN.
Configure pfSense WAN to pull an IP from the DHCP. This should also set the default gateway.
Configure a small unusual LAN network, as said, and enable the DHCP on it. Maybe you can do static mappings for the devices you need to access from the server side, so you can give all the same IP and can use the same filter rule configuration for all thenAssign an interface to the VPN instance and enable it.
In the outbound NAT enable the hybrid mode and add a rule to the VPN interface (OpenVPN if none is assigned):
source: clientLAN
dest. server sites LAN
translation: interface addressNow if the PC access the server he will be routed over the VPN due to the VPN settings. The clients pfSense translates the source IP into the clients VPN IP, and this is, what the server sees. Since each client has a unique VPN IP, all clients can be identified at the server.
For the other direction, accessing a device on the client site from the server, also NAT would make things easier.
Add a NAT port forwarding to the VPN interface (you have assigned before) and forward the needed port to the device IP you want. For the printer, if you do static mapping the rule would be the same on all clients.
In case you need to access multiple devices play with destination ports.Then if you want to access the printer from the server site, you connect to the respective clients VPN IP (which you know and is unique), so this goes to the clients pfSense and is forwarded to the printer.
Clients PC communication with the other LAN devices outside of pfSense like server, printer or any:
Since pfSense does outbound NAT on its WAN (assuming it gets a gateway from the DHCP), this works out ob the box. However, the destination device would see the WAN address of pfSense, but not the origin PC IP. If there is only one PC behind the clients pfSense this would be decent, maybe as well if there are more.Access from the clients LAN network into the network behind pfSense would not be possible, but should not be needed anyway, as I understood.
If I haven't forgotten something essential this should work.
If you don't want to do the NAT stuff you would need to configure different clients LAN networks and add routes for each of it on the servers LAN router. And apart from the client VPN IPs you have also to keep in mind the client LAN networks to access the devices.
I'd prefer the nat and do other tings in the saved time. -
@viragomann thanks for the detailed "draft" ... I have to read through it multiple times and try to understand all the parts of it.
This is still meant to be realized with OpenVPN, right?I wonder about the part with the printer etc ...
Basically I need a kind of site-to-site behavior:
site1 (servers): contains the VM(s) with the RDP-server(s) .. plus admin-PCs in the office LAN segment
site2 (shop number X): contains the shop PC plus maybe the card terminal and a network printer
site2 should be allowed to only access one specific terminal server
-
@sgw said in multiple client sites: which architecture to choose:
This is still meant to be realized with OpenVPN, right?
Yes, and you would need to state remote networks in the CSO. However, a CSO for each client is necessary anyway, since you need to assign specific VPN IPs to the client to access them.
I wonder about the part with the printer etc ...
That's just port forwarding. I have to find out, which port you need to forward though.
Basically I need a kind of site-to-site behavior:
Normally you realize a site-to-site with proper routing, not NAT. NAT has drawbacks, especially masquerading (S-NAT), so that you only see the routers IP on the destination device, not the real clients source IP.
But I think, for these purposes that doesn't matter. On the server you only need to know, which client is connecting, and this is given by the VPN IP. On the client site, for access from the server site the real source should not be relevant.site1 (servers): contains the VM(s) with the RDP-server(s) .. plus admin-PCs in the office LAN segment
site2 (shop number X): contains the shop PC plus maybe the card terminal and a network printer
In the OpenVPN server settings or even in the CSO, you have to state the server sites local networks, so the servers LAN + the office LAN, to push these routes to the client, since this is not natted at the clients.
site2 should be allowed to only access one specific terminal server
Allowing access is done by firewall rules. It depends on your needs if this can be done with a single rule for the whole tunnel subnet on the servers VPN interface or if you need to give a specific client only access to a certain server.
-
Talked to their internet provider today, I think things get a bit easier:
I'll be able to set up my pfSense IN PARALLEL to the existing Barracuda appliances. So I will get static IP(s) on WAN and establish an additional gateway in both the server- and the office-LAN.
I assume that reduces the complexity ...
-
@sgw
Easier? Sure?As I understood, pfSense should get an interface in both server and office LAN. And how do you think, access to the printer is properly routed?
Yes, this would work if you add a static route to each device, which you want to access the remote site. This is an option for a handful devices. But otherwise I think, this is much more effort than spawning up a transit network.
However, if the devices networks are configured via DHCP you could distribute the route by the Server in case, this is supported, of course.Getting a WAN IP on the VPN gateway doesn't make things better at all for your purpose. It needs pretty the same effort as if you connect pfSense to the LAN as a "router on a stick".
-
@viragomann said in multiple client sites: which architecture to choose:
@sgw
Easier? Sure?hm, I hope so.
I think I should somehow come up with a drawing or diagram here. Just to show things better. -
@sgw
For sure this would help to evaluate the set up. -
Yes. I will try to draw some diagram by hand ... not wasting too much time with some software I can't handle ;-)
-
Did a quick drawing, forgive the quality.
In black the current situation as far as I know.
I assume they have some routes in place between LANs "office" and servers, maybe on the barracudas, maybe at provider level.
I will have a phone call with the provider admin for details tomorrow, and be on-site on wednesday, to check details.
In green my suggested placement of the pfSense as a VPN-gateway:
I assume I could get one or more static official IP-adresses to use as WAN-IPs.The servers and/or VMs would need a route: reach all VPN-subnets by using the pfSense as gateway.
The "shops" (=external VPN-clients) would connect to WANIP_pfs2 (I forgot to draw pfsense1 in the office, sorry).
Isn't that working?
