multiple client sites: which architecture to choose
-
@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)
-
On my way.
So far I have an OpenVPN server running in Mode: "Remote Access ( SSL/TLS + User Auth )".
One shop/site ("site01") is connected via Windows OpenVPN client and is successfully accessing a VM in our server net. Nice.Now for the questions:
Should we be able to access the LAN of "site01"?
I added its subnet to a CSO in the field "IPv4 Remote Network/s".
I see a route added in the Routing Table under "Status/OpenVPN".
but when I ping an IP in "LAN-site01" it seems that it goes out via the default gateway .. wrongQuick googling seems to say: only "peer to peer" mode allows accessing the LAN behind the openvpn-client. Correct?
If yes, why the option to define Remote Networks in the CSO?
I will try to set up a 2nd openvpn server with "peer to peer" etc
Although that sounds scary: wouldn't that result in one ovpn-server per customer-site??
EDIT: why do I need routing to their LAN? The VM/server in the server LAN has to communicate with a card terminal in the client LAN.
-
plan B
- configured the client-appliance to have 2 LAN-ports
- added a portforwarding: from external "tunnel client IP" to "IP of card terminal in LAN behind the vpn client" (with specific ports)
- successfully accessed that card terminal from the server LAN
(for the test I used a webserver in a docker container on a laptop)
So as long as the card terminal has a fixed IP etc this should work.