NAT Reflection rules for FreeBSD PF

[Oliver Peter]

On Tue, Nov 15, 2016 at 02:49:18PM +0000, Big Lebowski wrote:
> On Tue, Nov 15, 2016 at 1:26 PM, Oliver Peter <lists at peter.de.com> wrote:
> 
> > On Tue, Nov 15, 2016 at 01:03:54PM +0000, Big Lebowski wrote:
> > > On Tue, Nov 15, 2016 at 11:37 AM, Oliver Peter <lists at peter.de.com>
> > wrote:
> > >
> > > > El duderino,
> > > >
> > > > On Mon, Nov 14, 2016 at 10:30:59PM +0000, Big Lebowski wrote:
> > > > >
> > > > > I am trying to set up a 11.0-R PF based NAT for group of jails that
> > needs
> > > > > to be able to talk to services on other jails, just as if they'd be
> > > > clients
> > > > > from outside of the network. Apparently, this is called 'NAT
> > reflection'
> > > > > and I was able to find examples for OpenBSD PF here:
> > > > > https://www.openbsd.org/faq/pf/rdr.html (bottom of the page).
> > > > >
> > > > > Obviously, their syntax doesn't work on FreeBSD PF, so how to
> > achieve the
> > > > > same thing? How to allow jails NAT'd on $ext_if (xn0) coming from
> > > > > $jails_net (192.168.0.0/24 aliased on lo0) to talk to each other,
> > via
> > > > the
> > > > > $ext_if external IP?
> > > >
> > > > We did something similar in a customer setup a while ago:
> > > >
> > > >         nat on $int_if from $jail_host to any -> $int_ip
> > > >         rdr pass on $int_if proto { tcp, udp } from $jail_host to
> > $ext_if
> > > > port{ $service1, service2 } -> $int_lb
> > > >
> > > > Cheers
> > >
> > > Thanks for your response Olivier! Would you mind elaborating on it a bit
> > > more? I don't understand what you're trying to achieve here, since the
> > NAT
> > > doesn't happen on $int_if (lo0) but instead on $ext_if (xn0). The $int_if
> > > only holds the jail's IP addresses from the $jail_net range. How does
> > that
> > > compare?
> >
> > Ah, it could be that this is a bit different since you only have a single
> > machine, our example was a gateway with two interfaces (ext/int) doing NAT
> > for some machines behind.  Since your packets are created on lo0 and
> > routed to xn0 it might be different.
> > Another idea would be to re-route the packets between the two interfaces:
> >         pass out quick on $ext_if route-to $int_if from ($int_if:network)
> > to $ext_if:network
> >
> > This might interfere with your regular outgoing traffic;  maybe the "to"
> > part needs a bit tuning.  Furthermore I'm not sure about the source
> > addresses...  We have this in production to route some DNS traffic via
> > VPN.
> >
> > Split horizon DNS is no option?
> > Sorry for not being very helpful.
> 
> 
> No worries, you've been most helpful so far :)
> 
> The host has two interfaces, I simply chose lo0 for jails, because I wasn't
> aware it would matter, so, if needs be, I can migrate jails IP's from lo0
> to xn1 - would it make difference in that I'd now be able to implement the
> reflection somehow, or would I need to get the jails out of the host
> entirely and make the host to provide gatefway functionality only?

Well, you made me curious about this so I created two jails on a
11-RELEASE test machine with a single external address.
	jail0 is on lo0
	jail1 is on lo1

For outgoing service I have:

	nat on em0 from lo0:network to any -> ($ext_if)
	nat on em0 from lo1:network to any -> ($ext_if)

The interesting thing here is that /all/ traffic happens on lo0 - even for
jail1 which sits on lo1 only - which I don't understand.

Furthermore it seems that since the target machine is also the source
machine and does not need any routing the packets are not translated but
directly routed, I tested this with:
	rdr pass on lo0 proto tcp from lo1:network to $ext_ip port 2224 -> $jail0 port 22

jail0 only sees the internal IP since we do not route here.

I was thinking about a mixture of PF and IPFW but this is getting nasty
now.


-- 
Oliver PETER       oliver at gfuzz.de       0x456D688F
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20161116/7030938d/attachment.sig>