On 27 Jul 2001, at 19:49, Daniel C. Sobral wrote:
> [EMAIL PROTECTED] wrote:
> >
> > With the following ipfw config fragment,
>
> Which happens not to include the rule that is denying your packets...
Untrue -- it's the "deny log tcp from any to any established" in the
fragment I gave (# 00600 in the ipfw listing below)
> >
> > # divert packets through the tunnel interface
> > $fwcmd add divert natd all from any to any via tun0
> > ...
> > # allow anything I start up (OK)
> > # allow connections to continue once made (FAILS!)
> > $fwcmd add check-state
> > $fwcmd add deny log tcp from any to any established
> > $fwcmd add allow log tcp from any to any out via tun0 setup keep-
> > state
> >
> > I get the following typical failures happening
> >
> > data# ipfw zero
> > Accounting cleared.
> >
> > (Run telnet session)
> >
> > data# ipfw show
...
> > 00500 0 0 check-state
> > 00600 8 344 deny log logamount 100 tcp from any to any
> > established
> > 00700 4 192 allow log logamount 100 tcp from any to any keep-
> > state out xmit tun0 setup
...
> > 65435 0 0 deny log logamount 100 ip from any to any
> > 65535 0 0 deny ip from any to any
> > ## Dynamic rules:
> > 00700 3 144 (T 5, # 86) ty 0 tcp, 213.104.70.121 1041 <->
> > 195.8.69.73 119
> >
.......
>
> It's doing precisely what you told it to. Perhaps if you would move the
> check-state before the nat?
Well, I tried that - moved to to just after the 'flush'. That just hangs
totally, presumably because although the packets do match at the
check-state, the rules stop being checked as soon as there's a
match, so the nat never happens. In fact, *anything* that matches
before the nat diversion will stop the latter happening, surely, so
the nat *must* be first.
I'm worried about the logic of the problem -- it seems to me that
there's no way that nat and the dynamic rules can work together
correctly, given that both incoming and outgoing packets start at
the top and work down the same list of rules. Tthe keep-state and
check-state surely have to be on the same side of the nat,
because they have to work together *either* on local *or* external
addresses, not a mixture. But if they're after the nat (as for all
written examples I've seen), then for incoming packets they operate
on local addresses, and for outgoing on external addresses, which
is not what's wanted. If they're before the nat, we never reach the
nat.
Am I totally at sea here with my understanding of what's going on?
Does anyone on the list have a working example which they could
offer, please, and set my mind at rest?
--
various incoming sites blocked because of spam:
see www.mikescott.clara.net for a list
[EMAIL PROTECTED] Mike Scott
aka [EMAIL PROTECTED] Harlow Essex England
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
