Connection via DotRas breaks ARP Cache

Jul 16, 2014 at 5:31 PM
Edited Jul 16, 2014 at 5:49 PM
I'm experiencing a strage problem that occurs oly when i connect via DotRas to a VPN Server:
When i connect via DotRas and send requests afterwards to a server (no matter if its http oder even XMPP), the server gets "blocked" and a connection is not possible anymore. This mostly occurs only in the next 60 seconds after the connect, requests after such a timespan are processed as normal. When i clear the ARP cache via "netsh interface ip delete arpcache", the problem gets solved in the most cases.
The hostname is actually resolved properly, since pinging the server works as expected. But the packets aren't send and only a "general error" appears.
Since the cleaning of the arpcache requires admin rights (which the application doesn't have in the most cases), this "bug" is fatal.

When i connect via the phonebook-file, the error doesn't occur.
I'm using windows 8.1, but the problem is the same at windows 7 and even XP.

If you need further information, i will do my best to provide them. Thanks for any suggestions!

EDIT: added some more detailed error description
Jul 18, 2014 at 2:53 AM
Edited Jul 18, 2014 at 2:54 AM
First time I've ever heard of this happening.

Is there any kind of network access protection (NAP) on the VPN server? It might be quarantining the connection, and causing the issue.
Is the "connection via the phonebook file" you mentioned using the same file that you're using with DotRas dialing the connection?

- Jeff
Jul 24, 2014 at 12:42 PM
Edited Jul 24, 2014 at 5:47 PM
Hey Jeff,

sorry for the late reply, i've been on vacation lately.

No NAP is running on the VPN Server and the "connection via phonebook file" is the file used in dotras.
I was able to reproduce the bug with another VPN service. The bug appears when you connect to any host while the connection is being established.

Code to reproduce the issue:
static void Main(string[] args)
            String phoenbookPath = Path.GetDirectoryName(Process.GetCurrentProcess().MainModule.FileName) +

            DotRas.RasPhoneBook book = new RasPhoneBook();
            // If empty, produce a PPTP entry
            if (book.Entries.Count == 0)
                RasEntry entry = RasEntry.CreateVpnEntry("vpnbooktest", "", RasVpnStrategy.PptpOnly,
                    RasDevice.GetDeviceByName("PPTP", RasDeviceType.Vpn, false));
                entry.Options.RemoteDefaultGateway = true;
                entry.Options.RequireChap = false;
                entry.Options.RequireMSEncryptedPassword = true;


            RasDialer _dialer = new RasDialer();
            _dialer.AllowUseStoredCredentials = true;
            _dialer.EntryName = "vpnbooktest";
            _dialer.PhoneBookPath = phoenbookPath;
            _dialer.PhoneNumber = "";
            _dialer.Credentials = new NetworkCredential("vpnbook", "2axusuFe");

            var activeConnection = RasConnection.GetActiveConnections();
            foreach (var t in activeConnection)

            // Send some requests while connecting
            new Thread(new ThreadStart(delegate
                WebClient wc = new WebClient();
                for (int i = 0; i < 1000; i++)

            // Dial!
           var handle=  _dialer.Dial();

Ping wird ausgeführt für [] mit 32 Bytes Daten:
Allgemeiner Fehler.
Allgemeiner Fehler.
Allgemeiner Fehler.
Allgemeiner Fehler.

Ping-Statistik für
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

C:\Windows\system32>netsh interface ip delete arpcache


Ping wird ausgeführt für [] mit 32 Bytes Daten:
Antwort von Bytes=32 Zeit=61ms TTL=61
Antwort von Bytes=32 Zeit=62ms TTL=61
The first requests should go fine while connecting to the VPN, then a timeout error occurs. When you ping, the "general error" appears.
Its also possible to avoid the thread and place the webrequest code right unter _dialer.DialAsync(). The same behaviour happens.

Any ideas so far?
Aug 20, 2014 at 7:55 PM
This sounds vaguely like an early cellular modem I was assigned to work with once - it would always require about a 1 second delay between actually being connecting and reporting that it had connected. So I waited on the DotRas event and then used Sleep(), because the manufacturer and the carrier seemed to have no inclination to provide more of a solution than that. I realize matters are not quite analogous, but perhaps this remark will provide a clue ...