could you solve this? Which version of m0n0wall are you running?
I seem to have the same problem and a look into netstat -rn
(http://m0n0/exec.php) shows that the route is not in the routing
table any more after the pptp tunnel got reconnected. A click on apply
changes in the static route settings seems to fix it.
To met it looks like m0n0 does not resetablis the routes for the pptp
interface after the interface comes up again automatically.
On Wed, Feb 7, 2007 at 11:47 AM, Tim Korves <tkml at cluster dash worxx dot net> wrote:
> Hi Roy, hi all,
> why the hell I should do it that way? Both, m0n0 and this DD-WRT thing, do
> have an integrated PPTP server which could be used... I use the m0n0 as the
> PPTP server for the DD-WRT to connect to. That's not the problem so far.
> The problem is the routing, nothing more, nothing less... And the problem is
> not on the DD-WRT box, it's on the m0n0 box, which seems to loose the
> knowledge of how to reach the DD-WRTs Subnet after a reconnect of that
> The configuration is as follows:
> m0n0: PPTP-Server, PPTP-IP 10.2.0.1, Routing to 10.3.3.1/29 via 10.2.0.16
> DD-WRT: PPTP-Client, PPTP-IP 10.2.0.16, Routing to 220.127.116.11/27 via
> If I do a traceroute from my subnet to the clients one (without reconnect),
> I get the following:
> 18.104.22.168 -> 22.214.171.124 (m0n0) -> 10.2.0.16 -> 10.3.3.3
> If the tunnel, for some reason, goes down and up again, the routing is as
> 126.96.36.199 -> 188.8.131.52 (m0n0) -> ... Nothing, m0n0 tries to route
> these packets to the external interface
> A traceroute from DD-WRT to the m0n0 box:
> 10.3.3.3 -> 10.3.3.1 (DD-WRT) -> 10.2.0.1 -> 184.108.40.206
> After reconnecting, it looks like this:
> 10.3.3.3 -> 10.3.3.1 (DD-WRT) -> 10.2.0.1 (where it stucks and gets no
> reply, due to the m0n0 problem routing the packets to the external
> I hope, this is better for understanding..
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch