Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Jun 2016 02:32:04 +0000
From:      James Lodge <James@Lodge.me.uk>
To:        "org.freebsd.security@io7m.com" <org.freebsd.security@io7m.com>
Cc:        "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
Subject:   Re: Filtering outbound traffic for private address jails?
Message-ID:  <B587F027-A8E5-4B5F-AC1A-07AEDB26F022@Lodge.me.uk>
In-Reply-To: <20160625220137.1ed8de16@copperhead.int.arc7.info>
References:  <20160625220137.1ed8de16@copperhead.int.arc7.info>

next in thread | previous in thread | raw e-mail | index | archive | help



Sent from my iPhone
On 25 Jun 2016, at 23:10, "org.freebsd.security@io7m.com<mailto:org.freebsd=
.security@io7m.com>" <org.freebsd.security@io7m.com<mailto:org.freebsd.secu=
rity@io7m.com>> wrote:

Hello.

I have been searching for the best part of a day for a solution to this
problem and quite frankly cannot believe that I've spent this long on
something that appears to be so simple and that used to be fairly easy
to achieve. Many years ago, I solved this problem on FreeBSD 6, but the
way I did it there seems to no longer work on modern releases.

The problem is this: I have a single public IP address. I want to run
multiple jails.

Back in the days of FreeBSD 6.*, the accepted way to do this seemed to
be to create a new loopback device:

 # ifconfig lo1 create

... and then add a lot of private 127.0.0.* addresses, one per jail.

Then, the real network adapter and the new loopback device were both
added to a bridge (if_bridge). Unfortunately, I can't remember the exact
details, but I believe that NAT was then enabled on the real interface.
In order to filter traffic to, from, and between jails, pf rules were
written that filtered the bridge device.

This meant that jails could correctly send outbound traffic and
receive responses (via pf states), could correctly receive specific
inbound traffic (via rdr rules), and traffic in both directions could be
filtered based on packets entering and leaving the bridge.

However (see my other mailing list post), it seems that now with
FreeBSD 10, you just can't add loopback devices to bridges. I can find
no evidence of anyone online doing this, or even using the old bridge
method that I just described! I can find one post in russian that seems
to have the same error that I encounter, but nobody has any idea why
it's happening.

I can find dozens of blog posts describing how to set up jails on
private IP addresses. They all follow the same pattern:

 1. Create a loopback device.
 2. Create a 127.0.0.* address on the loopback device.
 3. Create a jail using the address you just added.
 4. Set up pf and enable NAT between the real network adapter and
    the new loopback device.

Unfortunately, at this point, you completely lose the ability to filter
outbound jail traffic; All packets sent from a jail will obviously have
their source address changed to that of the host and therefore it's not
possible to distinguish between outbound host traffic and outbound jail
traffic in filter rules.

As far as I can tell, people are just not filtering outbound traffic,
which seems insane!

Is it really impossible to do this with FreeBSD 10?

M
_______________________________________________
freebsd-net@freebsd.org<mailto:freebsd-net@freebsd.org> mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org<mailt=
o:freebsd-net-unsubscribe@freebsd.org>"


If you clone lo1, give it a 192.168.x.x/32 IP and then use the following pf=
.conf
Do you need to bridge the interfaces? You may need to add gateway_enable=3D=
"YES" to rc.conf

Not sure if that's what you're trying to do?

James


IP_PUB=3D"Your Public IP Address Here"

IP_JAIL=3D"192.168.0.2"

NET_JAIL=3D"192.168.0.0/24"

PORT_JAIL=3D"{80,443,2020}"

scrub in all

nat pass on em0 from $NET_JAIL to any -> $IP_PUB

 rdr pass on em0 proto tcp from any to $IP_PUB port $PORT_WWW -> $IP_JAIL





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B587F027-A8E5-4B5F-AC1A-07AEDB26F022>