OT: Selective routing and proxying
jon at radel.com
Thu May 14 19:49:52 UTC 2020
On 5/14/20 14:13, Aryeh Friedman wrote:
> My significant other's employer (a public university) has payed for
> subscriptions on many newspapers and other periodicals that normally are
> pay-walled and allows anyone on the campus network (or VPN to it) us said
> subscriptions if you use the library's proxy server. There are other on
> campus only services that they want to also access like virtual desktops
> and network drives. For privacy reasons we want to make so only access to
> the said subscription and/or on campus IT services are routed via the VPN
> connection/library proxy and all others go out our normal ISP. Note we
> also have and other VPN connection to one of my clients that due to privacy
> regulations (HIPAA) must be used for all our work with them.
> What is the best way to handle all this? (Currently have 2 physical
> FreeBSD machines in the house and 2 more running as VM's and one Windows VM
> and one Windows physical machine... the VM's use bhyve)
It all depends:
* Are the VPNs you use relatively "open" ones, where if you know the
IPsec parameters, PSK (pre-shared key), and your authentication
information, it'll come right up. Or are we talking something with
proprietary sauce carefully tied to an employer/client owned laptop
that won't work unless the security token is plugged in?
* Is the address space on the other side of all VPNs non-overlapping?
* How dependent are you on DNS working for names on the far side of
In the case of a fortunate answer to the first question, I'd personally
use a FreeBSD VM, or a copy of pfSense either as a virtual appliance or
one of their little physical boxes, to act as a router and firewall.
Terminate the VPNs on the new router. Terminate your ISP connection on
the new router. Then it pretty much becomes a very straight-forward
exercise in routing. With however much firewalling you want to add to
force things to break if the "wrong" workstation tries to use the HIPAA
Unless the answer to question number two is unfortunate. In which case
you'll have to do some NATing. I'd strongly consider 1:1 mapping to an
otherwise unused chunk of RFC 1918 space. Which should be easy to do on
the edge router, except that....
....if you're dependent on DNS for services reached across either VPN,
DNS will get a bit trickier. A lot of end-user VPN configurations are
configured to force use of resolvers on the organizational network.
It's the cleanest way to give the client machine access to names that
map to private addresses on the other side. But that doesn't work so
well when there are VPNs to multiple organizations that have no reason
to coordinate access to DNS data. There I'd say it comes down to how
complicated your needs are. If there are only a couple of names that
need to work, it's probably easiest to just dump them into /etc/hosts on
the various clients that need access. If it's more complicated, I'd be
tempted to use dnsdist, which I've successfully used quite recently to
"glue together" a unified view of DNS for client machines: RFC 1918
reverse lookups from here, <company>.local from over there, the Internet
at large via the filtering at OpenDNS/Cisco Umbrella unless it's the
mail servers which would loose their little minds if you did that.
Likewise, it would be a fairly easy configuration to forward
<university>.edu lookups across one VPN, <medical>.com across another,
and send the rest to your ISP or Google or whatever you currently do.
Writing a bit of Lua code to translate responses in a way that matches
the 1:1 NAT would be somewhat more advanced, but I believe that's quite
feasible (I've had to do some other weird rewrites in dnsdist, but not
But again, it all depends. You haven't even told us whether you use a
managed switch that supports VLANs and/or have spare ethernet ports,
never mind what your budget is.
And as always, any issues regarding the terms of the contract with the
periodical subscription folks or whether any of this would freak out
some security officer somewhere, who realizes that you've now exposed
his stuff to all the users of your wifi AP, are between you and Not Me.
jon at radel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4177 bytes
Desc: S/MIME Cryptographic Signature
More information about the freebsd-questions