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
Michael Collette wrote:>[..snip good stuff..] >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. >[..more snipping..] Ok, I saw these problems too.. Remember that the vpn'd client's data is coming through the firewall, to the ng0 interface, and then leaving from there (when "surfing the net"), so you will have to have NAT set up (of some sort) and make sure your rules are open enough to allow the firewall to send packets from the ng0 interface on out and have them natted.. Some of your pages are probably loading from a cache, and not others... also, you may want to add these lines to mpd.conf: set iface enable proxy-arp set iface mtu 1440 I found it fixed all my odd problems that I was having with XP clients.. Eric
On Saturday 10 May 2003 09:17, Michael Collette wrote:> 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.Here is where we descend into Windows-bashing. For some STUPID reason, when a Windows box connects to a VPN via PPTP, the Windows box's default route is adjusted to go through the VPN connection. This is fortunately fixable (Windows has a ROUTE command), but it requires your users to have half a clue: route delete 0.0.0.0 route add 0.0.0.0 mask 0.0.0.0 gateway <ISP gateway> metric 1 route add [InsideNetwork] mask [InsideMask] gateway [far end of VPN tunnel] metric 1> 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.That would help, undoubtedly. One thing that I did (using my FreeBSD box as an mpd client to a Windows RAS box) was this: ${fwcmd} add check-state ${fwcmd} add pass all from any to ${vpnbox} keep-state That made it possible for me to VPN in from FreeBSD. You may need to add some similar stateful rule for the other direction, so that all packets destined to the outbound machines are just let through, period (because you don't know their IP addresses in advance). That may be too wide open; someone else can comment. Another thing you could try is to explicitly pass all out over ng0.> [...mpd config...]I didn't see anything glaringly obviously wrong there. -- Chris BeHanna Software Engineer (Remove "bogus" before responding.) behanna@bogus.zbzoom.net Turning coffee into software since 1990.
> > Here is where we descend into Windows-bashing. For some STUPID > > reason, when a Windows box connects to a VPN via PPTP, the Windows > > box's default route is adjusted to go through the VPN connection. > > This is fortunately fixable (Windows has a ROUTE command), but it > > requires your users to have half a clue: > > > > route delete 0.0.0.0 > > route add 0.0.0.0 mask 0.0.0.0 gateway <ISP gateway> metric 1 > > route add [InsideNetwork] mask [InsideMask] gateway > [far end of VPN > > tunnel] metric 1 > > I cannot test this right now, so it is quite probable that you are > right, but couldn't this be controlled by the Properties >> Networking > >> Internet Protocol (TCP/IP) >> Properties >> Advanced >> General >> > >> Use default gateway on remote network?Yes, this checkbox allows to NOT route all the traffic to the VPN server. No need of 'route delete, route add ...' scripts. oc
En un mensaje anterior, Michael Collette escribi?:> 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.Looks like a MTU problem. I suggest you ping with different packet sizes and see which is the smallest size that doesn't get throught. Some web servers use the Don't Fragment bit on, and packets get discarted. If the application you are interested in works right, maybe it be worth to made some batch on the XP side to alter the routing table so the default route doesn't point to the VPN. Good luck. Fernando.