Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Jan 2000 10:36:43 -0500
From:      "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com>
To:        Michael Bartlett <cataract@eye2eye.net>
Cc:        "'cjclark@home.com'" <cjclark@home.com>, "'questions@freebsd.org'" <questions@FreeBSD.ORG>
Subject:   Re: FW: internet gateway setup using NATD
Message-ID:  <20000124103643.A10401@cc942873-a.ewndsr1.nj.home.com>
In-Reply-To: <F16C1C3F6AB8D311998F00C0DF266AE7E22B@OPTIC>; from cataract@eye2eye.net on Mon, Jan 24, 2000 at 05:10:07PM %2B0200
References:  <F16C1C3F6AB8D311998F00C0DF266AE7E22B@OPTIC>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 24, 2000 at 05:10:07PM +0200, Michael Bartlett wrote:
> Crist,
> 
> Thanks for your response, maybe you could clear a couple of things up for me
> here...
> [eyeland] # ipfw list
> 01000 allow ip from any to any via lo0
> 01100 deny ip from 127.0.0.0/8 to 127.0.0.0/8
> 01500 divert 8668 ip from any to any via rl0
> 65000 allow ip from any to any
> 65535 deny ip from any to any

Looks good.

> I was under the impression that the # of the firewall rule is the order in
> which the rule is implemented (01000 will happen before 01100). If this is
> the case, do rules 65000 and 65535 not conflict each other? I cannot for the
> life of me find what is instigating rule 65535 on my box, nor can I delete
> it :
> 
> [eyeland] # ipfw delete 65535
> ipfw: rule 65535: setsockopt(IP_FW_DEL): Invalid argument

See the ipfw(8) manpage,

     One rule is always present:

                       65535 deny all from any to any

     This rule is the default policy, i.e., don't allow anything at all.  Your
     job in setting up rules is to modify this policy to match your needs.

     However, if the kernel option ``IPFIREWALL_DEFAULT_TO_ACCEPT'' is active,
     the rule is instead:

                       65535 allow all from any to any

     This variation lets everything pass through.  This option should only be
     activated in particular circumstances, such as if you use the firewall
     system as an on-demand denial-of-service filter that is normally wide
     open.

> > On one of my other boxes I run this script in /usr/local/etc/rc.d
> > 
> > /sbin/natd -n fxp0 -redirect_port tcp 196.38.133.194:110 196.38.133.198:80
> > /sbin/ipfw add divert natd all from any to any via fxp0
> 
> I have been previously told that it is "bad practise" to execute stuff like
> this in rc.d - but that has never been justified properly to me (I was told
> its not "pure"). Now in the abovementioned example this is my ipfw list:

I could not think of a reason off hand why it is technically
bad once I saw on the next lines how you have the firewall
setup. However, you lose the flexibility of starting natd from rc.conf
and all of the little detail that rc.network handles for you. It is
not good for most people since they typically have more complicated
firewall rules on a natd box. Under those circumstances, you need to
start natd when you start the firewall and you need to get all of your
network setup in order to do many of the other steps of the typical
multi-user startup.

You also miss out on a lot of support since most people don't do it
that way. ;)

> [messenger] # ipfw list
> 00100 divert 8668 ip from any to any via fxp0
> 65535 allow ip from any to any
> 
> The difference between the two boxes is that the [messenger] box does not
> act as a gateway whereas the [eyeland] box does. We can see that the
> firewall rules are slightly different but otherwise I can't see anything
> glaringly obvious that is making this thing not work.

messenger looks like it was compiled with IPFIREWALL_DEFAULT_TO_ACCEPT
set in the kernel config.

Anyway, all of that aside, I just noticed something about these,

 # /sbin/natd -n rl0 -redirect_port tcp 196.31.83.226:25 196.31.83.227:80

 01500 divert 8668 ip from any to any via rl0

Are the packets destined for 196.31.83.227 actually crossing the rl0
interface? They don't get sent to natd if they do not.

> -----Original Message-----
> From: owner-freebsd-questions@FreeBSD.ORG
> [mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Crist J. Clark
> Sent: Sunday, January 23, 2000 5:50 AM
> To: Michael Bartlett
> Cc: 'questions@freebsd.org'
> Subject: Re: FW: internet gateway setup using NATD
> 
> 
> On Sat, Jan 22, 2000 at 03:05:31PM +0200, Michael Bartlett wrote:
> > Thought I'd throw this @ the list as well...
> > 
> > -----Original Message-----
> > From: Michael Bartlett 
> > Sent: Saturday, January 22, 2000 2:56 PM
> > To: 'Burke Gallagher'
> > Subject: RE: internet gateway setup using NATD
> > 
> > 
> > Hey Burke,
> > 
> > Sorry to bug you again, but I'm having another problem and it could be
> > related to what you told me to do and could also prove interesting...
> > 
> > On one of my other boxes I run this script in /usr/local/etc/rc.d
> > 
> > /sbin/natd -n fxp0 -redirect_port tcp 196.38.133.194:110 196.38.133.198:80
> > /sbin/ipfw add divert natd all from any to any via fxp0
> > 
> > If you are confused, the reason is that we needed to get around a firewall
> > problem (one of our consultants other company close 110 access on their
> > firewall - this way he can pickup his mail from us with port 80!! ;) ).
> > 
> > Anyway,
> > 
> > I tried the identical thing on my box with your settings and take a
> look...
> > 
> > [eyeland] # /sbin/natd -n rl0 -redirect_port tcp 196.31.83.226:25
> > 196.31.83.227:80
> > [eyeland] # telnet 196.31.83.227 80
> > Trying 196.31.83.227...
> > telnet: Unable to connect to remote host: Connection refused
> > 
> > Now the .227 ip is an alias on rl0, so it should just be passed along the
> > same NIC and have no problems. I also tried the destination being on rl1
> > (192.168.62.150:25) which is an smtp server on my local network and that
> > didn't work either.
> > 
> > Any thoughts?
> 
> Yes. First, don't start NATd from /usr/local/etc/rc.d. That is pretty
> much dead last in the startup process and could prevent lotsa stuff
> from being started properly in the ealier steps since the networking
> won't work. It also means that your divert to natd in the firewall is
> the last rule. Most likely, that will mess things up too (especially
> if you have a 'pass ip any to any' before it).
> 
> In your second problem, it's really hard to say what is going on. Your
> firewall rules (with the divert) are suspect for the above reasons, so
> I would not be surprised if nothing works. However, even if we assume
> they are now OK, we can't say if there is a problem with natd. If you
> call 196.31.83.226 directly on port 25, do you actually get to talk to
> sendmail (or whatever MTA is supposed to be listening)? natd could be
> working and we would not know it.
> -- 
> Crist J. Clark                           cjclark@home.com
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" in the body of the message

-- 
Crist J. Clark                           cjclark@home.com


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000124103643.A10401>