vnet jail and ipfw/nat on host - keep-state problem?

[Ian Smith]

Hi Peter, going back to your second message ..

On Wed, 9 Jul 2014 16:24:27 +1000, Peter Ross wrote:

 > P.S. I also have the following rules near the top:
 > 
 > 01000 check-state
 > 01100 allow tcp from any to any established

For one thing, if you are running named as an authoritative nameserver 
in the jail, you'll also need to forward tcp port 53 traffic as well, as 
that's what's needed for zone updates to/from secondary NS.  So you may 
need to separate tcp port 53 traffic from other host traffic too.

And often, if setting state for your tcp rules as well, you rather want 
to _deny_ established traffic, but it does depend on your mix of rules.

 > 01200 allow ip from any to any frag

Indeed.

 > Peter
 > 
 > On Wed, 9 Jul 2014, Peter Ross wrote:
 > 
 > > Hi all,
 > > 
 > > I am setting up a host with vnet jails without a public IP.
 > > 
 > > E.g. a vnet jail with a DNS server (bind) running inside.
 > > 
 > > The setup:
 > > 
 > > Internet->age0(host interface with natd and external IP)
 > > ->bridge10(10.0.10.254)->epair1a
 > > ->epair1b(10.0.10.1 in bind vnet jail)
 > > 
 > > Inside the jail I have a simple open ipfw firewall
 > > (ipfw allow ip4 from any to any)
 > > 
 > > Here the rules relevant to let UDP port 53 connect from the outside world
 > > (with natd redirecting "redirect_port udp 10.0.10.1:53 external.ip:53")
 > > 
 > > 00100 divert 8668 ip4 from any to any via age0
 > > 03100 allow udp from any to 10.0.10.1 dst-port 53 keep-state
 > > 03200 allow udp from any to me dst-port 53 keep-state
 > > 
 > > This does not allow DNS requests from the outside, they only get returned
 > > by adding
 > > 
 > > 03300 allow udp from me 53 to any

It's not quite clear which addresses are where; could you show ifconfig 
for the host interfaces, including bridge and epair, obscuring public 
IP/s as necessary?  'me' on the host refers to any address configured on 
any of the host's interfaces, so might be a bit broad; more explicit 
rule/s might reveal this problem better?

Personally I don't use stateful rules for DNS at all, and I'm pretty 
careful if ever I use 'in keep-state' at all.  Hmm, maybe rule 3100 
should be qualified with 'in', or you may be inflicting a double-state 
situation?  Use 'ipfw -ted show' to examine dynamic rules incl. expired.

 > > I am pretty confident that the rules above work with "real interfaces". I
 > > have similar routers with ipfw/natd, there things are even more limited by
 > > interface rules (recv/xmit).
 > > 
 > > Does this mean, "keep-state" are not working properly in the mentioned vnet
 > > setup?

Not sure, but if it were me I'd add 'log' to all relevant rules and make 
sure net.inet.ip.fw.verbose_limit is set to something sensible, like the 
default of 100, in order to actually outline your flows.  It might be 
helpful to temporarily log packets to and from the jail also, assuming 
that logging to jail's /etc/security is working properly these days?

(verbose_limit reminds me of another of Joe B's silly recommendations in 
the IPFW Handbook section that I promised Warren I'd help clean up ..)

cheers, Ian