Manuel Kasper wrote:
> On 16.01.2005 14:23 -0500, William Arlofski wrote:
> 
> 
>>Manuel, not sure if you have seen this or my other posts regarding
>>this issue. I am curious to hear your thoughts. The whole thread
>>between me, myself and I is quoted below. :)
> 
> 
> I've had a look at your problem description, and while it's already a
> bit late in this part of the world for sharp thinking, I'd say the
> following behavior applies in your case:
> 
> When you define static routes on an interface, m0n0wall installs
> non-stateful rules to pass all traffic between the statically routed
> subnets and hosts on the subnet of the given interface itself. This
> had to be implemented because some people with complicated network
> structures needed it, and using stateful rules for traffic from and
> to the same interface (which only has to pass through m0n0wall
> because it may not be possible to define static routes on every
> client) would be inefficient. However, I have recently decided that
> this feature is too dangerous if used improperly (there's been at
> least one example of somebody who defined static routes even if there
> was absolutely no reason for it), so the next beta version will come
> with an option to enable it (and with default to disabled).
> 
> Your problem is probably that the PPTP client subnet lies within your
> LAN subnet. As such, if a packet from 192.168.1.0/24 with destination
> 192.168.100.16/28 comes in, it first matches a static routing bypass
> rule (which specifies 192.168.100.0/24 as its destination) and is
> therefore let in without creating a state table entry. However, since
> FreeBSD routing then decides that there's a more specific route for
> that particular packet (through the PPTP tunnel), it doesn't go out
> through the LAN interface (where it would have been permitted by a
> matching static routing bypass rule), but instead gets blocked by
> ipfilter when it is sent out through the PPTP tunnel because there's
> no state table entry for it.
> 
> You have three options:
> 
> 1. Use a different subnet for PPTP clients (yes, I know that the
> webGUI and manual suggest using part of the LAN subnet for it, and
> proxy ARP will normally ensure it works, but it's only for the
> convenience of people with simple setups that want PPTP clients to
> appear like normal LAN hosts)
> 
> 2. Wait for the next beta release that will come with an option to
> enable/disable the static routing bypass
> 
> 3. Comment out the corresponding lines in etc/inc/filter.inc (~378 -
> 408).
> 
> HTH,
> 
> Manuel


Manuel... Thank you for a very complete explanation of the cause of my 
woes, as well as several options to resolve them.

Any word (official or unofficial) as to a possible release date for the 
beta that will take care of this?  :)


Bill Arlofski
waa dash m0n0wall at revpol dot com