"ET" sent me his config, and while I couldn't use it verbatim (as he had to mask out many IP addresses), I could reproduce the problem simply by copying the relevant bits over a default configuration.
The problem appears when a traffic shaper rule matches GRE traffic on the WAN interface (as in his case). m0n0wall has a kernel patch to work around an issue where packets that exit dummynet (after shaping) get NATed again. However, it turns out that the same workaround causes firewall processing on the PPTP VPN interface to be skipped for inbound packets that have gone through dummynet while they were still PPTP/GRE encapsulated (because ng_pptpgre doesn't create a new mbuf, but merely strips the GRE header, and thus preserves m_flags). This has two effects: a) firewall rules on PPTP VPN don't work (it's essentially a "pass all") *if* the traffic shaper catches GRE packets, and b) because of this, PPTP VPN clients cannot communicate with m0n0wall directly: since the inbound packet from the PPTP VPN client doesn't go through the firewall, no state table entry is created, and the reply from m0n0wall (ping, DNS etc.) is hence blocked.
This is actually quite a nasty issue, and I'm glad that we've found it - thanks for your help!
I've created 1.3b13-pre images with a kernel fix for this issue; I hope it doesn't break anything else, so it would be great if someone with a complicated config with lots of features, including IPsec (like "ET"
could give it a try.http://m0n0.ch/wall/downloads-local/generic-pc-1.3b13-pre.imghttp://m0n0.ch/wall/downloads-local/net45xx-1.3b13-pre.imghttp://m0n0.ch/wall/downloads-local/net48xx-1.3b13-pre.imghttp://m0n0.ch/wall/downloads-local/wrap-1.3b13-pre.img
(not digitally signed)