Date: Wed, 19 Dec 2001 16:33:09 -0500 From: "Blake Crosby" <dev@samurai.com> To: "Forrest W. Christian" <forrestc@imach.com>, "Jim Flowers" <jflowers@ezo.net> Cc: <portmaster-users@portmasters.com>, <freebsd-isp@FreeBSD.ORG> Subject: RE: Infrastructure Design with Portmasters and FreeBSD/Zebra (long) Message-ID: <JAEEIJKIHAONENKPFCCPGENKCBAA.dev@samurai.com> In-Reply-To: <Pine.BSF.4.21.0112191352570.18716-100000@workhorse.iMach.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hmm I am pretty sure the rogers@home network here uses 10/8 network space for their internal routing: A traceroute from my box on the rogers@home network to yahoo.com (abridged): 2. 24.101.32.1 3. 24.112.249.1 4. 10.0.185.1 5. 24.7.74.29 6. 24.7.69.41 Notice that 10/8 ip address in there (there used to be more) Blake > -----Original Message----- > From: owner-freebsd-isp@FreeBSD.ORG > [mailto:owner-freebsd-isp@FreeBSD.ORG]On Behalf Of Forrest W. Christian > Sent: December 19, 2001 4:20 PM > To: Jim Flowers > Cc: portmaster-users@portmasters.com; freebsd-isp@FreeBSD.ORG > Subject: Re: Infrastructure Design with Portmasters and FreeBSD/Zebra > (long) > > > I'm going to be very specific about this: > > Using 1918 space as you have described is bad. Very bad. > > To make a long story short, if you use 1918 space, it will break things in > weird and unusual ways. The reason for this is a lot of providers discard > any packets with a source address of 1918. Certain internet protocols > require each router along the path to be able to reply with ICMP messages > with their own address. If they are in the 1918 space, these will most > likely be discarded causing the functionality which needs these to break. > > Most notably, this will break MTU path discovery which can cause a whole > set of other problems which I won't go into. It also will prevent ICMP > Source qwench messages which are used to provide for some additional flow > control by certain ip stacks. > > The only place to use 1918 space is behind a NAT box or on a network which > will never be connected to the internet. > > On Wed, 19 Dec 2001, Jim Flowers wrote: > > > Date: Wed, 19 Dec 2001 11:55:06 -0500 > > From: Jim Flowers <jflowers@ezo.net> > > To: portmaster-users@portmasters.com, freebsd-isp@FreeBSD.ORG > > Subject: Infrastructure Design with Portmasters and FreeBSD/Zebra (long) > > > > Our current ISP infrastructure has a head-end connection to the > Internet and > > a number of remote POPs at the end of point-to-point connections. The > > Internet routers are IRX-211s and the pop-connecting routers > are IRX-114s. > > Customer connections at the pops include dialup via PM3s and > point-to-point > > dedicated via fbsd routers. 5 subnetted class C address blocks are used > > including /30 on the numbered point-to-point links. Routing is ospf > > (Zebra-0.92a on fbsd). Additional Internet sources are being added to > > several of the POPs using BGP routing as are some inter-pop > telecom links > > with ospf. > > > > I am considering renumbering all of the interior (to the Internet) > > infrastructure subnets to RFC1918 private addresses, primarily > to promote > > security but also to reclaim public addresses. Customers, both > dialup and > > dedicated, would still have public addresses routed by ospf > over the RFC1918 > > infrastructure to allow full access to Internet services. Local servers > > that require access to the Internet connections would have > public addresses > > on their own network allowing connections to the Internet via > the RFC1918 > > infrastructure. Customers would also have the option to connect via a > > secured public subnet. > > > > I question that a PM3 with a private Ethernet interface and a public > > assigned address pool will work. I think connections would > just be routed > > by ospf instead of proxy arp so it would be OK. Is this correct? > > > > This layout also relies on a web proxy (squid) host with a > secondary public > > address on the RFC1918 subnetwork to allow http connections to Internet > > hosts and other cache servers. Eliminates loading router to unsecured > > public subnet that would result if the web proxy host were placed there. > > Seems a compromise to the concept though explicit filtering at > the IRX-211 > > could minimize the vulnerability. Opinions? > > > > I am also thinking of connecting all 3 subnets (private, public > and public > > secured) to a vlan segmented level 2 switch to take away > sniffing capability > > from a compromised host (mirrored to the MGMT host for management use). > > Will this introduce additional problems? > > > > Any other caveats? > > > > Alternate suggestions? > > > > Thanks. > > > > Fixed width charcter spacing ASCII map follow: > > > > POP layout > > > > ================= Internet > > | > > | ]--------> to previous POP (RFC1019) > > [IRX-211] [IRX-411]--------> to next POP (RFC1918) > > | | | > > | +--+--------+-------+-------+---- RFC1918 subnet > > | | | | | > > | [W/P] [R] [PM3] [R] > > | | | +--------> ptp > > | | Unsecure Customers (public) > > | | > > | +----------+-- unsecured public subnet > > | | > > | [W/P] [MGMT] [servers] > > | | | > > +------+---------+-------+---- secured (public) subnet > > | | | > > [servers] [PM3] [R] > > (secure) | +--------> ptp > > Secure Customers (public) > > > > IRX-211 and PM3 for unsecured network uses minimal filtering > > IRX-211 and PM3 for secured network uses maximal filtering > > RFC1918 addresses can only be reached from secure subnet > > Unsecure customers may use W/P (web proxy) > > Secure customers must use W/P > > Management from Internet requires first to connect to MGMT host > > Management by dialup to directly connected subnet only > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-isp" in the body of the message > > > > - Forrest W. Christian (forrestc@imach.com) AC7DE > ---------------------------------------------------------------------- > The Innovation Machine Ltd. P.O. Box 5749 > http://www.imach.com/ Helena, MT 59604 > Home of PacketFlux Technogies and BackupDNS.com (406)-442-6648 > ---------------------------------------------------------------------- > Protect your personal freedoms - visit http://www.lp.org/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-isp" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?JAEEIJKIHAONENKPFCCPGENKCBAA.dev>