multiple client sites: which architecture to choose

[viragomann]

@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 - internet

And 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.

[sgw]

@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 - internet

And 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

[viragomann]

@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 then

Assign 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 address

Now 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.

[sgw]

@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

[viragomann]

@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.

[sgw]

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 ...

[viragomann]

@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".

[sgw]

@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.

[viragomann]

@sgw
For sure this would help to evaluate the set up.

[sgw]

Yes. I will try to draw some diagram by hand ... not wasting too much time with some software I can't handle ;-)

[sgw]

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?

[viragomann]

@sgw
So I understood it correctly.

Isn't that working?

As mentioned, you would need static routes pointing to pfSense for the client sides subnet on all devices, which need to communicate. On the server side this might only be the server and the router (assuming that the router connects to the office network, so that the employees in the office can also access the client side devices).

I forgot to draw pfsense1 in the office, sorry

As I understood, it is connected to the router and has its own LAN behind.

[sgw]

@viragomann

they access their server-VMs already, but maybe unprotected: no VPN, no TLS, that's the status quo.

So pfsense1 might be a first VPN-client to establish a protected connection between office and servers.

And it's a demo-appliance for a first shop.

[viragomann]

@sgw said in multiple client sites: which architecture to choose:

they access their server-VMs already

I was talking about accessing the clients LAN. I understood, that this is required for troubleshooting.

[sgw]

@viragomann said in multiple client sites: which architecture to choose:

@sgw said in multiple client sites: which architecture to choose:

they access their server-VMs already

I was talking about accessing the clients LAN. I understood, that this is required for troubleshooting.

Ah, yes.

I should add the shops/clients to the drawing, sure.

That's what this is all is about in the end: enabling the shops to access the servers over secure channels.

[viragomann]

@sgw
No, I was meaning this:

Main site: actually it consists of 2 segments:
An office with a firewall/router and a server site with a fw/router.

[sgw]

I now have done first steps there:

as projected I was able to set up a pfSense as a parallel router/firewall:

I have a static WAN-IP with routed internet, and LAN has an IP in their server-LAN.

By adding a static route to the pfSense I can reach it from the office-LAN.

Set up an OpenVPN-server, plus some users, we chose a Test-VM in the server-LAN, added a route ("reach openvpn-subnets via the LAN-IP of pfSense") and I can successfully access that VM via OpenVPN, tested from a Windows 11 laptop from outside, and my linux laptop.

I then set up a SG1100, imported the VPN-client-config and established the tunnel. OK.

But here I get stuck: per default WAN gets its IP via DHCP. In my "shop scenario" I want to plug the SG1100-WAN-interface into their LAN-switch ... and connect the shop-PC to the SG1100-LAN-interface.

That means WAN gets an RFC1918-IP .. which isn't good ... as the default IPv4 deny rules match etc etc

Basically I don't need (??) NAT on such a box, I only want a gateway into the established VPN-tunnel. Should/could I disable NAT on the "vpn-client appliance"?

Maybe I am just too tired today ... and I overlook the obvious. Thanks for every help here.

[viragomann]

@sgw said in multiple client sites: which architecture to choose:

But here I get stuck: per default WAN gets its IP via DHCP. In my "shop scenario" I want to plug the SG1100-WAN-interface into their LAN-switch ... and connect the shop-PC to the SG1100-LAN-interface.

That means WAN gets an RFC1918-IP .. which isn't good ... as the default IPv4 deny rules match etc etc

Why not?
There is not any incoming access desired on WAN, as I understood your requirements.
And if it ever was for any reason you could disable RFC1918 blocking.

Basically I don't need (??) NAT on such a box, I only want a gateway into the established VPN-tunnel. Should/could I disable NAT on the "vpn-client appliance"?

As mentioned, it would make things much more complicated.
You would need different client sides LAN subnets for each and the proper routes on the OpenVPN server.
I'm preaching this since my very first post here. So if you want routes, just do it and have fun.

[sgw]

@viragomann said in multiple client sites: which architecture to choose:

@sgw said in multiple client sites: which architecture to choose:

But here I get stuck: per default WAN gets its IP via DHCP. In my "shop scenario" I want to plug the SG1100-WAN-interface into their LAN-switch ... and connect the shop-PC to the SG1100-LAN-interface.

That means WAN gets an RFC1918-IP .. which isn't good ... as the default IPv4 deny rules match etc etc

Why not?
There is not any incoming access desired on WAN, as I understood your requirements.
And if it ever was for any reason you could disable RFC1918 blocking.

OK, I see. My first tests were done from inside their office-LAN today, that wasn't the best setup. I will test with the SG1100 tmrw, from my LAN.

I'm preaching this since my very first post here. So if you want routes, just do it and have fun.

ok ok ;-) it seems I haven't fully understood yet. I test things tomorrow and maybe things get clearer then anyway. Thanks so far @viragomann

[viragomann]

@sgw said in multiple client sites: which architecture to choose:

My first tests were done from inside their office-LAN today, that wasn't the best setup.

Not clear, what you're calling office-LAN here. I was thinking about the main office network, but maybe you mean the clients LAN.

As I explained, for accessing devices in the clients network (which might only be one according to your description), I would forward the traffic on the VPN interface to it. So you would have to call the clients virtual IP to access it.