Thanks very much for the reply.
On 01/15/2013 01:25:50 PM, Daniel Hartmeier wrote:
> On Tue, Jan 15, 2013 at 09:46:37AM -0600, Karl O. Pinc wrote:
>
> > Something that's not mentioned that
> > comes to mind is ICMP redirection. (Without thinking
> > about it a lot it seems like it should be a good candidate.)
> > However when I tried ICMP redirection on OpenBSD
> > years ago I couldn't get it to work. Never looked to see why,
> > or whether it's been fixed since. Or, I might have been doing
> > something wrong. If anyone can send a clue my way
> > I'd appreciate knowing more.
>
> An ICMP redirect, if it is honored by a client, does not mean "if you
> want to talk to external-server, connect to proxy-on-local-network
> instead", but "if you want to reach external-server, route through
> next-hop-on-local-network".
Yes, when I tried it some time ago it was in the context of routing.
>
> The difference is that the reaction will not change the destination
> IP address, but the destination MAC address. Its really the same as
> if
> you added a temporary host route on the client.
>
> The proxy will simply ignore the IP packet for a foreign IP address
> sent
> to its MAC address (like a default gateway that has IP forwarding
> disabled).
I was thinking that the way to use icmp redirects in a "reflection"
setting is to assign a second IP address to the webserver, the server's
public IP address, and, on the router use the internal address
of the webserver as the gateway in a route statement designating
a route to the external address. The router would then issue icmp
redirects and packets would be delivered from the lan to the webserver.
The webserver, having a second IP address, would respond. However
I did not think the whole process through since you could
need additional foolery on the webserver to force it to send
all outbound packets from the LAN IP number -- or at least
that's something you'd always have to ensure.
The advantage
is that 2nd IP numbers on interfaces and adding a route
are easy configuration changes to make. The big disadvantage
is that you're messing around in the bottom part of the
network stack to solve a problem higher up in the stack,
and so it's a kludge that you don't want to hand over
to the random "next guy" who will maintain the network.
I always go for the split-horizon dns setup. It's
obvious what's happening and there's only one place where
the functionality is maintained.
>
> OpenBSD ignores ICMP redirects by default, you can enable it with
> sysctl
> net.inet.icmp.rediraccept, if you want to try. The security risk is
> that
> someone on the local network could send you ICMP redirects for
> various
> destinations (like DNS server), for a man-in-the-middle attack.
FYI, FWIW.
I was not trying to get OpenBSD to respond to icmp redirects, but
to get it to issue icmp redirects. I don't recall messing with a
sysctl, but I also don't see a security disadvantage in
a router issuing icmp redirects since that's what they're supposed
to do. That does not mean there's not a sysctl I should have
frobbed, but I'd hope it'd be a different systcl from the one
involving responding to icmp redirects. Looking at the
list of sysctls in sysctl(8) nothing jumps out.
Thanks again for the reply.
Regards,
Karl <k...@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
