Subject: Re: Recent ipv6 changes and gif breakage
From: Ignatios Souvatzis <firstname.lastname@example.org>
Date: 01/27/2006 10:55:35
Content-Type: text/plain; charset=us-ascii
On Thu, Jan 26, 2006 at 08:48:48PM +0000, Martijn van Buul wrote:
> It occurred to me that Ignatios Souvatzis wrote in
> > Yes, but what outer address did you use for your view of your end of the
> > tunnel? The poster uses a public address - I can't quite see how this is
> > supposed to work, and he doesn't explain.
> I did, a few weeks ago ;), but a quick recap:
> My modem doesn't offer bridging, but it does offer a DMZ of some sorts.=
> My public IP is 220.127.116.11, and that's the official endpoint of the
> tunnel. (The other end being at 18.104.22.168). The private IP of my modem
> is 192.168.5.1. It *should* NAT all traffic to 192.168.5.2, but for some
> strange reason it fails to do so for IP protocols it doesn't know about
> itself (Including proto 41, aka gif). That traffic is still bridged to
> the inside network, and it's being transmitted with the ethernet address
> of 192.168.5.2 as target address, but the IP header isn't rewritten prope=
> it still reads "22.214.171.124" as destination. So in fact, it's doing a=
> bridge instead of a NAT, but only for proto 41. I initially added the
> appropriate alias to rtk0, my interface connected with the modem, but that
> didn't quite work out. Moving the alias to lo0 did.=20
> I tried putting back the alias to rtk0, but that didn't help. And I'm not
> convinced my slightly dodgy network setup is to blame - I see traffic com=
> in and out of my tunnel - just neighbourhood discovery seems broken.
Caution - rant follows.
|"Slightly dodgy"? Your network setup is so sick that I wonder how your
|machines survive. Do you understand know why reasonable people frown upon
Ok, seriously now:
Adding 126.96.36.199 to your _ethernet_ interface should work. Somehow you
have to convince your machine to accept that packet in the first place,
before gif can see it.
If it doesn't, maybe give your ethernet interface 188.8.131.52 as the
primary address and the internal address as the alias.
Adding that address to lo0 as an alias should confuse gif, as it's trying
to use an address on one interface and output the data through another.
Maybe you need to switch routing on for this to work.
Oh, yes, did you swithc routing on? (What does
sysctl net.inet.ip.forwarding say?)
If this still doesn't work, I guess you can use IPfilter to rewrite
proto 41 packets on your NetBSD machine so that gif can understand them.
You wold have to tell gif to use the internal address.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----