Date: 10 Dec 1997 17:30:55 +0100 From: Eivind Eklund <perhaps@yes.no> To: "Jamil J. Weatherbee" <jamil@trojanhorse.ml.org> Cc: hackers@FreeBSD.ORG Subject: Re: I seriously need some networking help Message-ID: <86ra7lw474.fsf@bitbox.follo.net> In-Reply-To: "Jamil J. Weatherbee"'s message of Thu, 4 Dec 1997 01:22:39 -0800 (PST) References: <Pine.BSF.3.96.971204010641.385B-100000@trojanhorse.ml.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"Jamil J. Weatherbee" <jamil@trojanhorse.ml.org> writes:
> Here is a diagram of what I want to do (if this is possible):
> I have not been able to get this configured:
>
> The ip addresses have been altered to protect innocent networks of
> unprotected wincrap 95 machines.
>
>
> service provider ------\
> |
> |
> Ascend Pipeline 50
> 123.123.62.161/27 (router0)
> |
> | <----- crossover cable
> (ed1)
> FreeBSD Firewall
> 123.123.62.162/27 (core)---(ppp0)------modem(remote user)
> (ed0) proxied to
> | ethernet
> |
> |
> Windoze ethernet 123.123.62.161-190/27
This one seems to be possible, but it will be somewhat hairy. Quick
version: Proxy ARP in both directions, direct interface routes (you
will probably not want to have any address assigned to the interfaces
if you want this to be transparent) and a kernel mod to stop
decreasing the TTL field.
(1) Do an interface route for all traffic to the ascend by
route add -host 123.123.62.161 -iface ed1
(2) Do an interface route for all traffic to the local network
route add -net 123.123.62.160 -netmask 255.255.255.225 -iface ed0
This will not conflict with the route to the Ascend, as the kernel
router select the most specific route available.
(3) Set up proxy arp resolution for 123.123.62.161 on the ed0
interface. This will be something like
arp -S 123.123.62.161 $(ifconfig ed0 | awk '/ether/ {print $2}') pub
(4) Add proxy arp for all the windows machines on ed1.
#!/bin/sh
END_ARP=$(ifconfig ed0 | awk '/ether/ {print $2}')
for ip in 163 164 165 166 167 168 169 170 171 172 173 174 \
175 176 177 178 179 180 181 182 183 184 185 186 \
187 188 189 190
do
arp -S 123.123.62.$ip $END_ARP pub
done
(5) Set IPTTLDEC in /sys/netinet/ip.h to 0. This will stop your
kernel from decreasing the Time To Live field. Thus, you won't
show up in traceroutes etc.
WARNING: TTL is a safety field to avoid routing loops. If you
disable this, you'd better be damn sure you don't
respect source routing and don't have anything else
that can cause a routing loop.
(6) If you're going to do this 'right' (hide the host and create a
completely transparent firewalling bridge), don't set an IP
address on ed0. This will, however, stop the firewall from both
accepting and creating TCP connections. If you need acceptance
only, you can do this by adding an alias of 123.123.62.162/32 to
lo0, and proxy-arp'ing for that address on ed0. This will allow
inbound but not outbound connections. (I'm not certain you'll be
able to do connections with the machines even if you set up an
interface address - you're proxy-arp'ing for them, anyway.)
No guarantees is given for the correctness of the approach above (with
the same constraint as below).
ppp0 is left as an exercise for the reader (unless the reader is
willing to pay me money to do the exercise, of course ;-)
BTW: I've been thinking of firewalls and routing lately. A worthy
project for Somebody would be to replace ipfw with a firewall
integrated with the routing code - they seem to be doing a lot of
duplicate work. It should also be possible to make the resulting
trees compile to an easily parsable format that can be implemented as
a mask/compare -> (change table position|route|deny|log)
where the mask/compare is done against 'a complete set of data about
the packet'. Extra tables should be possible to add input and output
on each interface.
If anybody suddenly feel an urge to do suchs a project, please contact
me. I have done some work on how to optimize this; it is fairly
simple to optimize spacewise, but not so easy to optimize for time (as
this depend on the number of packets matched by each rule, and both
negative and positive rules can be added).
BTW2: How is the general and core view on making such changes? Is the
routing code 'holy code', or are drastic changes possible? (The idea
above would more-or-less replace the entire implementation with a more
powerful scheme for the 'static routes' case; I guess it would be both
easy and best to write so it was only enabled on request, though)
Eivind.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86ra7lw474.fsf>