Archive for September, 2008

Phishing filter makes internet slow

September 30, 2008

Switching the Microsoft Phishing Filter to automatic makes web browsing (at least firefox) about 5 times slower than usual, taking about 10 sec to start up and display google. When I looked into task manager, McAffee virus scanner was blamed for using 50% CPU time. When either phisihing or McAffee were switched off, everything was fast. I decided against phising. I do not now whether this is enabled by default.


Microsoft Windows Vista Service Pack 1 VPN Problem

September 29, 2008

I had a problem after installing Windows Vista Service Pack 1:

I connect to the internet through ADSL (via a VPN) to my internet provider. To tunnel through the firewall around my office in the university network, I used another VPN, tunneling through the provider’s one. However, after SP1 installation this stopped working, while both VPN worked individually (i.e. through the providers VPN to the open internet, and from the open internet using the universitys VNP through the firewall). Some info from helped me to understand what is going on: Some firewall/router on the way does not relay fragmented TCP packets. Information at helped me to force Vista to use small packets: set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery to 0.

Now everything works.

Sept 09

No, unfortunatly I was wrong. Some pages (e.g. my universities homepage do not load through the fixed vpn. Web search brought me to, and I did

Netcfg -u MS_L2TP
Netcfg -u MS_PPTP
Netcfg -l %windir%\inf\netrast.inf -c p -i MS_PPTP
Netcfg -l %windir%\inf\netrast.inf -c p -i MS_L2TP

undoing the regedit change before. This allowed a vnp connection, but not for

Sept 10

Finally, I found a suitable solution for me: I do no longer use the UniVPN, but I use a proxy through ssh tunnels: see

However, it would be better if vpn would work…

Jan 24 2009

I have wasted more time, using netmon and other funny tools, and came closer to the root of the problem: apparently, for the vpn connections, the mtu (maximum transfer unit?) auto detection does not work – but not from my side, but from the univie vpn server! I can connect to through both an ADSL access by aon, and also through a A1 mobile phone used GPRS modem, in any case, the server sends larger fragments (close to 1500 bytes) than the connections can handle. I get only the second, smaller fragment.

If I ping from my laptop to a computer behind the univie firewall through the vpn, below a certain packet size the packets come back regularly, above the mtu found by my computer they are sent fragmented, but come back as one bigger fragment. Above a certain size, the returned packet becomes so large that it becomes fragmented – I get only the second, smaller fragment!

If I ping from inside the univie firewall to my laptop, packets below a certain size are echoed correctly (and seen by the netmon on the laptop), above this size they disappear without notice, nothing visible at netmon, and above another larger size they report fragmentation (if the corresponding ping option is used).

The problem has to be eihter in the univie vpn server which determines the mtu wrongly, and/or in the vista SP1. The latter is suggested by the fact that the SP1 installation destroyed the vpn fully, but the remaining problems may have existed before.

I will contact the univie helpdesk.