From owner-freebsd-ipfw Thu Jan 24 21:56:14 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from femail22.sdc1.sfba.home.com (femail22.sdc1.sfba.home.com [24.0.95.147]) by hub.freebsd.org (Postfix) with ESMTP id B541737B416; Thu, 24 Jan 2002 21:56:06 -0800 (PST) Received: from stevehome ([24.81.145.39]) by femail22.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20020125055606.WZXV2359.femail22.sdc1.sfba.home.com@stevehome>; Thu, 24 Jan 2002 21:56:06 -0800 From: "Steve" To: =?iso-8859-1?Q?'Ramiro_V=E1zquez'?= , "'Ruslan Ermilov'" Cc: Subject: RE: Using ipfw to make a "Dynamic NAT depending of protocol L7" Date: Thu, 24 Jan 2002 22:56:02 -0700 Message-ID: <000001c1a564$f8df9740$0500000a@stevehome> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <002801c1a45c$ed273240$1500a8c0@corp.megared.net.mx> Importance: Normal Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Actually, from what I've read the best solution to all of these Microsoft producted NAT problems is "UPNP". New products like Windows XP Remote assistance, MSN messenger file/video all apparently support UPNP firewalls. If we could add UPNP code to NATD it would all be transparent to the user. Basically MSN messenger learns about a UPNP firewall on the network and asks the firewall what its real public IP will be so it can use that in the packet. If needed the firewall is also told what ports to handle for the return connection. I don=92t know a lot about UPNP but have done some reading on http://upnp.org and there is a testkit out (originally produced by Intel for linux) on sourceforge.net. There seems to be little talk of UPNP except many firewall vendors are promising it in future versions. It sounds like its going to be the only way to fix these NAT problems.=20 Steve. -----Original Message----- From: owner-freebsd-ipfw@FreeBSD.ORG [mailto:owner-freebsd-ipfw@FreeBSD.ORG] On Behalf Of Ramiro V=E1zquez Sent: Wednesday, January 23, 2002 3:26 PM To: Ruslan Ermilov Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: Using ipfw to make a "Dynamic NAT depending of protocol L7" OK, I going to make some tests and I'll tell you if I can make it. Thanks a lot! Ramiro. Megacable. ----- Original Message ----- From: "Ruslan Ermilov" To: "Ramiro V?zquez" Cc: Sent: Tuesday, January 22, 2002 11:26 AM Subject: Re: Using ipfw to make a "Dynamic NAT depending of protocol L7" > On Tue, Jan 22, 2002 at 11:19:27AM -0600, Ramiro V?zquez wrote: > > Hi, > > > > We work at a cable-ISP and we are using NAT & PAT to provide=20 > > enough IP > > Addresses to our customers. > > > > We have experienced problems with certains applications, mostly=20 > > with peer to peer applications like MSN Messenger. > > Some features like send files function don't work. > > We put a sniffer and discover that when one of our customer try=20 > > to send > > a file to someone out of our net does this: > > 1.- The application opens a port ( 6891-6899 ). > > 2.- Sends the IP of the machine ( the private IP ) and the port=20 > > that is > > listening. > > 3.- The another peer try to connect to the private IP and the=20 > > port that > > it had received. > > 4.- The connection fails. > > > > We modify a proxy to change the packet that the application=20 > > sends with > > the private IP and the local port to replace them for a public IP=20 > > and another port, then the proxy sends this changes to an=20 > > application that just > > maps or forwards the port that we sent to the peer outside to the=20 > > real IP > > and port of our costumer. > > > > This solution works and we going to begin with the test with=20 > > more connections, but maybe is not the best solution, one=20 > > disadvantage is that > > the costumer must to specify a proxy and it's a hard work. > > > > We think that if we could make this changes with ipfw or=20 > > ip-filters and > > then add a rule to natd or ip-nat to forward the port, it would be=20 > > more efficient. > > > > Then we can redirect the traffic of MSN to ipfw or ip-filters=20 > > and make > > all transparent to our costumers. > > > > We think that we can do this for the most important applications > > to solve this problem, and its very important because we use a lot=20 > > of PAT and > > many applications can't work with the complete features. > > > > Is it possible make this with ipfw ?? Is anybody working arround this > > ?? > > > > Any idea or comment would be helpful !! > > > If you know MSN protocol, it should be pretty easy to add the required > glue to libalias(3) to do the necessary payload stubs, etc., so that=20 > this works transparently through a natd(8) and/or ppp(8). > > > Cheers, > -- > Ruslan Ermilov Oracle Developer/DBA, > ru@sunbay.com Sunbay Software AG, > ru@FreeBSD.org FreeBSD committer, > +380.652.512.251 Simferopol, Ukraine > > http://www.FreeBSD.org The Power To Serve http://www.oracle.com=20 > Enabling The Information Age > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message