Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Multiple NAT alias addresses

0 views
Skip to first unread message

Doug White

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
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.
Does natd support multiple alias addresses, or am I missing something
obvious?

This is a production situation so doing test runs for logs is difficult.
I can get more info in ~30 minutes, but if someone can note any
inconsistencies that would be great.

Doug White
Internet: dwh...@resnet.uoregon.edu | FreeBSD: The Power to Serve
http://gladstone.uoregon.edu/~dwhite | www.freebsd.org

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

Ruslan Ermilov

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
On Mon, Sep 13, 1999 at 05:48:11PM -0700, Doug White 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?
Have you tried to run it in the foreground? (`natd -v')

> Does natd support multiple alias addresses, or am I missing something
> obvious?
>

Definitely supports!

BTW, what version you are on?


--
Ruslan Ermilov Sysadmin and DBA of the
r...@ucb.crimea.ua United Commercial Bank,
r...@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

Doug White

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
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.

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

> > Does natd support multiple alias addresses, or am I missing something
> > obvious?
> >
> Definitely supports!
>
> BTW, what version you are on?

3.2-RELEASE.

Doug White
Internet: dwh...@resnet.uoregon.edu | FreeBSD: The Power to Serve
http://gladstone.uoregon.edu/~dwhite | www.freebsd.org

To Unsubscribe: send mail to majo...@FreeBSD.org

Ruslan Ermilov

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
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
r...@ucb.crimea.ua United Commercial Bank,
r...@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

Doug White

unread,
Sep 14, 1999, 3:00:00 AM9/14/99
to
On Tue, 14 Sep 1999, Ruslan Ermilov wrote:

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

Hm, rev. 1.21 of natd.c is worrisome:

1.21 Tue Sep 7 15:34:12 1999 UTC by ru
CVS Tags: HEAD
Diffs to 1.20

Config file parser changes:

- Trailing spaces and empty lines are ignored.
- A `#' sign will mark the remaining of the line as a comment.

Reviewed by: Ari Suutari <a...@suutari.iki.fi>

Perhaps the parser is skipping my redirect_port lines?

> 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

Hm, I'm using the default divert rule 'divert 8668 all from any to any via
fxp0' instead of grabbing specific traffic.

Very odd. I'm going to adjust the configfile so that it has no comments
or blank space. Can you send me your file exactly as you wrote it?

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

argh :(

Doug White
Internet: dwh...@resnet.uoregon.edu | FreeBSD: The Power to Serve
http://gladstone.uoregon.edu/~dwhite | www.freebsd.org

To Unsubscribe: send mail to majo...@FreeBSD.org

Ruslan Ermilov

unread,
Sep 15, 1999, 3:00:00 AM9/15/99
to

--mojUlQ0s9EVzWg2t
Content-Type: text/plain; charset=us-ascii

Yeah, I committed this change after one guy had the problems with
redirect_port's not happening. He had `#' after `redirect_port' line,
and natd(8) silently ignored it. But you said that it works for you
without specifying publicIP, so this shouldn't be the case here.

> > 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
>
> Hm, I'm using the default divert rule 'divert 8668 all from any to any via
> fxp0' instead of grabbing specific traffic.
>

I understand. My rules look so, because I have another natd(8) (production)
running on my outside interface, so I grabbed only those packets that were
sufficient to experiment with your config file.

[...]


> Very odd. I'm going to adjust the configfile so that it has no comments
> or blank space. Can you send me your file exactly as you wrote it?
>

I just copied your config file from your original posting, see attached.
But PLEASE MAKE SURE you have no trailing whitespaces at the end of
your redirect_port rules!


Later,


--
Ruslan Ermilov Sysadmin and DBA of the
r...@ucb.crimea.ua United Commercial Bank,
r...@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

--mojUlQ0s9EVzWg2t
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="natd.cf"

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

--mojUlQ0s9EVzWg2t--

Krzysztof Krawczyk

unread,
Sep 15, 1999, 3:00:00 AM9/15/99
to
Hi,

Could someone say me, why the maximum packetsize in ping command is 8184
(ping -s 8184)? If I want to do a bigger packetsize than this i got
message like this:

tepsa:cys:/home# ping -s 65000 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 65000 data bytes
ping: sendto: Message too long
ping: sendto: Message too long
ping: sendto: Message too long
ping: sendto: Message too long
ping: sendto: Message too long
^C
--- 127.0.0.1 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss

Is there any way to bypass this limit? Should I recompile my
kernel/ping.c?


Cys - Krzysztof Krawczyk
IRC on DALnet: #polska #polcafe #wroclaw

c...@for.lames.access.is.denied.cx

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
"What sane person could live in this world and not be crazy?"
-- Ursula K. LeGuin
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Justin C. Walker

unread,
Sep 15, 1999, 3:00:00 AM9/15/99
to
> From: Krzysztof Krawczyk <c...@denied.cx>
> Date: 1999-09-15 13:12:21 -0700
> To: hac...@FreeBSD.ORG
> Subject: ping: sendto: Message too long
> In-reply-to:
> <Pine.BSF.4.10.990913...@resnet.uoregon.edu>
> Delivered-to: freebsd...@freebsd.org
> X-Sender: c...@tepsa.lame.pl
> X-Loop: FreeBSD.ORG

>
> Hi,
>
> Could someone say me, why the maximum packetsize in ping command
is 8184
> (ping -s 8184)? If I want to do a bigger packetsize than this i got
> message like this:
My guess: this is a "socket buffer size" issue. There should be
two ways around this:
- change the code to have 'ping' set its socket buffer sizes based
on the requested size
- use 'sysctl' to change the system's default send/receive buffer
sizes (see net.inet.raw.maxdgram, net.inet.raw.recvspace).

Naturally, I haven't tried this, or eyeballed the code, so treat
this with some caution.

Regards,

Justin

--
Justin C. Walker, Curmudgeon-At-Large *
Institute for General Semantics |
Manager, CoreOS Networking | Men are from Earth.
Apple Computer, Inc. | Women are from Earth.
2 Infinite Loop | Deal with it.
Cupertino, CA 95014 |
*-------------------------------------*-------------------------------*

Assar Westerlund

unread,
Sep 15, 1999, 3:00:00 AM9/15/99
to
Krzysztof Krawczyk <c...@denied.cx> writes:
> Could someone say me, why the maximum packetsize in ping command is 8184
> (ping -s 8184)? If I want to do a bigger packetsize than this i got
> message like this:

Look at the sysctl variable `net.inet.raw.maxdgram'.

/assar

Doug White

unread,
Sep 17, 1999, 3:00:00 AM9/17/99
to
On Wed, 15 Sep 1999, Ruslan Ermilov wrote:

> > - Trailing spaces and empty lines are ignored.
> > - A `#' sign will mark the remaining of the line as a comment.
> >
> > Reviewed by: Ari Suutari <a...@suutari.iki.fi>
> >
> > Perhaps the parser is skipping my redirect_port lines?
> >
> Yeah, I committed this change after one guy had the problems with
> redirect_port's not happening. He had `#' after `redirect_port' line,
> and natd(8) silently ignored it. But you said that it works for you
> without specifying publicIP, so this shouldn't be the case here.

Ah, ok.

An update:

I set up a test config at work with some spare boxes. I found that if you
specify an aliasIP that is the primary alias address (as determined by the
-n or -a options), those redirections will be ignored. Others continue to
work. I don't know why they weren't working on the real box, I may had
made a mistake there.

So this file is wrong:

interface fxp0
redirect_port 10.0.0.1:ssh 128.1.1.1:ssh
redirect_port 10.0.0.2:ssh 128.1.1.2:ssh

But this correct:

interface fxp0
redirect_port 10.0.0.1:ssh ssh
redirect_port 10.0.0.2:ssh 128.1.1.2:ssh

There is some logic in natd to handle the wrong case so that it is
equivalent to the right case, but that logic may be flawed.

> I just copied your config file from your original posting, see attached.
> But PLEASE MAKE SURE you have no trailing whitespaces at the end of
> your redirect_port rules!

I'll be sure to keep the whitespace pollution down.

Doug White
Internet: dwh...@resnet.uoregon.edu | FreeBSD: The Power to Serve
http://gladstone.uoregon.edu/~dwhite | www.freebsd.org

To Unsubscribe: send mail to majo...@FreeBSD.org

Ruslan Ermilov

unread,
Sep 17, 1999, 3:00:00 AM9/17/99
to
On Thu, Sep 16, 1999 at 11:25:53PM -0700, Doug White wrote:
[...]

> An update:
>
> I set up a test config at work with some spare boxes. I found that if you
> specify an aliasIP that is the primary alias address (as determined by the
> -n or -a options), those redirections will be ignored. Others continue to
> work. I don't know why they weren't working on the real box, I may had
> made a mistake there.
>
> So this file is wrong:
>
> interface fxp0
> redirect_port 10.0.0.1:ssh 128.1.1.1:ssh
> redirect_port 10.0.0.2:ssh 128.1.1.2:ssh
>
> But this correct:
>
> interface fxp0
> redirect_port 10.0.0.1:ssh ssh
> redirect_port 10.0.0.2:ssh 128.1.1.2:ssh
>
> There is some logic in natd to handle the wrong case so that it is
> equivalent to the right case, but that logic may be flawed.
>
You know, natd(8) is not guilty, this is a bug in libalias(3) :-(
I have made a patch for this and yet another bug and will send my
patch for review to Brian Somers and Eivind Eklund.

Please let me know if you would like to test these patches, and
THANK YOU VERY MUCH for digging this out, there was a cool hacking!


Cheers,


--
Ruslan Ermilov Sysadmin and DBA of the
r...@ucb.crimea.ua United Commercial Bank,
r...@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

Doug White

unread,
Sep 20, 1999, 3:00:00 AM9/20/99
to
On Fri, 17 Sep 1999, Ruslan Ermilov wrote:

> You know, natd(8) is not guilty, this is a bug in libalias(3) :-(
> I have made a patch for this and yet another bug and will send my
> patch for review to Brian Somers and Eivind Eklund.
>
> Please let me know if you would like to test these patches, and
> THANK YOU VERY MUCH for digging this out, there was a cool hacking!

I would be happy to. I still have the test environment.

Someone restarted the firewall and it included my changes (no address for
the default alias IP), and it's working perfectly. FreeBSD to the rescue
once again!

Doug White
Internet: dwh...@resnet.uoregon.edu | FreeBSD: The Power to Serve
http://gladstone.uoregon.edu/~dwhite | www.freebsd.org

To Unsubscribe: send mail to majo...@FreeBSD.org

0 new messages