[ previous ] [ next ] [ threads ]
 From:  Brian <mono at ricerage dot org>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] PPTP Server with PPTP Clients Behind
 Date:  Sun, 15 Feb 2004 19:14:06 -0500
On Sun, 2004-02-15 at 17:55, Hilton Travis wrote: 
> Hi Ben,
> On Mon, 2004-02-16 at 07:06, Ben Carlisle wrote:
> > Folks,
> >    Just got m0n0 working and I love it (convert from shorewall on a
> Linux
> > machine). I am having one problem however. When I enable the PPTP
> server on
> > m0n0, my LAN clients from behind m0n0 cannot open VPN PPTP
> connections to
> > the outside world. If I disable the PPTP server, connections are
> opened
> > fine.
> > 
> >    I'd like to have my m0n0 machine as a PPTP server for road
> warrior-type
> > connections from the outside world, and allow PPTP from clients on
> the LAN
> > to outside PPTP servers. Can I do both?
> The reason you cannot do this is because when the PPTP Server is
> running
> on m0n0wall, it needs to use the same ports/protocols that need to be
> forwarded thru the m0n0wall if you want to get internal machines
> making
> PPTP connections.  The only way this could possibly work is if you had
> multiple public IPs, and utilize one for the PPTP Server, and another
> for the outbound clients.

I had originally mailed my reply directly to Hilton (while I may
understand firewalling concepts, mail clients are apparently too much
for me), and he had graciously responded. List members, please accept my
apology for being ridiculously silly. Below is the correspondence
between us:

Hi Brian,

> I'm not trying to be argumentative, but I doubt thats the case. Before
> discovering m0n0wall my firewall ran on a minimal Debian GNU/linux
> install, with both the poptop pptpd, as well as netfilter and pppd
> patches. pptpd acted as the PPTP server for inbound connections, and
> netfilter patches allowed the NAT'ed hosts behind it to connect to
> remote pptpd's. Granted this was accomplished through netfilter
> patch-o-matic voodoo, but it worked great.
> As for ports/protocols, again I'm pretty sure thats incorrect. On the
> external interface, one would need to allow port 1723 and GRE traffic
> inbound. On outbound initiated connections, one would need to make
> that GRE traffic wasn't munged by the NAT implementation. Outbound
> connections certainly wouldn't require 1723, but instead would
> on a "high port". 

It still uses protocol GRE in both directions, but yes, different ports
are used.  I've not had my coffee yet!  :)

> Now that I've actually thought that through enough to provide you with
> the above explanation, sounds more like ipfilter's "proxy"
> for particular protocols (ftp, irc dcc, etc, ad nauseum) getting in
> way.

Does, kinda, doesn't it.



Hilton Travis                   Phone: +61-(0)7-3343-3889
Manager, Quark AudioVisual      Phone: +61-(0)419-792-394
         Quark Computers         http://www.QuarkAV.com/
(Brisbane, Australia)            http://www.QuarkAV.net/

Open Source Projects:           http://www.ares-desktop.org/

Non Linear Video Editing Solutions & Digital Audio Workstations
 Network Administration, SmoothWall Firewalls, NOD32 AntiVirus
  Conference and Seminar AudioVisual Production and Recording

War doesn't determine who is right. War determines who is left