Date: Tue, 14 Sep 1999 19:23:36 +0300 From: Ruslan Ermilov <ru@ucb.crimea.ua> To: Doug White <dwhite@resnet.uoregon.edu> Cc: hackers@FreeBSD.ORG Subject: Re: Multiple NAT alias addresses Message-ID: <19990914192335.A3257@relay.ucb.crimea.ua> In-Reply-To: <Pine.BSF.4.10.9909140846130.65695-100000@resnet.uoregon.edu>; from Doug White on Tue, Sep 14, 1999 at 08:49:21AM -0700 References: <19990914040220.B71293@relay.ucb.crimea.ua> <Pine.BSF.4.10.9909140846130.65695-100000@resnet.uoregon.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 14, 1999 at 08:49:21AM -0700, Doug White wrote:
> On Tue, 14 Sep 1999, Ruslan Ermilov wrote:
>
> > > hello ..
> > >
> > > We're trying to turn up a firewall box running NAT with multiple external
> > > IPs. I added the alias and set up natd.conf as follows:
> > >
> > > use_sockets yes
> > > same_ports yes
> > > #
> > > # machine1 redirections
> > > #redirect_port tcp 192.168.2.237:ssh 1.2.3.4:ssh
> > > #redirect_port tcp 192.168.2.237:smtp 1.2.3.4:smtp
> > > #redirect_port tcp 192.168.2.237:pop3 1.2.3.4:pop3
> > > #redirect_port tcp 192.168.2.237:imap4 1.2.3.4:imap4
> > >
> > > # machine2 redirections
> > > redirect_port tcp 192.168.2.201:ssh 1.2.3.5:ssh
> > > redirect_port tcp 192.168.2.201:http 1.2.3.5:http
> > >
> > > I start natd with:
> > >
> > > natd -f /etc/natd.conf -n fxp0 where fxp0 is the public-side interface.
> > >
> > > Restarting natd with this configuration causes it to block everything.
> > >
> > So, without redirect_port's it works OK?
>
> Yes, and the redirect_port's work if the alias address is not specified.
>
Strange, I just run 3.2-RELEASE's natd(8) with your configuration file
and everything works as expected:
Firewall rules were:
00001 divert 8668 ip from any to 1.2.3.5 via fxp2
00001 divert 8668 ip from 192.168.2.201 to any via fxp2
Natd(8) was run as:
natd -v -f natd.cf -n fxp2 (fxp2 in an external interface)
telnet 1.2.3.5 123 (from 212.110.138.4):
In [TCP] [TCP] 212.110.138.4:49964 -> 1.2.3.5:123 aliased to
[TCP] 212.110.138.4:49964 -> 1.2.3.5:123
In [TCP] [TCP] 212.110.138.4:49964 -> 1.2.3.5:123 aliased to
[TCP] 212.110.138.4:49964 -> 1.2.3.5:123
In [TCP] [TCP] 212.110.138.4:49964 -> 1.2.3.5:123 aliased to
[TCP] 212.110.138.4:49964 -> 1.2.3.5:123
Redirections not happening.
telnet 1.2.3.5 80 (from 212.110.138.4):
In [TCP] [TCP] 212.110.138.4:49960 -> 1.2.3.5:80 aliased to
[TCP] 212.110.138.4:49960 -> 192.168.2.201:80
Out [TCP] [TCP] 192.168.2.201:80 -> 212.110.138.4:49960 aliased to
[TCP] 1.2.3.5:80 -> 212.110.138.4:49960
In [TCP] [TCP] 212.110.138.4:49960 -> 1.2.3.5:80 aliased to
[TCP] 212.110.138.4:49960 -> 192.168.2.201:80
In [TCP] [TCP] 212.110.138.4:49960 -> 1.2.3.5:80 aliased to
[TCP] 212.110.138.4:49960 -> 192.168.2.201:80
Out [TCP] [TCP] 192.168.2.201:80 -> 212.110.138.4:49960 aliased to
[TCP] 1.2.3.5:80 -> 212.110.138.4:49960
Out [TCP] [TCP] 192.168.2.201:80 -> 212.110.138.4:49960 aliased to
[TCP] 1.2.3.5:80 -> 212.110.138.4:49960
In [TCP] [TCP] 212.110.138.4:49960 -> 1.2.3.5:80 aliased to
[TCP] 212.110.138.4:49960 -> 192.168.2.201:80
Redirections are happening.
> > Have you tried to run it in the foreground? (`natd -v')
>
> Not on the target machine but I did test it from home. It looks like NAT
> stops matching packets when the alias addr is provided; it lets them fall
> through to the local system, where they generally get 'connection
> refused'. I am going to try it without alias addresses for the default
> address (the first bank) and see if those work.
>
> I can't attach gdb to a running -g'd version of natd, it just segfaults.
> :(
>
This is a known problem, it is fixed in -STABLE:
dfr 1999/05/22 01:29:24 PDT
Modified files: (Branch: RELENG_3)
contrib/gdb/gdb solib.c
Log:
MFC: Problems with coredumps from static programs.
Revision Changes Path
1.3.2.2 +1 -1 src/contrib/gdb/gdb/solib.c
--
Ruslan Ermilov Sysadmin and DBA of the
ru@ucb.crimea.ua United Commercial Bank,
ru@FreeBSD.org FreeBSD committer,
+380.652.247.647 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990914192335.A3257>