--L1EIGrW/+75u5Nmw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 04, 2005 at 10:55:58AM +0000, Patrick Welche wrote:
> On Fri, Mar 04, 2005 at 11:40:25AM +0100, Quentin Garnier wrote:
> > > They are on the same segment.. vlan3 is on 192.168.192/20 which inclu=
des
> > > 204 and 205. Does this matter though? It seems the redirect is fired,=
 just
> > > sideways..
> >=20
> > Your network geometry is somewhat special.
> >=20
> > 204.6 is trying to reach 205.130 through 204.62, all of them being on t=
he
> > same LAN segment.
> >=20
> > So I guess you specifically added a route on 204.6 to make it use 204.62
> > instead of directly reaching 205.130.  Am I right?
>=20
> Yes you are :-)  Actually most machines are on 204/24, and the servers
> were on 205/24. Now we need a /20, so moved the servers to 0/20, leaving
> the 204/24 boxen on essentially 204/20, otherwise known as 192/20. So,
> 204.6 is just using its old gw 204.62. At that point we can say
> "redirect 205/24 server to 0/20"

Ew.

> > If so, the real question is whether IPF should pick up the packet before
> > the stack sends a redirect for it or not.
>=20
> I don't think so..

The redirect is perfectly legitimate, in the case there was no IPF
whatsoever.  The problem is the packet shouldn't reach the point where
a redirect packet is sent receiving the initial packet.

> > Reading source makes me think it should pick up the packet, so for some
> > reason IPF doesn't work.
>=20
> That's my impression, and it seems the redirect happens, its just that
> it seems to be redirected to its source address :-/

The redirect is fine.  Just think a little bit more about it, or get
some sleep.

> > ipnat -l does list the rules?  is ipf active?
>=20
> yes and yes..

Does IPF creates NAT entries for the packets?  I.e., does ipnat -l shows
entries for those packets?

> > > (In the meantime things are working with a nasty DNS hack instead..)
> >=20
> > Well, the route addition is nastier IMHO.
>=20
> Well, it was more of a "route left alone and not disturbed" ;-)

The problem is your network configuration is not consistent.  E.g., the
broadcast address is not the same everywhere.  This is clearly kludgy.

On another note, I really wonder why you want to use 205.130 as the
destination address, but meanwhile:

1.  not want the hosts to reach it directly, _in order to_
2.  redirect it to somewhere else.

Honestly, that feels completely messed up :)

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--L1EIGrW/+75u5Nmw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQihCadgoQloHrPnoAQK+EAgAy4BcvZtxYWJa1jkMXzdf04u0LYleS8yM
n3wlbPbyplmNVNdXsH4kmb/FbDAykfbuI9SBX1wYPqPtZ/b14Sb96rCe5ClisQ93
aMtw7kzzGX3h4GYAzsCBysPFwBgVZHz7JaSY35aG2foIcOJqaBc9qCKPWhoGeQz2
AzAG5RTiywaLnVdKlgbVTh+kauoQDXds58j+6qracR5evYv88Mc5sCJMuVvuipgD
l2oYeLuvxCtKDh2NEzfNzXIwh51G2gvYSczqKmCaXLqAGNV0R+hH+N6b8MrbeYMR
BTXe63H/QE87Ud+z4bOXV2S77KtzcfBUUHk2Uh3steGsBYleNFtRPg==
=Xil1
-----END PGP SIGNATURE-----

--L1EIGrW/+75u5Nmw--