Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Jul 2002 16:46:27 +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:  <20020730164627.A19307@rfc-networks.ie>
In-Reply-To: <20020730133246.A18016@rfc-networks.ie>; from philip.reynolds@rfc-networks.ie on Tue, Jul 30, 2002 at 01:32:46PM +0000
References:  <20020729144758.A11849@rfc-networks.ie> <20020730055722.GD89241@blossom.cjclark.org> <20020730133246.A18016@rfc-networks.ie>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
Philip Reynolds <philip.reynolds@rfc-networks.ie> 33 lines of wisdom included:
> "Crist J. Clark" <crist.clark@attbi.com> 19 lines of wisdom included:
> > This is a FAQ,
> > 
> >   http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13412+0+archive/2002/freebsd-net/20020217.freebsd-net
> 
> using ``via'' helped along the way and the setup is currently
> working.
> 
> What was needed was a specification of the public interface _only_
> for the ``NATD'' rule in conjunction with a specification of the
> private interface _only_ for the ``keep-state'' rule. 
> 
> Unfortunately tweaking my rules before, I must have missed this
> combination, although I'm not sure how.
> 
> Thanks for to Crist and Boris for their help.

After a lot of testing, I solved the problem earlier on (although
not adequately, however it helped produce the solution below)

--] Public Info [-
Interface: xl0
Network:   10.0.0.0/24 (or simply: ``not 10.0.1.0/24'')
Address:   10.0.0.56

--] Private Info [-
Interface: xl1 
Network:   10.0.1.0/24 
Address:   10.0.1.56


Rules:

   divert natd ip from any to any via xl0
   check-state
   deny tcp from any to any via xl1 established
   deny ip from any to any in recv xl1 frag
   allow tcp from 10.0.1.0/24 to any 22 via xl1 setup keep-state
   allow tcp from 10.0.0.56 to any 22 out xmit xl0
   deny ip from any to any

1:    Divert everything through the public interface to NAT
2:    Check the state of the packets coming through.
3&4:  No established connections or IP fragments should be here that
      aren't in the stateful ruleset table.
5:    Allow any packets out to port 22 that have SYN (but not ACK)
      bit set (i.e. ``setup packets'')
6:    Allow TCP connections from 10.0.0.56 to port 22. I was getting
      messages that a TCP connect from 10.0.0.56 to the destination
      machine on port 22 was being rejected without this.
7:    Deny everything else.  

I hope my logic above is right, as you can see from my rules listing
below, it seems to have solved the problem.

$ ipfw -d list
00100 divert 8668 ip from any to any via xl0
00200 check-state
00250 deny tcp from any to any via xl1 established
00251 deny ip from any to any in recv xl1 frag
00300 allow tcp from 10.0.1.0/24 to any 22 keep-state via xl1 setup
00400 allow tcp from 10.0.0.56 to any 22 out xmit xl0
65534 deny ip from any to any
## Dynamic rules:
00300 32 4394 (T 203, slot 135) <-> tcp, 10.0.1.2 4249<-> 10.0.0.10 22


This is basically the refined version of my previous mail, the
following commmands is a reduced ruleset that will work but provides
no ruleset protecting packets coming in xl0 not destined for the
10.0.1.0/24 network.


   divert natd ip from any to any via xl0
   check-state
   allow tcp from 10.0.1.0/24 to any 22 via xl1 setup keep-state
   deny ip from any to any via xl1
   allow ip from any to any

I think I confused people in my previous mail, however the above is
what I meant. The ruleset, provided by a colleague of mine, however,
is too open for my (and probably a lot of other peoples) needs.
As you can see, the ``deny'' line, only denies anything going
through xl1.

With a bit of messing here as well though, another appropiate
solution could be adequate.

If anyone has any comments/suggestions etc. please direct them my
way.

Regards and many thanks,
-- 
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?20020730164627.A19307>