Date: Thu, 27 Sep 2001 08:11:22 -0600 From: Mike Porter <mupi@mknet.org> To: swear@blarg.net (Gary W. Swearingen), Jamie Norwood <mistwolf@mushhaven.net> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: 127/8 continued Message-ID: <200109271411.f8REBNH02164@c1828785-a.saltlk1.ut.home.com> In-Reply-To: <i5vgi5tx0h.gi5@localhost.localdomain> References: <20010924094048.X5906-100000@coredump.scriptkiddie.org> <20010926134253.A65444@mushhaven.net> <i5vgi5tx0h.gi5@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 26 September 2001 04:20 pm, Gary W. Swearingen wrote:
> Jamie Norwood <mistwolf@mushhaven.net> writes:
> That's it, but rambling on...
>
> I considered doing a bridging firewall so all segments could be on one
> (sub)network but meagerness of documentation discouraged an attempt.
>
> AFAIK, to do "correct" networking, my three network segments separated
> by a routing firewall require three separate networks while my
> ISP-assigned subnet supports only two sub-subnets.
>
As somone else mentioned, however, to do "correct" networking, the first
address and last address of *each subnet* are reserved. But I think there is
a way around what you are trying to do. (well, two ways, but one of them
isn't what you are trying to do, so I don't know if it counts.)
> I also tried setting it all up on 10.x addresses with public IPs aliased
> on the server and workstation; I might have just messed up. Should
> that work?
>
That should work, but implies NAT to do the "aliasing" Also the firewall
needs an external IP as well. (Yes, you can alias more than one IP to an
interface, however, IIUC, this affects the listening for packets, not the
sending of packets, packets sent out an interface receive the primary
interface address (somebody correct me if I'm wrong?). However, with a /29,
you could use a 1-to-1 NAT, which should eliminate any of the problems
typically associated with NAT. (in ipnat, you simply use the bimap keyword so
that all packets from the outside bound for a.b.c.4 get routed to the
appropriate machine (say 10.0.1.2, for the sake of argument) and packets
FROM 10.0.1.2 get translated to appear from a.b.c.4, but ports etc will
remain the same. Since no two machines will ever share the same IP under
this scheme, it will work fine, while hiding your intenal network structure
from "the world".
> I currently have addresses assigned like this:
>
> a.b.c.0 subnetwork (ISP-assigned)
> a.b.c.1 DSL router (ISP-assigned; not sure why I couldn't choose)
two reasons: they want to know your router's IP, so they can (attempt to)
connect to it to verify connectivity in the event that you call and complain
that you can't connect (if they can ping your router, it is on "your side" of
the network). And tradition. The "router" is usually the first available
address. (or sometimes the last) in a subnet.
> a.b.c.2 firewall's workstation interface
> a.b.c.3 workstation
> a.b.c.4 firewall's server interface
> a.b.c.5 server
> a.b.c.6 firewall's DSL router interface
> a.b.c.7 subnetwork broadcast (ISP-assigned)
>
> The following is the only thing I've blundered upon which works on the
> workstation (and server). (It's considerably worse on the firewall.)
>
yes, becase your firewall is also trying to route.
> $ netstat -nr
> Destination Gateway Flags Refs Use Netif
> Expire 127.0.0.1 127.0.0.1 UH 0 334
> lo0
>
> $ ifconfig xl0 a.b.c.3/29 [IIRC, /30 works too; 31 or 32 don't]
>
> $ netstat -nr
> Destination Gateway Flags Refs Use Netif
> Expire default a.b.c.2 UGSc 0 0
> xl0 127.0.0.1 127.0.0.1 UH 0 334 lo0
> a.b.c.0/29 link#2 UC 1 0 xl0 =>
>
> At which point I can ping firewall but no further. I wish it didn't
> auto-add the route, but, oh well; it makes some sense.
>
The problem is that in your scheme, in order to pass from one subnet to the
other, it must use the gateway. HOWEVER, it will only send a packet to the
gateway, if it is outside of the interface's netmask. So setting the
interface to a.b.c.3/29 means it considers all of the packets to be on the
local subnet, and will attempt to connect directly to any other machine. Of
course, since only the firewall is directly connected, that is the only one
that will work. (well, pinging an outside address, say, your ISP, should
work, unless the firewall is blocking ICMP), becuase that is OUTSIDE your
/29, thus will try to use the gateway. The trick should be to use a /32
netmask, so that ALL addresses are considered non-local, and delivered to the
gateway. Though you might have to use /31. The other thing you need to do,
though, for this to work is set the broadcast address for each interface. I
may be wrong here, but I *think* you can set this to an arbitrary value.
Without the correct broadcast address, at least unless you have manual static
routes set up in the firewall, packets won't find their way back.
> Then I delete the subnet route and add one for a.b.c.2/31:
>
> Using "route add a.b.c.2/31 -interface xl0" gives:
> a.b.c.2/31 link#2 UCSc 0 0 xl0 =>
> which routes as desired.
>
> (Using "route add a.b.c.2 -interface xl0" gives:
> a.b.c.2 <xl0's MAC> UHLS 0 0 lo0
> which is hardly what I want and doesn't route as desired.)
>
> Unfortunately, doing "ifconfig xl0 down; go fishing; ifconfig xl0 up"
> puts back the a.b.c.0/29 route, breaking my routing.
>
This is becuase you already have the /29 netmask for xl0; if you change the
xl0 netmask ("ifconfig xl0 netmask 255.255.255.252" as well as changing the
rc.conf info) ifconfig xl0 up will bring back the correct (/31) family.
> If I start with:
> ifconfig xl0 a.b.c.2/31
>
> I get from netstat:
> Destination Gateway Flags Refs Use Netif
> Expire default a.b.c.2 UGSc 0 0
> xl0 127.0.0.1 127.0.0.1 UH 0 334 lo0
> a.b.c.2/31 link#2 UC 1 0 xl0 =>
>
> which looks pretty good (except Flags), but doesn't ping past the firewall.
>
> Thanks again for your interest.
>
Again, you are having conflicts with your subnets and your routing. You need
to either get enough addresses to support a "real" subnet (including the two
"dead" addresses per net), use bridging, or use NAT.
One of the reasons there is little documentation on bridging, at least in
FBSD, is that in FBSD all that is required is "gateway_enable=YES" in
rc.conf. (you might need a kernel config tweak, I don't recall offhand. If
you are running ipfw or ipf, then you should already have whatever kernel
tweaks you need). With gateway_enable=YES, packets appearing on one
interface, get popped out the other interface (at least they did for me)
unless blocked or NAT'ed by your firewall ruleset. This lead to me suddenly
flooding my subnet with 192.168 packets by mistake at one point configuring
my own home network. (which uses NAT because I have a /32 address. <(}:)
This *should* allow everythng to work as your existing setup, using /29 for
your netmask, and everything talk to each other without fancy routing.
naturally, of course, you will want to configure your firewall rules so that
packets from workstation to server don't go out to your DSL link, and clutter
up your upstream bandwidth.
Your only other choice is to go with NAT, which as previously mentioned, you
have enough addresses to use 1-to-1 NAT, which will eliminate MOST of the
problems associated with it.
mike
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109271411.f8REBNH02164>