Using OpnSense To Connect Multiple Networks Together

MapGuy11

Hi All,
I have been trying to get this done, but seem to hit roadblocks in a different step everytime and would like some tips on my journey.
My goal is to have my OPNsense VM (sitting behind my main UniFi network on a specific VLAN - not that it matters) connect to many different routers (some on OpenVPN and some Wireguard) running VPN servers. My goal is OPNsense would connect to these all and I can setup routing rules so that when I hit its network it will go from the main net to OPNsense (this part is ez) and then forward over the correct VPN tunnel to it's destination (I seem to hit some weird firewall issues in this part). It would be especially cool if I didn't have to switch every router I am connecting to a different subnet that I am not using (but I can switch them if required). Also, I can't deploy devices on each network for a tailscale alternative or something similar, unfortunately (would be much easier!) (I can swap to something like pfsense or another alternative if you think it is easier.)

Main Net (Requests 10.76.xx.xx) -> OpnSense -> (Certain VPN Tunnel) -> Router with that (10.76.xx.xx IP)

I appreciate any help that you can provide!

HELLFIRE

May I suggest a drawing or diagram of what you're trying to do? I've read over your explanation multiple times and I'm having a heckuva time even visualizing what it is you're doing... or what your roadblock is?

From this

MapGuy11 Main Net (Requests 10.76.xx.xx) -> OpnSense -> (Certain VPN Tunnel) -> Router with that (10.76.xx.xx IP)

only seems to be part of what you have and/or trying to do? Or am I missing something (more) here?

Or would it be more descriptive to visualize things as :

a.a.a.a / OPNSense --> UnFI --> "the internet" --> (another VPN device) --> d.d.d.d
			|
b.b.b.b ----------------^

and a host in b.b.b.b network trying to get to d.d.d.d must SOMEhow loop back to a.a.a.a so OPNsense can tunnel it to "another VPN Device"?

"Right Hand, Left Hand" and all that...

Regards

MapGuy11

HELLFIRE You are correct lemme do a diagram I apologize.

Computer Requests 10.22.xx.xx it will go through this path:
"Main Net" --> "OpnSense" --> "VPN Tunnel" --> "Router on other side" (10.22.xx.xx)
I am having trouble where opnsense can travel along the tunnel and get there. And, I can get the routing rules to go from Main Net to OpnSense but something in OpnSense will forbid it to go from the external interface (that is facing MainNet) and route to the VPN tunnel.

HELLFIRE

MapGuy11 "Main Net" --> "OpnSense" --> "VPN Tunnel" --> "Router on other side" (10.22.xx.xx)

That's a routing problem for starters -- HOW is the routing looking hop-by-hop through "Main Net" and "OpnSense?" Secondly, how granular are the routing controls hop-by-hop? TL;DR, if can't do either, you're hosed.

To expand my earlier diagram to explain things alittle better :

a.a.a.a / OPNSense --> UnFI --> "the internet" --> (another VPN device) --> d.d.d.d
			|		|
b.b.b.b ----------------^		|
					---------> youtube

Host b.b.b.b hits d.d.d.d through the tunnel you want to build on Opnsense.
Host b.b.b.b also goes to youtube on the internet, but this traffic doesn't need to be tunneled.
so on host b.b.b.b, UnFI, or Opnsense, SOMEthing needs to be able to granularly parse this routing out and (re)direct it accordingly, ie.
IF SRC=b.b.b.b AND DST=d.d.d.d THEN send to Opnsense and tunnel
ELSE do not tunnel.

I don't know what your base OS is on host b.b.b.b, nor am I versed in what controls Opnsense nor Wireguard has. You may have some luck with "opnsense policy based routing" on your search engine of choice.

Hope that gives you a starting point.

Regards

MapGuy11

HELLFIRE
I really appreciate your continued help. Yeah I am going to keep trying to attack it I know it's possible I just seem to stop somewhere! Thanks again! 🙂

cypherstream

MapGuy11 also make sure the defaults “block bogon addresses” and “block rfc1918 addresses” are UNCHECKED on the wan in opnsense. If you have static routes pointed properly, by default opnsense blocks these private IPs back in from wan because it expects wan to be the internet, but in reality the wan is on the outside of UniFi here.