Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Jul 2002 00:19:56 +0000
From:      Philip Reynolds <philip.reynolds@rfc-networks.ie>
To:        freebsd-ipfw@freebsd.org
Subject:   Re: 4.6-RELEASE / NATD + IPFW + keep-state
Message-ID:  <20020730001956.A15831@rfc-networks.ie>
In-Reply-To: <20020729223214.GB1488@xy.blank.spb.ru>; from borman@blank.spb.ru on Tue, Jul 30, 2002 at 02:32:14AM +0400
References:  <20020729144758.A11849@rfc-networks.ie> <20020729223214.GB1488@xy.blank.spb.ru>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
boris karlov <borman@blank.spb.ru> 48 lines of wisdom included:
> On Mon, 29 Jul 2002 14:47:58 +0000, Philip Reynolds <philip.reynolds@rfc-networks.ie> wrote:
> > 
> >     divert 8668 ip from any to any
> 
> -- mb, divert 8668 ip from any to any via xl0?

This is actually what I have (unfortunately messing around with my
rules etc. caused me to paste not quite the exact ruleset I started
out with).

The still works as I documented in my previous mail, with ``ipfw -d
list'' bring up two connections.

> -- IMHO: these packets are processed twice by ipfw(8) as for packets
> routed by the host (acting as a gateway) (see ipfw(8), `IMPLEMENTATION NOTES'
> section). you should alias only outgoing packets before next hop forwarding
> but not incoming ones after reception on an IP interface (see divert(4),
> `READING PACKETS' section).

I'm not too clear on what you mean by "alias", I can only presume
you mean translations via NAT, in which case I'm not sure where
you're coming from? (i.e. NAT needs to be done on incoming and
outgoing packets on the public interface).
 
> > Packet comes in on inside interface.
> > Packet matches access rule with keep-state option and gets added to
> > dynamic ruleset
> > Packet NAT'd
> 
> -- it seems you forgot `Packet comes out from outside interface and gets
> NATed too' here.

That's what I meant by the last line.

Unfortunately I didn't specify the ``via xl0'' in my original
ruleset for the divert line, however I can assure you, the behaviour
is consistent with this in. 

What I'm curious about is the connection which is showing up in
``ipfw -d list'', which is timing out according to
"net.inet.ip.fw.dyn_syn_lifetime:".

Unfortunately nothing you've suggested seems to have worked (unless
I've missed something?), although thankyou for your suggestions.
Perhaps this mail may shed some more light on the issue.

Phil.

-- 
Philip Reynolds                  | Technical Director
philip.reynolds@rfc-networks.ie  | RFC Networks Ltd.
http://www.rfc-networks.ie       | +353 (0)1 8832063

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?20020730001956.A15831>