Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
ifconfig 192.168.0.16 255.255.255.240
secret bubble.key
ping 10
verb 3
mute 10
route 192.168.2.0 255.255.255.0 192.168.0.17

On the client I have:

remote [my server's public ip address]
rport 1198
dev tap
ifconfig 192.168.0.17 255.255.255.240
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:192.168.0.16  Bcast:192.168.0.31  Mask:255.255.255.240
          inet6 addr: fe80::2ff:55ff:fe4d:647/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          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: 192.168.0.17 --- 0xf
  Internet Address      Physical Address      Type
  192.168.0.16          00-ff-51-1e-af-f3     dynamic
  192.168.0.31          ff-ff-ff-ff-ff-ff     static
  224.0.0.22            01-00-5e-00-00-16     static
  224.0.0.252           01-00-5e-00-00-fc     static
  255.255.255.255       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 192.168.0.16', 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.

share|improve this question

1 Answer 1

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)

share|improve this answer
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 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 at 9:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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