From owner-freebsd-security@FreeBSD.ORG Sat May 10 06:18:04 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5024637B401 for ; Sat, 10 May 2003 06:18:04 -0700 (PDT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 835B543FD7 for ; Sat, 10 May 2003 06:18:03 -0700 (PDT) (envelope-from metrol@metrol.net) Received: from metlap (adsl-67-121-60-9.dsl.anhm01.pacbell.net [67.121.60.9]) h4ADI1J9122864 for ; Sat, 10 May 2003 09:18:02 -0400 From: Michael Collette To: FreeBSD Security Date: Sat, 10 May 2003 06:17:43 -0700 User-Agent: KMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305100617.44245.metrol@metrol.net> Subject: Down the MPD road X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2003 13:18:04 -0000 Well, after working through the various options it looked like MPD would be my best bet here. I've got it sort of working, but there's obviously some tweaky I'm missing here. Recap of the scenario: Full class C of static IPs segmented into 3 networks. Outside, DMZ, Inside. Trying to get remote Windows users through securely to the Inside. Remote users have dynamic IPs. What's working: MPD is running, and authenticating my test XP box via PPTP. No certificates or any IPSec involved here. I can hit boxes on the Inside really solid now. The probs: Apparently PPTP actually puts the remote machine IN the target network. Sorry, I'm still pretty green on this PPTP stuff. Works a good bit different than IPSec. Anyhow, once the remote box is connected all the connections to the rest of the Internet are now coming from behind the firewall. That'd be cool if it worked reliably. While connected, when I attempt to browse around the public Internet some pages just don't load, where others do. No rhyme or reason, and nothing showing up in my logging of all denied packets via ipfw. For example, I can hit CNN without a problem, then when I try news.google it never loads a page. I can hit the main Yahoo page, but any of their other sites won't go. Really odd. I'm not sure if I've got an ipfw or mpd problem at this point. I've tried a dozen different ways to open up ipfw a LOT while still keeping it reasonably closed. This thing is in production and all. If it'd help, I'll post the relevant rule list here. Here is what I'm running for an mpd.conf file. Both mpd.links and mpd.secret I'm guessing are okay due to their simplicity. ----------------------------------------------------------------------------- default: load pptp_client0 pptp_client0: new -i ng0 pptp0 pptp0 set ipcp ranges {InsideIF}/32 {AssignedIP}/25 set iface disable on-demand set iface enable proxy-arp set iface idle 3600 set bundle disable multilink set bundle enable compression set bundle yes crypt-reqd set link mtu 1440 set link no pap chap set link enable chap set link keep-alive 10 60 set link yes acfcomp protocomp set ipcp dns {InsideDNS} set ipcp nbns {NTServer} set ipcp yes vjcomp set ccp yes mppc # set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless set ccp enable mpp-compress ----------------------------------------------------------------------------- I've played with tweaking a number of these settings, but with the same basic glitchiness. Was hoping one of you folks swearing by mpd might be able to point out some goofball thing I did here. BTW, the ng0 interface has permissions to every darn thing in ipfw. That includes tcp, udp, icmp, and even igmp. I've run out of things to try here. Later on, -- "Outside of a dog, a book is man's best friend. Inside of a dog, it's too dark to read." - Groucho Marx