Date: Wed, 19 Dec 2001 14:39:42 -0700 From: "Jeremy Buckner" <jeremy@cableaz.com> To: <isp@FreeBSD.ORG> Subject: Re: Infrastructure Design with Portmasters and FreeBSD/Zebra (long) Message-ID: <002f01c188d5$ad40c800$4396f13f@caz> References: <JAEEIJKIHAONENKPFCCPGENKCBAA.dev@samurai.com>
next in thread | previous in thread | raw e-mail | index | archive | help
We use RFC1918 here for our routing too, and yes it saves public address space, but I agree with Forest that you should only do it behind NAT or isolate it completely from the world. Otherwise you are asking for the head-ache you will get. Jeremy Buckner ----- Original Message ----- 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> Sent: Wednesday, December 19, 2001 2:33 PM Subject: RE: Infrastructure Design with Portmasters and FreeBSD/Zebra (long) > 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 > 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?002f01c188d5$ad40c800$4396f13f>