On 1/6/24 15:09, Ibsen S Ripsbusker wrote:
Dear colleagues,



I have various network appliances that I don't really trust, like
a printer. I have these plugged into an unmanaged switch and
connected to network interface igc2.

I want to allow the igc1 network to make web requests to the igc2
network, and I want the igc2 network to have very restricted access
outside of igc2.

what does a printer need internet access for?
nevermind.  Don't answer that.  It's the 21st century.  Many people
think their bloomin' thermostats should have Internet access...(I'm
really close to replacing my non-internet connected digital
programmable thermostat with a 100% mechanical.  Because...they
don't suck)
(My main computer is connected to network interface igc1.
And the egress interface is igc0.)

MY QUESTION: What would be a normal way of achieving this?

let's abstract this a bit...
(in large part because a sequence of letters and numbers confuses
me quickly.)

So you have a trusted network, an untrusted network, and of course,
the Internet, which we will just call "The Evil".

While you can do it with a bridge, I don't want to think that
hard.  And it would be a lot of work.

[snip bridge stuff]

I also tried setting different subnets.

yeah. that's the way I'd go.

trusted:
   /etc/hostname.igc1:>    inet 192.168.2.1/24
untrusted:
   /etc/hostname.igc2:
   inet 192.168.3.1/24

With this everything works as I want except that
the only way I figured out to allow hosts on 192.168.2.1/24
to access 192.168.3.1/24 was with NAT, and that can't be right.

yeah, the problem is, it sounds like your barrier machine is not
your primary gateway/firewall.  So when your trusted machine in
192.168.2/24 talks to an address in 192.168.3/24, it talks to your
primary gateway, and your gateway says, "whoa, dude.  wazzat?"

I'd fix this by making your main firewall the barrier machine.
This would require a three or more port firewall.

Pass in from trusted to anywhere.
block in quick on untrusted to trusted
Pass from untrusted to anywhere (but trusted is already blocked)


Failing that, with a separate barrier machine, you will need to
add a static route for the 192.168.3/24 subnet to point to the
"trusted" address of your barrier machine. That way, when your
trusted network machines try to access the untrusted network, they
know to route through your barrier machine.  Every single trusted
machine that wants to access something in that subnet will need
that extra route added.  Clumsy at best (probably doable with the
DHCP server.  I just glanced, looks kinda ugly).


I guess if there is only one untrusted device, you could just use
an inbound NAT tunnel for whatever ports need to access that
device, then just use the barrier's IP address to access the
device.  But I don't normally think in quantities of one, and
this doesn't scale well.  But if there's only one device, or several
devices, but they can all be hit on different ports, that's an
option.


Another way to do it is with two NATting firewalls:

Evil <--[NAT-FW] <- untrusted network [NAT-FW] <- trusted network.
(internet)         (192.168.3/24)                 (192.168.2/24)

traffic flows unimpeded in the direction of the arrows, and is
blocked going backwards.  Your trusted machines can hit untrused
machines or the internet, untrusted machines can hit the Internet,
but they can't dig through to your trusted network.  Yeah, the down
side is that the trusted network has to jump through two routers,
so the untrusted network potentially has better access than the
trusted network, and that's just not fair.  But ... it's easy.


I've done the opposite, what I call "portable DMZ"s, where untrusted
machines need access to the Internet but shouldn't be allowed to
touch the trusted machines, but unlike your situation, the untrusted
machines don't need to be accessed by the trusted.  Small machine,
two NICs.  One NIC is DHCP to the trusted network, NAT and DCHP server
on the untrustedv side, maybe a logging DNS server.  Block all from
the untrusted to the trusted subnet, pass everything else (internet).
These don't need those inbound static routes.

Nick.

Reply via email to