multiple client sites: which architecture to choose
-
@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?
-
@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.
-
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.
-
@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.
-
@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.
-
@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. -
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.
-
@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. -
@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
-
@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.
-
I was plugging the future "shop appliance" = SG1100 into their office LAN as I was testing.
I assume there was a route missing on the target VM (the default gateway is still the Barracuda) ... we will fix and check that later today.
With a software client like a Windows-PC with OpenVPN on it the device directly gets an IP in the OpenVPN subnet.
With the SG-1100 as client that isn't true, the PC behind it gets an address in the LAN-subnet of that device: additional layer, additional routes needed.
If it was possible to somehow directly use the OpenVPN subnet for the devices plugged into LAN, that would be great.
Maybe you suggest that, could you explain how to DO that?
thanks! good morning (here)
-
I currently struggle with how to route the LAN behind the OpenVPN client to the servers behind the OpenVPN server.
The SG1100 is able to ping 192.168.1.75 in the LAN of SG2100 (tested from the GUI).
A client in the LAN of SG1100 (192.168.99.0/24) is NOT able to reach 192.168.1.75.
In the OpenVPN server I have "IPv4 Local network(s): 192.168.1.0/24"
For the user used in the VPN client on SG1100 I configured a CSO containing:
IPv4 Remote Network/s: 192.168.99.0/24
No obvious firewall hits ... what do I miss? thanks for help here.
-
@sgw said in multiple client sites: which architecture to choose:
The SG1100 is able to ping 192.168.1.75 in the LAN of SG2100 (tested from the GUI).
A client in the LAN of SG1100 (192.168.99.0/24) is NOT able to reach 192.168.1.75.
I assume, you're missing the outbound NAT rule on the client, as described above.
For the first testing you can do this also without CSO. This is only needed here to assign a certain IP to the client, which would be relevant later.
-
@viragomann Yes, the outbound nat rule was missing.
Followed that part from your suggestionNow my laptop is able to connect, great!
thanksI will try to understand all this and decide if I can use all this in "production" (after some more cleanups etc, sure)