3

I have a strange misconfiguration on my openvpn tap network.

Clients can connect and get there IP address in 192.168.42.x as intended, but after few seconds another address gets assigned to it, self-assigned this time (169.254.x.x).

The problem it creates is that the dns lookup resolves to the self-assigned ip (only on second try).

here is my server.conf content:

port 1194
proto udp
dev tap0

ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
ifconfig-pool-persist ipp.txt

server-bridge 192.168.42.254 255.255.255.0 192.168.42.100 192.168.42.200

keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

client-to-client

and my client configuration file:

client
dev tap

proto udp

remote vpn 1194
resolv-retry infinite
nobind
persist-key
persist-tun

ca ca.crt
cert node.crt
key node.key

ns-cert-type server
comp-lzo
verb 3

A little detail that might be interesting is that I don't bridge the server tap interface, as what I want is only client-to-client connections (the purpose of the vpn is to be able to administer a fleet of machines in different places/networks).

thanks.

EDIT:

I had similar logs as in this google group: https://groups.google.com/forum/#!topic/tunnelblick-discuss/u32yHzly9RA

2012-02-24 15:22:36 *Tunnelblick client.up.tunnelblick.sh: Sleeping for 0 seconds to wait for DHCP to finish setup.
2012-02-24 15:22:36 *Tunnelblick client.up.tunnelblick.sh: Sleeping for 1 seconds to wait for DHCP to finish setup.
2012-02-24 15:22:37 *Tunnelblick client.up.tunnelblick.sh: Sleeping for 2 seconds to wait for DHCP to finish setup.
2012-02-24 15:22:39 *Tunnelblick client.up.tunnelblick.sh: Sleeping for 3 seconds to wait for DHCP to finish setup.
2012-02-24 15:22:42 *Tunnelblick client.up.tunnelblick.sh: Sleeping for 4 seconds to wait for DHCP to finish setup.

Looks like disabling DNS in tunnelblick resolves this on the mac. So it looks like it might be more a problem on the dhcp part, as it keeps waiting for DNS, and appears to be adding a self-assigned IP when it doesn't appear.

Still have to have access to one of the Linux machines to check for a fix. I'll update here.

vitaminwater
  • 131
  • 4
  • I've hit about similar thing when bug was introduced in windows TAP driver - because of NDIS driver architecture change in Windows 8. Does your client config runs as service? With what privileges? What OSes do you have there? Where are logs? Where does it works and where not? – Michal Sokolowski Jun 24 '16 at 11:52
  • @MichalSokolowski It's only linux and macosx machines, default privileges (root). Logs don't show much except the fact that it doesn't receive any DNS config from the dhcp, which is expected, the vpn network is a dead end anyway. – vitaminwater Jun 25 '16 at 10:35
  • As long as you won't present requested data, I won't be able to help. I don't have my magic 8 ball today. – Michal Sokolowski Jun 25 '16 at 11:58
  • @MichalSokolowski Juste updated my question, and actually found a part of the solution (looks like it though), I'll update here once I got my hand on one of the linux machines (can't really take the risk to do it remotely) – vitaminwater Jun 27 '16 at 09:27

1 Answers1

2

169.254.x.x address is called Automatic Private IP Addressing (APIPA).

In order to prevent that from happening, add the following line to your ovpn config file.

ip-win32 ipapi

So the final config would like something like this:

client
dev tap

proto udp

ip-win32 ipapi
remote vpn 1194
...
user630702
  • 465
  • 6
  • 25