Re: Half Bridge mode and multi-homed box
From: MattD.. (mattd145_at_gmail.com)
Date: 12/15/04
- Next message: Kris Kennaway: "Re: BSDI 4.3 Kernel API -> FreeBSD X.X Kernel API?"
- Previous message: Matthew Hale: "No boot loader, missing mount points"
- In reply to: jpd: "Re: Half Bridge mode and multi-homed box"
- Next in thread: jpd: "Re: Half Bridge mode and multi-homed box"
- Reply:(deleted message) jpd: "Re: Half Bridge mode and multi-homed box"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 15 Dec 2004 07:00:48 +0000
On Wednesday 15 Dec 2004 00:23, the whim of a few quarks and leptons to be
jpd for a while caused the following to be typed:
Sorry for the length. I couldn't snip too much without losing context.
> So... it translates PPPoA into ``native'' ethernet and takes care of
> ``logging in'' with the provider?
Exactly. The router takes all the authentication and link negotiation burden
from the machine and simply presents it with an Internet routable IP
address. In theory. :-/
>> Setting the router to half bridge mode does indeed replicate the WAN IP
>> to whatever is connected to the LAN port. Hooking my laptop up with only
>> one NIC and setting this to DHCP in rc.conf picks up all the information
>> and can immediately ping hosts on the big wide Internet. However, trying
>> the same on xl1 on the server, I get the IP of the WAN assigned to the
>> NIC, but no routing information.
>
> At this point I'm tempted to assume this is purely a dhcp issue, and I'd
> suggest firing up tcpdump to look at the two conversations. It could be
> that the server somehow doesn't ask for a default gateway. Do you have
> a defaultrouter= entry in your rc.conf?
I tried putting the default route that the laptop gets into rc.conf. Same
result, as was running route flush and adding the route manually. I even
got to the stage where I set the laptop up, ran netstat -rnf inet,
disconnected the router and fired the server up and had the output on the
laptop screen whilst I tried to replicate it on the server.
> Also, you can run a diff(1) on both /etc directories to see what the
> differences are. And inspect netstat -nrf inet output, of course.
Might be a good starting point. I'll do that.
>> The problem seems to be the way the router assigns the default gateway.
>> What it seems to do is give the client NIC the address of the WAN and
>> then adds 1 to the last octet of the IP and uses this as a pseudo gateway
>> IP, along with supplying the MAC of the LAN port (router) as a route for
>> this gateway IP.
>
> I'm not sure, but this could very well be how the provider sets it up.
> I'd probably not do that but I'm not your provider.
That's not the provider. The provider's gateway is on a completely different
subnet. I'm still trying to get my head around how the deuce you route an
address on the 82.x.x.x subnet through a gateway on the 204.x.x.x subnet. I
assume it's using PPP tunnels, which is probably where my half bridge is
falling down. My machine with the outside IP has no way of getting a packet
to the gateway without the modem's assistance via the PPP tunnel because
the gateway is on a totally different subnet. The machine also doesn't know
the modem can do this, or even that the modem is there. I assume that's why
the ADSL router does the "last octet plus one" trick for the gateway. So
why does it work on the laptop, this being the case?
>> xl1: Should be the WAN IP. At present, set up with an RFC1918 address and
>> doing two lots of NAT to enable the internal network to see the 'net.
>> natd seems happy with this, but I'm not.
>
> You really only need to do it once. I mean, if your internal network
> is 192.168.0.0/24 and the transit is 192.168.1.0/24 but the ``edge''
> (in this scenario the ethernet<->pppoa thing, I assume) does NAT on
> 192.168.0.0/23, or bigger, then you can route all you want on the
> inside, but you do not need to do extra layers of NAT. OTOH, if for some
> reason it cannot, you can give it an 192.168.0.0/24 address and have it
> do NAT on it, while your server sits on another 192.168.0.0/24 IP while
> it also bridges between your internal network and the ``edge''. Or you
> buy a cheap switch instead.
OK, this is what I've got at the moment. My external address is static and
has a PTR to my domain. I've disabled IPv6 on everything, just to be on the
safe side (I was running TSPC2 to get a /48 block).
The router is doing NAT from the external 82.x.x.x address via 10.0.0.2 to
10.0.0.1. Note NAT, not NAPT, it's port for port, which means I've also got
the router set so that 10.0.0.1 is the recipient of everything, a DMZ if
you like. There is nothing else, only the router and the server on this
subnet connected port to port via a crossover cable.
The server is running natd with this interface (tl1) as the target, along
with ipfw so only the ports I want to be seen in the big wide world are
open on 10.0.0.1 and the rest of the network uses 192.168.0.1 (tl0) as the
default gateway through a 3Com Superstack III managed switch.
So two lots of NA(P)T, one NAT to get anything from 82.x.x.x to 10.0.0.1 and
then one NAPT to allow traffic both ways from 10.0.0.1 to 192.168.0.0/24
(and the WLAN, of course, on ath0). At the moment it is working with this
setup as I wanted it to work, but the server is still blithely ignorant of
its real Internet address on the WAN, which isn't as neat as I'd like it
and screws up my sendmail setup to name just one problem. I was hoping that
half-bridge mode on the router was going to make the ADSL connection appear
to be just a WAN connection to the server, which indeed it does on the
laptop. The differences are these:
The server is a gateway. gateway_enable="YES" in rc.conf.
The server has multiple NICs, on different subnets. The laptop hadn't when I
first tried out half bridge.
The server is running dhcpd and BIND (and a myriad of other services).
The server is a Dual Xeon SMP box.
Hmm, look at that last one. I'm wondering if this could be an mpsafenet
issue now I type this, since I'm running 5.3-RELEASE and the xe0 adaptor on
the laptop is Giant locked and requires debug.mpsafenet=0 in loader.conf.
Or am I off at tangents? I've just read Robert Watson's post about
mpsafenet and various bits of the networking stack being Giant dependent,
along with the busdma-SMPng project page, and the more I think about this,
the more plausible it seems. I also think it might be a good idea to put
the 3Coms back in (see below). The tl driver isn't listed on there as done.
>> ath0: This is the wireless AP for me only. The laptops connect via this.
>> It's on 192.168.1.1/24 and is in hostap mode with 128 bit WEP enabled.
>
> Those things are pretty good at bridging, too, usually. I wonder if you
> can make the thing do dhcp on both wireless and wired lans in the same
> subnet. I think so. :-)
I wish I could. It would save me having duplicate lines in /etc/exports for
everything, not to mention making my firewall rules a lot simpler. Any
advice on this would be VERY helpful if you think it should be possible.
Last time I tried to bridge the ath0 to the xl0 (internal wired network
adaptor) I couldn't ping or communicate with the xl0 (now tl0) address,
although I could ping everything else on 192.168.0/24. Kind of an important
stumbling block, though, since DHCP is on this adaptor, along with all the
NFS, NIS, pop3, smtp and filtering proxy services. That's why I'm using
ath0 on 192.168.1.1 and not bridging. Perhaps this is another symptom? BTW,
I have swapped out the 3c905TX cards for the original Compaq Netelligent
NICS, TI ThunderLANs, which is why my adaptor names have changed. This
didn't solve anything, but reassured me it wasn't a hardware fault, but as
I said above, the xl driver is mpsafe, whereas the tl driver isn't.
>> There are no other interfaces. I did have xl1 picking up the WAN address
>> and aliasing as the RFC1918 address just so I could talk to the router,
>> but disabling this made no difference. Any ideas? More information
>> needed?
>
> I'm a bit unclear as to what your edge pppo[ea] thingy does, exactly,
> and what it can do. I'd investigate what goes on with the dhcp stuff,
> as while you say the machines run the same OS, something has to be
> different to make them behave differently with the same setup. If
> you can't find it, I'd like ifconfig, netstat (-nrf inet), rc.conf,
> dhclient.conf, and maybe tcpdump (-nevvvs 1500 -i $if port 67 or 68)
> output of what goes on with the dhcp negotiations, of both machines.
I will do that, as soon as I've slept, and post right back. Another
all-nighter, I'm afraid ;-)
Thanks for all the advice.
-- Radio glossary #33 M3 filter: Any American station that has "had the privilege".
- Next message: Kris Kennaway: "Re: BSDI 4.3 Kernel API -> FreeBSD X.X Kernel API?"
- Previous message: Matthew Hale: "No boot loader, missing mount points"
- In reply to: jpd: "Re: Half Bridge mode and multi-homed box"
- Next in thread: jpd: "Re: Half Bridge mode and multi-homed box"
- Reply:(deleted message) jpd: "Re: Half Bridge mode and multi-homed box"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
