I'm trying to configure a connection using openvpn from a windows 7 client machine to a linux host. I'm using openvpn in the traditional routed mode using tap devices, and the configuration I'm using is basically one that has worked fine for me in the past for linux-linux connections. On the server I have:

lport 1198
dev tap
secret bubble.key
ping 10
verb 3
mute 10

On the client I have:

remote [my server's public ip address]
rport 1198
dev tap
secret bubble.key
ping 10
ping-restart 120
verb 3
mute 10

My problem is that every time the client side is restarted, it is initially unable to contact the server. However, when I send a ping from the server to the client, everything starts working. Other than leaving a ping process running on the server, I'm not sure how to make this work...

More info: suspecting an ARP issue, I've been looking into the ARP settings. The linux host has the following network info:

tap1      Link encap:Ethernet  HWaddr 00:ff:55:4d:06:47
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::2ff:55ff:fe4d:647/64 Scope:Link
          RX packets:45508 errors:0 dropped:0 overruns:0 frame:0
          TX packets:45318 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:3375338 (3.2 MiB)  TX bytes:3561021 (3.3 MiB)

But the windows machine seems to be picking up an incorrect physical address for it:

$ arp -a

Interface: --- 0xf
  Internet Address      Physical Address      Type          00-ff-51-1e-af-f3     dynamic          ff-ff-ff-ff-ff-ff     static            01-00-5e-00-00-16     static           01-00-5e-00-00-fc     static       ff-ff-ff-ff-ff-ff     static

Which is then corrected when it receives a packet from the remote end. However, every time I run 'arp -d', the physical address reverts to the same incorrect one. I'm not sure where it's getting it from. Any ideas?

Update: switching from 'tap' to 'tun' fixes the problem, but I'd still like to understand why it doesn't work correctly in 'tap' mode.


Hello i learned that enabling promisc mode on all level of interfaces on server helps speed up this process - however i noticed this bug also - it actually works over time - try pinging several adresses from windows over tap, and one by one they will be dicovered, but it will take time, faster way is to ping from servers, but it is not always possible. I'm searching for other solutions that actually manually update arp table- but it seems like bug in TAP driver or windows ARP updates. Strange enough, after estabilishing connection it works flawlesly. (i'm using TCP - maybe more hickups, but it is more stable - i'm raching 45 mbit download and 50 mbit upload which is way enough i guess)

  • 1
    In the time since I asked this question, I've had several other mysterious networking issues that can all be traced to ARP and other low level protocols. I've begun to suspect that my router doesn't handle broadcast packets all that well, which might account for the several times I've had ARP not working in several different scenarios, plus the fact that neither mDNS nor SSDP work reliably on my network. – Jules Feb 11 '14 at 8:28
  • Enabling promiscuous mode on all the interfaces is a bit of a rash decision that shouldn't be taken lightly. – Tom O'Connor Feb 11 '14 at 9:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.