Computers Can't Route Traffic to OpenVPN Gateway

[palswim]

I have successfully installed and configured OpenVPN as a (CentOS 6) server, as well as Windows and Linux clients. However, none of these clients can reach each other, and I'm wondering why OpenVPN doesn't configure its routing in the way I think it should (I'm sure it has a perfectly valid reason, but I just don't know it).

On Linux clients:

Code: Select all

> route -n
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.1.2.1        0.0.0.0         UG    0      0        0 wlan0
10.0.0.0        0.0.0.0         255.0.0.0       U     2      0        0 wlan0
192.168.0.1     192.168.0.13    255.255.255.255 UGH   0      0        0 tun0
192.168.0.13    0.0.0.0         255.255.255.255 UH    0      0        0 tun0

On Windows clients (only the entries which relate):

Code: Select all

> route PRINT -4
Network Destination        Netmask          Gateway       Interface  Metric
...
      192.168.0.1  255.255.255.255       192.168.0.5      192.168.0.6     31
      192.168.0.4  255.255.255.252         On-link        192.168.0.6    286
      192.168.0.6  255.255.255.255         On-link        192.168.0.6    286
      192.168.0.7  255.255.255.255         On-link        192.168.0.6    286

Any time I try to ping one client from another, I see the "Destination host unreachable" error. In my mind, at least one of these routes should use a 255.255.0.0 netmask, like I've configured in my "server.conf" file:

Code: Select all

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh1024.pem
server 192.168.0.0 255.255.0.0
ifconfig-pool-persist ipp.txt
keepalive 60 1200
tls-auth ta.key 0 # This file is secret
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
log-append  /var/log/openvpn.log

And a sample client conf file (Windows, Linux would look very similar):

Code: Select all

client
dev tun
proto udp
remote server.tld 1194
resolv-retry infinite
nobind
persist-key
persist-tun
# Omitting the certificate/key information
ns-cert-type server
tls-auth ta.key 1
comp-lzo
keepalive 60 1200
route-method exe
route-delay 2

What have I done wrong or omitted? (I also may have omitted vital information from the configuration files.)

[maikcat]

hi there,

simply add client-to-client directive to your server config

Michael.

[palswim]

simply add client-to-client directive to your server config

Exactly what I needed; thanks! I had a working configuration prior to my current one, but I guess I couldn't determine that I had omitted the "client-to-client" directive in my current configuration.

Do I need to do anything else (on the server) to enable the clients to respond to their hostnames? I have tried configuring the clients as "Mixed Node" clients (try "Broadcast" first, then use WINS), but they still don't respond to "ping clientname".

[maikcat]

hi there,

sadly the only workaround for name resolving to work (which is not openvpns issue)
is enabling wins on your server and use it to your clients

-or-

use dns infrastructure..

Michael.

[palswim]

hi there,

sadly the only workaround for name resolving to work (which is not openvpns issue)
is enabling wins on your server and use it to your clients

-or-

use dns infrastructure..

Michael.

Sorry to resurrect an old thread, but I had a question about what you said. Do you mean that in an OpenVPN network, I can only resolve client hostnames if the network has WINS or a DNS infrastructure? Or do you mean for any network?

If you meant this applied to any network, I have plenty of networks using Broadcast name resolution only, and it works fine.

If you mean this applies to OpenVPN networks, then the inability to resolve hostnames with the Broadcast method sounds like an OpenVPN issue.

[maikcat]

openvpn uses tun -or- tap interface to create tunnels.

Tun interfaces are layer 3 interfaces and *dont* pass broadcast/multicast packets

therefore using tun interface you do have name resolution problem which must
addressed using wins/dns/static name mapping.

clearly not openvpn weakness...

regards.

Michael.