buggy server re-directors? buggy NATs? Too much RFC 1918 traffic on the net!
Greg A. Woods
woods at most.weird.com
Fri Feb 26 19:40:42 UTC 1999
I've been seeing a growing amount of traffic of various sorts from
various public internet sites that has a source address in an RFC 1918
In some cases because I have servers running multi-homed on
administrative LANs which use these private networks, and because I've
installed filters to ensure traffic isn't coming from the wrong nets on
the wrong interfaces, this is even causing some services and requests to
fail. (Eg. source quenches coming from private nets where even if the
filters didn't exist the desired effect is not achieved.)
I'm also seeing a growing number of requests on a couple of my
transparent web cache machines that seem to be directed at hosts in RFC
1918 private networks -- i.e. it would appear as though the URLs refer
either directly to private networks, or perhaps some domain names used
in publicly accessible URLs resolve to point at private nets.
I'm almost tempted to try and implement a DNS proxy that'll refuse to
allow any responses from foreign nameservers to contain RFC 1918
addresses (and of course ensure that my internal DNS is authoritative
for all the necessary in-addr.arpa zones).
I suspect what's happening is that people are putting load-balanced
servers behind service re-directors and are running these servers on RFC
1918 private networks in hopes that the re-director will do the
appropriate NAT. Unfortunately most of these re-directors are not yet
sophisticated enough to work as full proxies, and they often fail to
properly translate associated packets, such as related ICMP traffic.
(As has been amply evidenced by the extremely common failure of Path-MTU
discovery from several such load-balancing devices.)
In cases where I can identify the owners of the errant servers from my
filter logs and/or from simple tcpdump traces I do attempt to contact
them. However I'd rather try a more preventative approach, perhaps by
making this issue more widely known, and perhaps by educating vendors
and implementors of devices that might be causing these problems of what
mistakes they might be making.
I'm interested in exchanging information about these issues with other
operators and in trying to track down and identify devices that might be
letting some such private traffic slip through, and of course in helping
to find and implement fixes to these problems.
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods at acm.org> <robohack!woods>
Planix, Inc. <woods at planix.com>; Secrets of the Weird <woods at weird.com>
More information about the NANOG