Ok, this one is a little tricky.

I already have in use a nice syste mcomposing of a 1100AH in a data center and a 450G at my core office, bunding with nth 3 internet links over PPTP - no problems there. I now have a satellite location that is regularly used (like every day).

I work on a virtual workstation in the data center and was so far logging into the data center firewall (windows based) via PPTP to access my company network. Works and worked like a charm.

I today tried to switch that over to using a site tosite pptp link with a /24 network, so that I dont have to log into the company network from windows all the time Also because we will soon deploy some hardware voip here... and i want Qos and "always on" vpn.

The problem: performance is sluggish. This is a 750 -> 1100AH pptp link, using one dsl link. packets come through nicely, 26ms delay, but remote desktop is quite painfull.

The two mangling rules (MSS to 1420) are visible on both sides (total 4 rules) - but I still think this could be an ordering / fragmentation problem? Can it? Anyone an advice?

Surfing works mostly, just remote desktop is a lot more sluggish than with the windows integrated vpn. And I want to solve that

It is very likely a fragmentation issue. Fragmentation of real time protocols causes slow down even when the fragmentation occurs in working fashion. Now you don't get immediate feedback from the RDP server, but have to wait until the second fragment arrives and has been reassembled.

Rarther than rely on MSS mangling try setting the MTU on your desktop and server NICs to something lower than the link minus all VPN headers so that natively the packets won't be fragmented. Try again. If that works better either leave it, or make sure you have MTU path discovery working through the entire path.

It is very likely a fragmentation issue. Fragmentation of real time protocols causes slow down even when the fragmentation occurs in working fashion. Now you don't get immediate feedback from the RDP server, but have to wait until the second fragment arrives and has been reassembled.

Rarther than rely on MSS mangling try setting the MTU on your desktop and server NICs to something lower than the link minus all VPN headers so that natively the packets won't be fragmented. Try again. If that works better either leave it, or make sure you have MTU path discovery working through the entire path.

Ok, but then why do I not have this issue when I connect directly with windows to the mikrotik in the data center (and RDP from there)? The same fragmentation would occur, or? (on the packets coming back to me).

Again:
Computer -> windows vpn -> dsl -> mikrotik -> server = perfect
Computer -> Mikrotik -> dsl -> Mikrotik -> server = sluggish as hell, close to unusable.

I definitely do not wan to change MTU settings on a server nic because some stupid issue down the line for a single workstation. I rather fix the issue instead of the problem. Does Mikrotik have serious problems with fragmentation?

Have you found a working solution?
We have same problem.

I have the same experience as described in this topic and I found the reason.

My test environment of PPTP Lan2Lan:
RB750GL -> RB1200, it causes very slow response to remote desktop.

when I use direct Windows PPTP -> RB1200, there are no problems.

I tried to switch PPTP encryption off (interface/pptp-client profile=dafault) and problem disappeared. So I suppose there is not enough CPU power to encrypt data going through PPTP VPN. I will try to change RB750GL with RB450G and do later next tests....

no, problem is packet reordering / reassembly I believe. with encryption it is very bad because it has to resync/rekey encryption. Someone should packet sniff both ends and compare to see if packets are not in same order when they are received. same issue with 2 powerful routers.

Possibly but sadly not solvable with Mikrotik not implementinng MLPPP properly (i.e. also server side). It seems they willfully ignore this part (i.e. the amount of people putting various links together for different reasons and with the will to load balance them) and I may have to put up some money and replace my 1100 with some other manufcacturer at least on the hub (as the Mikrotik is a MLPPP client). MLPPP does sfix a lot of problems, including packet markings for routing and their total inflexibility (i.e. the need to run complex scripts to change routing when one link is down, which is getting more and more likely wihth the numbers of links one adds).

I would really like Mikrotik to get their act together here, but then hope dies last - my Mikrotik will likely be EOL before someone at Mikrotik puts that at a higher priority than garbage bin.

Is the PPTP tunnel using MPPE128-Stateful encryption?