From owner-freebsd-questions Wed Jun 6 20:32:57 2001 Delivered-To: freebsd-questions@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id D2A0B37B405 for ; Wed, 6 Jun 2001 20:32:53 -0700 (PDT) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f574pls07623; Wed, 6 Jun 2001 23:51:47 -0500 (CDT) (envelope-from nick@rogness.net) Date: Wed, 6 Jun 2001 23:51:47 -0500 (CDT) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Doug Lee Cc: freebsd-questions@FreeBSD.ORG Subject: Re: Shared IP, real-time packet editing, or best offer...? In-Reply-To: <20010606222424.A4331@kirk.sector14.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 6 Jun 2001, Doug Lee wrote: > I want to do something a bit beyond NAT: > > MSN Messenger's audio protocol and at least the IRC DCC protocols I've > seen send a workstation's IP address inside the data section of a TCP > packet. When the workstation's address is NATed and private, this > translates to communication failure, since the unsuspecting machine at > the other end has no way to route a packet back to the workstation. > > I can think of two possible solutions to this: (1) sharing the public > IP such that the workstation believes it owns the address but really > only owns the address on certain ports, or (2) editing packets as they > go by and possibly triggering actions, such as firewall modification, > based on data patterns in packets. You can probably write something that does #2 [Some type of proxy gateway or divert socket app]. This is probably the best way to do it. #1 would be difficult. You would need 2 BSD machines (probably) in a setup like so: X.X.X.X --- BSD-1 --- 192.168.0.0/24 --- BSD-2 --- Real machine ^ ^ ^ ^ .1 .2 X.X.X.Y X.X.X.X Where X.X.X.X is the outside Address that you want to duplicate on your "Real Machine". On BSD-1, you have the public address of X.X.X.X and an "inside" address of 192.168.0.1. Then on BSD-2 you have an outside address of 192.168.0.2 and an inside address of X.X.X.Y. It doesn't matter what netblock you use on this segment, but it must be in the same network (directly reachable) to X.X.X.X. So let's say you have 28.28.28.1/32 for your public address of X.X.X.X. BSD-2's inside interface could be 28.28.28.2/24. Then you assign the 28.28.28.1 address to your "Real machine" changing your netmask to 255.255.255.0 (/24) to match your BSD-2's interface. If your app runs on port 6666 (tcp) You natd setups would look something like: On BSD-1: redirect_port tcp 192.168.0.2 X.X.X.X:6666 alias_address X.X.X.X On BSD-2: redirect_port tcp X.X.X.X 192.168.0.2:6666 alias_address 192.168.0.2 This is a horrid [spelling] work-around and I haven't tested it but it *should* work. It's actually going through 2 nat's, one on each machine. Certain things would not work, like trying to reach the Real 28.28.28.0/24 network from the inside. > > The `netsed' program looks somewhat promising as a solution to the > second idea, though I see nothing to indicate that it could be used to > trigger actions other than just packet modification (I haven't > finished reading though). Based solely on my limited understanding of > the state of modern firewall/router boxes for cable/DSL, I am under > the impression that the first idea is not unheard of. I would think > the first idea would really require the workstation to have two IPS on > its interface though: the normal private one, and the partly-owned > public one. I don't know if this will work or not. I've just installed it but there is really no manpage associated with it and the command-line syntax is not to in-depth. Nick Rogness - Keep on Routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message