From owner-freebsd-net Fri Jul 23 5: 5:39 1999 Delivered-To: freebsd-net@freebsd.org Received: from kweetal.tue.nl (kweetal.tue.nl [131.155.2.7]) by hub.freebsd.org (Postfix) with ESMTP id 7788F14E73 for ; Fri, 23 Jul 1999 05:05:28 -0700 (PDT) (envelope-from rombout@gewis.win.tue.nl) Received: from gewis.win.tue.nl [131.155.71.116] by kweetal.tue.nl (8.9.3) for id OAA24646 (ESMTP). Fri, 23 Jul 1999 14:05:12 +0200 (MDT) Received: (from rombout@localhost) by gewis.win.tue.nl (8.9.2/8.9.2) id OAA66696 for freebsd-net@freebsd.org; Fri, 23 Jul 1999 14:05:12 +0200 (CEST) (envelope-from rombout) From: Rombout de Backer Message-ID: <19990723140511.B64214@gewis.win.tue.nl> Date: Fri, 23 Jul 1999 14:05:11 +0200 To: freebsd-net@freebsd.org Subject: ARP Proxy with fake network Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, Situation: We have a link to the internet, together with a few other companies on a subnet (212.61.24.0). We want to filter all packages going into our company. We have eight IP addresses. We installed a FreeBSD box with IPFIREWALL with two network cards. One wired to the subnet and one wired into the internal network. The server is configured as IP address A, the clients as B, C en D (we have three clients at the moment). The first problem we encountered is that the router of the internet provider doesn't route the packages for B, C and D via A. Although the FreeBSD bridge-code could solve this (by bridging instead of routing), it is not a very neat solution in this case (we only want to pass IP traffic that is for us). The first thing we tried was to let the server fool the router of the internet provider by pretending that A was B, C and D using ARP proxy (``arp -s''). This failed because when B would request it's own IP address it would scream and disables it interface (Windows NT, sigh). Then we found choparp which enabled us to specifically announce the ARP reply on an internet interface and announce the IP address of the internet provider on the internal interface. The next problem we encountered was routing. Since the router of the internet provider and our clients were on the same subnet, our server didn't know where to route a packet. We fooled around with route's -interface and stuff like that, but we kept failing. By introducing a ``fake'' network (192.168.1.*), we were able to get routing into track. Not a very neat solution, but it seemed to work. We added a routing entry for every client to the fake network (e.g., route add A 192.168.1.10) and then we added a static arp entry in the arp table for the 192.168.1.10 address. Although A didn't know it was 192.168.1.10, the packet was delivered there (for IP A) and handled. The inner-network was now configured as 192.168.1.1, so FreeBSD understood which network card to use when routing. The clients are now using the internet via the firewall and they have no clue about the fake network. The migration only took place on the server. The only probleming remaining is that when a connection is made from the freebsd box, the connection comes from 192.168.1.1. Although this is not a problem (since A for instance will route back the message, via the ethernet address of the internet provider server, which is spoofed to our ip address) we would have liked that the fake network was never visible. Our question is how to accomplish this. Can the ``route'' problem be fixed, or can applications automatically use the ip address of the other ethernet card? Thanks, Rombout/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message