On Tue, 22 Jun 2004, Martin Holst wrote:
> Hi Fisch!
> 
> Try allowing fragmented packets from LAN to WAN. 
> I had to do this to get a Cisco VPN client running behind m0n0wall.
> ("Allow fragmented packets" is a checkbox option under firewall rules).

That's unrelated.  And it would probably be unnecessary if ICMP errors
were getting through properly so that PMTU Discovery could work.

> -----Original Message-----
> From: fisch [mailto:fisch at conne dash island dot de] 
> Sent: 21. juni 2004 15:15
> To: m0n0wall at lists dot m0n0 dot ch
> Subject: [m0n0wall] pptp-client behind m0n0
> 
> hi,
> I can't connect from LAN to an oustide PPTP-Server, I allowed GRE from
> WAN -> LAN and from LAN -> WAN, but I can't connect. The PPTP-Client
> config is ok - it works when direct connected to WAN.

Doesn't help when it doesn't know *where* on the LAN to send it. :-)

On Wed, 23 Jun 2004, fisch wrote:

> that isn't the point - I found the problem:
> 
> situation [192.168.1.0/20 = LAN]:
> 1) reboot m0n0wall
> 2) connect with client (192.168.1.100) to the outside-pptp-server -
> working
> 3) disconnect vpn
> 4) connect with client (192.168.1.111) to the outside-pptp-server -
> not working
> 
> all incoming pptp-traffic from the outside-pptp-server is always [until
> a m0n0wall-reboot] send to the client who connected first
> 
> ok, problem found but how to resolve?

Write a PPTP Proxy. :-)

Seriously, PPTP has *major* problems with NAT.  Not only are there issues
with getting the GRE packets directed properly, but also the protocol
forbids more than one control connection between any two client/server
machines, and NAT makes *all* your machines look like one.

If you only need to use *one* machine on your LAN as a PPTP client or
server, then you can get around it by setting up PPTP redirection on
m0n0wall pointing to that machine.  This was intended solely for directing
*incoming* PPTP sessions, but can be used for outgoing ones as well.

					Fred Wright