OPNsense Forum

English Forums => General Discussion => Topic started by: flipswitchingmonkey on November 07, 2016, 04:01:04 pm

Title: Is OPNsense the right thing for this scenario
Post by: flipswitchingmonkey on November 07, 2016, 04:01:04 pm
Hi all,

I was wondering whether you could give me a heads up in advance before I attempt to fix my problems with an OPNsense-solution in this setup:

Two subnets A and B.
Two WAN (one DSL, one Cable).

A and B should not communicate with each other (so no routing between those two).
B can connect to the outside world.
Some B should connect via DSL, some via Cable (identified via IP for example). No proxy, no limits.
A should connect to the outside world in either way, but through a proxy with Whitelist.

So the question is, can OPNsense:
- use whitelists for proxy (judging form the docs that's a yes?)
- excempt clients from otherwise enforced proxy by their IP-range
- route clients to different gateways based on their IP (to lead them to the DSL or Cable WAN)

I plan to get a 4x LAN board for this, so one port for A, B, Cable and DSL.

Any help would be much appreciated. Cheers!
Title: Re: Is OPNsense the right thing for this scenario
Post by: franco on November 08, 2016, 09:39:17 pm
Hi flipswitchingmonkey,

Yes, that setup is perfectly fine. In order to get your policy for A set up correctly you will probably use LAN so you need to delete / modify the pass all rules for IPv4 and IPv6 according to your needs (essentially set to: not network "B"). The OPT1 for B will have no rules templates, it needs similar rules then.

The proxy is per port/interface, so if you configure it for A, it will not enforce it for B. The transparent proxy enforcement is also done in (the NAT part of) the rules. You can also exempt IP addresses or subnets from the proxy if that works better for you.

Last but not least, the Multi-WAN is flexible and you can write multiple source/destination policies per interface, but note that due to a bug in FreeBSD the policy route circumvents transparent proxy enforcement at this point. We're hoping for a fix in 17.1, but it's a different kind of code compared to what we write for OPNsense normally so it's not as easy/quick to fix.

Hope that helps! :)


Cheers,
Franco