From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 26 19:27:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7A9C37B401 for ; Sat, 26 Jul 2003 19:27:02 -0700 (PDT) Received: from pgh.nepinc.com (pgh.nepinc.com [66.207.129.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1A8343F75 for ; Sat, 26 Jul 2003 19:27:01 -0700 (PDT) (envelope-from durham@jcdurham.com) Received: from jimslaptop.home.jcdurham.com (18.gibs5.xdsl.nauticom.net [209.195.184.19]) by pgh.nepinc.com (8.11.4/8.11.3) with ESMTP id h6R2R2u84966; Sat, 26 Jul 2003 22:27:02 -0400 (EDT) (envelope-from durham@jcdurham.com) From: Jim Durham Organization: JC Durham Consulting To: Yar Tikhiy Date: Sat, 26 Jul 2003 22:26:55 -0400 User-Agent: KMail/1.5.2 References: <200307251349.38413.durham@jcdurham.com> <20030726074239.GB61353@comp.chem.msu.su> In-Reply-To: <20030726074239.GB61353@comp.chem.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307262226.56003.durham@jcdurham.com> cc: freebsd-hackers@freebsd.org Subject: Re: NATD and Address Redirection X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: durham@jcdurham.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jul 2003 02:27:03 -0000 On Saturday 26 July 2003 03:42 am, Yar Tikhiy wrote: > On Fri, Jul 25, 2003 at 01:49:38PM -0400, Jim Durham wrote: > > The procedure we used was to alias a 2nd public address to the > > outside interface and use a redirect_address statement in > > natd.conf to redirect connections to the new public IP to the > > inside machine. > > Just a remark: If this 2nd public IP is already routed to your > gateway, you don't need to add it as an alias for your gateway's > outside interface. But you really need to if the latter interface > is on a broadcast network and must do ARP to attract packets > destined to the 2nd public IP specified to natd. Ok... it's sitting on the back side of a Cisco on a class C public. It doesn't sound like this would prevent anything from working in any case. > > > This doesn't seem to be symmetrical. You can ping the inside > > machine from outside using the new address and if you connect > > outwards from the inside machine, the outside world sees the > > connection as coming form the new public IP. However, a test > > running VNC server on the inside machine and connecting from > > outside does not work. You can connect to the inside machine and > > it sees mouse and keyboard, but the virtual screen does not work. > > It seems that the connection works properly redirecting inward > > but not outward. VNC disconnects in about a minute. > > Could you check if TELNET, HTTP, or SSH from the outside world to > the inside machine works? The problem may have to do with VNC > protocol peculiarities preventing it from working through NAT. > (However, the VNC FAQ claims VNC will work through NAT.) Well, that was my suggestion to my partner. All the inside machines are M$ workstations, so no connectable services running on them That's why we installed VNC. I suggested that we get a *nix box on the inside network that we can actually *do* something useful with 8-; . To further thicken the soup. This is not the only client system with a problem like this. There's another LAN client back of the NAT on a FreeBSD box that needs to run a piece of software that connects to some database system that figures out the most efficient routing for carrying loads on a semi trailer. We were running this guy very happily on an ISDN connection and using the NAt built into the PPP client. We tried to put him on a system hanging off a T1 line using natd and never got it to work. I did lots of tcpdumps on that using both the PPP nat and NATD and couldn't see any difference! However it worked just fine with the nat in PPP client, but not NATD. So, there may be a clue there. Another user is trying to run yahoo chat through NATD and no go, even with a redirect_address to her computer. I believe this also works on the PPP machine with the ISDN line, but not on NATD. So, my question is "What's the difference"? Is it different handling of icmp or something of that sort? -- -Jim