General Questions

This is my recent experience from Monowall's PPTP VPN server. It is not as stable as I would expect it to be.

Access to internal network is achieved SOMETIMES. Not never, not always, but sometimes. Resetting states, reconnecting etc. does not solve the issue. I double-checked any rule-based aspect, just to make sure I am not blocked at another level. All seem fine.

I would very much like to know if someone else has faced such issues, or I am plain crazy.

I'm going to vote for Crazy  

I use it all the time on 20 + firewalls (1.33, 1.34 and 1.8 beta) with all kinds of hardware and have zero problems.

Roy...

No i don't think You are crazy, an ISP between the two points of connection (client and server) might be doing some nasty traffic shaping or filtering. Also check the TCP state idle timeout to check if it's set too low under System>Advanced - but I don't think that's the case.

If You can, test Your VPN scenario in local controlled laboratory environment.

The problem remains. I have to disconnect, wait, reconnect to work this out. The strange thing is that it does not follow some kind of pattern. Sometimes I can connect to one internal server, sometimes to the other. As far as the ISPs traffic shaping is concerned, I don't think this is an issue. I have tried to access the production VPN server (the one we give to end users), which is located behind the firewall (also via PPTP) and never had any issues.

TCP idle timeout is set to 1800 seconds, I thought of that and tried to reset it to the default. No luck.

It is also worth mentioning the following three points:

1. VPN connection is ALWAYS established.
2. Access to monoWall web interface is ALWAYS succesful. This clearly indicates that the VPN channel is properly opened.
3. PPTP rules are set to Allow All. Also, I have the impression (but cannot state this for sure) that sometimes editing a rule and hitting apply has the side-effect of allowing some connections, even though the specific rule has nothing to do with those machines.

I really need some guidance on this. Thanks.

I think that the connection state is getting killed for inactivity at some point (node - router) in between the server and the client, including them too, mostly due to strict connection idle timeout expire values.
If it's not m0n0, and it's not the client problem then it might be some of the routers in between, anyhow try to enable sending of periodical (using small period) echo packages over the link, just to keep it alive.

I have tried to maintain keepalives. Still no luck. The packet filtering/firewall settings with their respective values in my ADSL router are shown below. Perhaps you or someone else could identify a setting that might cause my problems?
---------------
    Intrusion Detection Feature (all enabled)

    SPI and Anti-DoS firewall protection    
    RIP defect    
    Discard Ping To WAN Interface    
---------------
    Stateful Packet Inspection (all enabled)

    Packet Fragmentation    
    TCP Connection    
    UDP Session    
    FTP Service    
    H.323 Service    
    TFTP  Service    
-----------
    Fragmentation half-open wait: 10 secs
    TCP SYN wait: 30 sec.
    TCP FIN wait:  5 sec.
    TCP connection idle timeout: 3600 sec.
    UDP session idle timeout: 30 sec.
    H.323 data channel idle timeout: 180 sec.
-----------
    DoS Detect Criteria:

    Total incomplete TCP/UDP sessions HIGH: 300 session
    Total incomplete TCP/UDP sessions LOW: 250 session
    Incomplete TCP/UDP sessions (per min) HIGH: 250 session
    Incomplete TCP/UDP sessions (per min) LOW: 200 session
    Maximum incomplete TCP/UDP sessions number from same host: 30
    Incomplete TCP/UDP sessions detect sensitive time period: 1000 msec.
    Maximum half-open fragmentation packet number from same host: 30
    Half-open fragmentation detect sensitive time period: 10000 msec.
    Flooding cracker block time: 300 sec.

your DSL modem should be set for Bridged mode.  Then none of those settings apply.

Roy...

UPDATE: I have also tried a different modem, on a different location. Exact same behaviour. So it is my understanding that this is clearly a monowall issue. Even if I accept this is not a bug (which is probably the case), it seems that there are not many things to configure in monowall as far as PPTP is concerned.

Examining the log, I can see the following:

10:53:39.544202    OPT1    1.2.3.4, port 443    5.6.7.8, port 39013    TCP

Where 1.2.3.4 is the IP of a server that at the moment is inaccessible from VPN, and 5.6.7.8 is the IP of monowall WAN. This log entry is very strange for me , since there are OPT1 rules that should prevent this from happening. For example?

*    *    *    5.6.7.8    *

This rule has no meaning, but I included this to show that communication is clearly allowed towards 5.6.7.8. Still I get entries like the one above. Perhaps this has something to do with the main issue of this discussion. Any clues?

PS: Is there any way to configure any other monowall's timeouts, except the 'tcp idle timeout'?