Easiest way to allow limited traffic between two LANs that do not share a gateway
-
I have a network configuration (depicted below) currently implemented as two separate and distinct networks:
[WAN interface to Internet]
^
|
[Router 1 is a NetGate 6100] --- [VLAN 10 Subnet 10.100.0.0/24]
[5G Internet]
^
|
[Router 2 is a T-Mobile Gateway] --- [VLAN 20 Subnet 192.168.1.0/24]
Notes:
All switches and access points are managed and VLAN aware.The NetGate 6100 is used for working from home. Devices on this network, VLAN 10, must be protected.
Router 2 is used for in home IOT devices. Devices on this network, VLAN 20, cannot be trusted. The T-Mobile router's configuration cannot be changed.
The setup provides the isolation I want. It's currently two distinct LANs with distinct WANs. The IOT devices have no way to open connections on the work LAN. However, I would like to be able to reach some of the VLAN 20 devices from two VLAN 10 devices. And there is a gaming PC on VLAN 20 that I would like to back up to my RAID server on the work LAN. The backup agent phones home, so the PC on VLAN 20 needs to reach VLAN 10.
I am toying with a few ideas:
Establish a site-to-site WireGuard tunnel between VLAN 10 and 20. This could be done with a pfSense VM, or a NetGate 5100 I not currently using. The problem with this is that the devices on VLAN 20 will not know to use the WireGuard tunnel.
The second idea is to put a pfSense router in front of the 5G router. This seems to be more complicated and would then introduce a double NAT situation which would likely derail gaming connections.
The third would be to add an additional network adapter to the gaming PC on VLAN 20. That adapter would be connected to VLAN 10.
I am looking for ideas and also some recipe guidance. Not interested in Multi WAN or failover. I'll do that with the switches.
-
@bigtfromaz for access from your router 1 vlan 10, just add an interface from the 10.100 network into the 192.168. network.. So pfsense would now have an interface in the 192.168 network.
To get to stuff in the 192 network just source nat so traffic to anything on the 10 network talking to 192 network looks like its coming from pfsense 192.168 address in this network.
For your pc to talk to your 10 network.. Just create a specific route on the pc, hey vs sending to your default gateway (this tmoble device) send traffic for 10.100.0/24 to pfsense 192.168 address.
I do sort of the same thing to access the network behind my nvr the cameras are on the 10 network behind the nvr device.. I just connected a interface on pfsense into this network behind the nvr, and source natted traffic so it looks like coming from pfsense IP address in that network.. Now I can directly talk to any of the cameras on that network.
But since I don't have anything in this 10 network behind the nvr to ever create a connection to any of my other networks, I don't need any routing on the devices..
The only thing required for this solution is a connection from your pfsense into this 192.168 network.. Maybe a wire is needed to connect from pfsense into this network, and then some config. If your using a shared vlan capable switch already for both of these networks - then all that is required is some config.
-
NAT works nicely for VLAN 10 to VLAN 20. It hadn't dawned on me that we can use NAT without adding a gateway. Here's a screen snap of the manual outbound mapping. Let me know if you see opportunity for improvement:
The static route works well, routing VLAN 10's subnet to the pfSense's VLAN 20 (TMOBILE22) interface address. Windows Task Scheduler is set up to execute the "route add" command at startup.
I hard coded the gaming PC's VLAN 20 IP address to 192.168.12.n and added rules to TMOBILE22 allowing the PC to reach very specific ports on specific interfaces in VLAN 10. Everything else if blocked, including ICMP. Can you think of ways to improve on this?
Thanks for your help!
-
@bigtfromaz you could maybe limit the outbound nat for only the device you would be coming from lan with. Like your pc... But yeah that works..
If you just add the route as persistent it should survive reboots, upgrades, etc. you shouldn't need a batch to kick off on startup.
I would normally allow ping as a way to validate connectivity..
