Date: Fri, 23 Jul 1999 14:05:11 +0200 From: Rombout de Backer <rombout@gewis.win.tue.nl> To: freebsd-net@freebsd.org Subject: ARP Proxy with fake network Message-ID: <19990723140511.B64214@gewis.win.tue.nl>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990723140511.B64214>