From owner-freebsd-hackers  Tue Sep 26 21:34:50 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from wind.lcs.mit.edu (wind.lcs.mit.edu [18.31.0.82])
	by hub.freebsd.org (Postfix) with ESMTP id E631E37B422
	for <hackers@freeBSD.org>; Tue, 26 Sep 2000 21:34:37 -0700 (PDT)
Received: (from dga@localhost)
	by wind.lcs.mit.edu (8.10.2/8.10.2) id e8R4Ybn00067;
	Wed, 27 Sep 2000 00:34:37 -0400
Message-Id: <200009270434.e8R4Ybn00067@wind.lcs.mit.edu>
Subject: natd bug with pptp, hack fix, question
To: hackers@freeBSD.org
Date: Wed, 27 Sep 2000 00:34:36 -0400 (EDT)
Cc: dga@lcs.mit.edu
From: "David G. Andersen" <dga@lcs.mit.edu>
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

With natd+ipfw, I was setting up a front-end firewall for
a client.  The firewall has several real IP addresses
(we'll call them 10.0.0.1 and 10.0.0.2) and two
MS PPTP servers behind it.


              10.0.0.1
              10.0.0.2
World--------- | firewall | --------- PPTP-1  192.168.1.1
                                \---- PPTP-2  192.168.1.2

I setup the natd.conf file in the way one would expect:

redirect_proto gre 192.168.1.1       10.0.0.1
redirect_port  tcp 192.168.1.1:1723  10.0.0.1:1723

redirect_proto gre 192.168.1.2       10.0.0.2
redirect_port  tcp 192.168.1.2:1723  10.0.0.2:1723

[With or without the redirect_proto gre;  with the
 -current libalias, I would expect to perhaps not need it]

Anyway, to make a long story short, it doesn't work.  The
first PPTP server is reachable and happy, but the virtual
PPTP server on 10.0.0.2 is unreachable.  When natd sees
the first GRE packet, it calls

FindPptpIn(), which then checks:

    link = FindLinkIn(dst_addr, alias_addr,
                      NO_DEST_PORT, call_id,
                      LINK_PPTP, 1);

This check fails, and it falls back to a call to
FindOriginalAddress(alias_addr);

Two questions:

  a)  I'm not sure about the location of the call to
AddLink for for this connection in the PPTP aliasing
code, so I couldn't determine the right way to set
things up.

  b)  Shouldn't this also check to see if there's a default
      GRE relay host for this alias address?

One issue:

  I hacked my client's natd program in the interim to
AddLink inside FindPptpIn if it doesn't get a returned
link, and it works like a charm.  However, it's definitely
the wrong thing to do and only a temporary solution.
The fact that it works, however, suggests that this
should be something relatively straightforward for someone
with a clue about how libalias works to fix.

  Anyone?  I'm happy to fix it (though my client might
not like that. :-), but I'd love a bit of a hint about
the right way to address this within the libalias framework
before I blunder through making changes that won't be
accepted.

Thanks!

This is using the 4-stable natd and the libalias from -current.

   -Dave

{I'm not on -hackers at the moment, so if you could CC: me on
 a response, I'd appreciate it}.

-- 
work: dga@lcs.mit.edu                          me:  dga@pobox.com
      MIT Laboratory for Computer Science           http://www.angio.net/


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