RE: FW: internet gateway setup using NATD

From owner-freebsd-questions Tue Jan 25 10:13: 6 2000 Delivered-To: freebsd-questions@freebsd.org Received: from mail.eye2eye.co.za (mail.eye2eye.co.za [196.31.83.226]) by hub.freebsd.org (Postfix) with ESMTP id E50EC14BD8 for ; Tue, 25 Jan 2000 10:12:41 -0800 (PST) (envelope-from cataract@eye2eye.net) Received: from [192.168.62.150] (helo=optic.eye2eye.net) by mail.eye2eye.co.za with esmtp (Exim 3.12 #1) id 12DCYS-00008N-00; Tue, 25 Jan 2000 20:27:12 +0000 Received: by OPTIC with Internet Mail Service (5.5.2448.0) id ; Tue, 25 Jan 2000 20:25:11 +0200 Message-ID: From: Michael Bartlett To: "'cjclark@home.com'" Cc: "'questions@freebsd.org'" Subject: RE: FW: internet gateway setup using NATD Date: Tue, 25 Jan 2000 20:25:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6761.83A89410" Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6761.83A89410 Content-Type: text/plain; charset="iso-8859-1" Crist, Sorry to bombard you, but I think I'm sort of closer (well actually I've done this by the book now) and am still having the problem when I telnet 196.31.83.227:25 I get the 196.31.83.226:25 exim hello rather than the 192.168.62.150:25 response. [eyeland] /etc # 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 allow ip from any to any As you can see, I adjusted the IPFIREWALL_DEFAULT_TO_ACCEPT in my kernel. natd_enable="YES" natd_interface="rl0" natd_flags="-f /etc/natd.conf" And finally /etc/natd.conf with most of the comments removed... log yes # Incoming connections. Should NEVER be set to "yes" if redirect_port, # redirect_address, or permanent_link statements are activated in this file! # # Setting to yes provides additional anti-crack protection # deny_incoming no use_sockets yes same_ports yes verbose no port 8668 interface rl0 unregistered_only no #The following mapping points outside address 198.105.232.1 to 192.168.1.56 redirect_address 192.168.62.150 196.31.83.227 Now the interesting thing here is the first comment that deny_incoming should never be set to yes. So I didn't! Then they have their example on the redirect_address, and so I adjusted it to suit my IPs and still nothing! I'm wondering if this maybe has something to do with it # Obtain interface name from the command output of "ifconfig -a" # # alias_address 192.168.0.1 interface rl0 And then what you said... >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. I've tried to uncomment that alias_address and put 196.31.83.227 in there, but the same results. What do you mean by crossing the rl0? And do you have any other ideas ;) Cheers Mike From: Crist J. Clark [mailto:cjc@cc942873-a.ewndsr1.nj.home.com] Sent: Monday, January 24, 2000 5:37 PM To: Michael Bartlett Cc: 'cjclark@home.com'; 'questions@freebsd.org' Subject: Re: FW: internet gateway setup using NATD 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 ------_=_NextPart_001_01BF6761.83A89410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: internet gateway setup using NATD

Crist,

Sorry to bombard you, but I think I'm sort of closer = (well actually I've done this by the book now) and am still having the = problem when I telnet 196.31.83.227:25 I get the 196.31.83.226:25 exim = hello rather than the 192.168.62.150:25 response.

[eyeland] /etc # 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 allow ip from any to any

As you can see, I adjusted the = IPFIREWALL_DEFAULT_TO_ACCEPT in my kernel.

natd_enable=3D"YES"
natd_interface=3D"rl0"
natd_flags=3D"-f /etc/natd.conf"

</snip>

And finally /etc/natd.conf with most of the comments = removed...

log yes
# Incoming connections. Should NEVER be set to = "yes" if redirect_port,
# redirect_address, or permanent_link statements are = activated in this file!
#
# Setting to yes provides additional anti-crack = protection
#
deny_incoming   no
use_sockets     yes
same_ports      yes
verbose         = no
port          = ; 8668
interface       = rl0
unregistered_only       = no
#The following mapping points outside address = 198.105.232.1 to 192.168.1.56
redirect_address = 192.168.62.150        = 196.31.83.227

Now the interesting thing here is the first comment = that deny_incoming should never be set to yes. So I didn't!

Then they have their example on the redirect_address, = and so I adjusted it to suit my IPs and still nothing!

I'm wondering if this maybe has something to do with = it

# Obtain interface name from the command output of = "ifconfig -a"
#
# alias_address 192.168.0.1
interface = rl0

</snip>

And then what you said...

>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.

I've tried to uncomment that alias_address and put = 196.31.83.227 in there, but the same results. What do you mean by = crossing the rl0? And do you have any other ideas ;)

Cheers

Mike

From: Crist J. Clark [mailto:cjc@cc942873-a= .ewndsr1.nj.home.com]
Sent: Monday, January 24, 2000 5:37 PM
To: Michael Bartlett
Cc: 'cjclark@home.com'; = 'questions@freebsd.org'
Subject: Re: FW: internet gateway setup using = NATD

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:

&nb= sp; = 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:

&nb= sp; = 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 &= nbsp; &= nbsp; cjclark@home.com
>
>
> To Unsubscribe: send mail to = majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" = in the body of the message

--
Crist J. = Clark &= nbsp; &= nbsp; cjclark@home.com

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