From owner-freebsd-isp Wed Dec 19 13:29:26 2001 Delivered-To: freebsd-isp@freebsd.org Received: from workhorse.iMach.com (workhorse.iMach.com [206.127.77.89]) by hub.freebsd.org (Postfix) with ESMTP id 8304437B405 for ; Wed, 19 Dec 2001 13:29:18 -0800 (PST) Received: from localhost (forrestc@localhost) by workhorse.iMach.com (8.9.3/8.9.3) with ESMTP id OAA18861; Wed, 19 Dec 2001 14:20:06 -0700 (MST) Date: Wed, 19 Dec 2001 14:20:06 -0700 (MST) From: "Forrest W. Christian" To: Jim Flowers Cc: portmaster-users@portmasters.com, freebsd-isp@FreeBSD.ORG Subject: Re: Infrastructure Design with Portmasters and FreeBSD/Zebra (long) In-Reply-To: <013b01c188ad$ea3bc570$22b197ce@ezo.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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 > 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