client-to-client routing issue

[rhyas]

All,

I've searched a bunch and can't seem to find my exact issue anywhere. I'm hoping it's a simple thing I'm missing. I've been using OpenVPN for years using a single client to the server. I'm now trying to add another client, and I want to be able to do client-to-client routing.

The first client, and the server, are Linux. The new, 2nd, client is Win7. All of them were updated to 2.2 as part of my trying to make this work.

I can get everything connected, and when I have client-to-client commented out, I can see the server and access resources on it, but I can't see the other client, or access any of that client's networks. When I enable client-to-client, I get the opposite behavior. I can access all the other client's networks, but I lose connectivity from both clients to talk to anything on the server. There are no firewalls active on any of the hosts.

Is there something I've missed in a FAQ or something that something special has to happen? everything is using tun devices. I'm just curious if there's something else I need to set when I do client-to-client to still allow client-to-server at the same time. Here are the configs:

CLIENT 1:

Code: Select all

dev tun
remote vpn3 443
proto tcp
client
ca ca.crt
cert Office.crt
key Office.key
comp-lzo
persist-key
persist-tun
verb 3
log openvpn.log

CLIENT 2:

Code: Select all

client
dev tun
proto tcp
remote vpn3 443
resolv-retry infinite
nobind
persist-key
persist-tun
ca C:\\Users\\user\\OpenVPN\\ca.crt
cert C:\\Users\\user\\OpenVPN\\WorkLappy.crt
key C:\\Users\\user\\OpenVPN\\WorkLappy.key
ns-cert-type server
comp-lzo
verb 3
log openvpn.log

SERVER:

Code: Select all

local 10.1.5.69
port 443
proto tcp
dev tun
ca ca.crt
cert vpn3.crt
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 10.1.2.0 255.255.255.0"
push "route 10.1.5.0 255.255.255.0"
client-config-dir ccd
route 10.142.128.0 255.255.240.0
route 172.16.0.0 255.240.0.0
route 10.0.0.0 255.0.0.0
route 192.168.0.0 255.255.0.0
route 10.142.142.0 255.255.255.0
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log         openvpn.log
log-append  openvpn.log
verb 4

CLIENT 1 CCD:

Code: Select all

iroute 10.142.142.0 255.255.255.0
iroute 10.142.128.0 255.255.240.0
iroute 172.16.0.0 255.240.0.0
iroute 10.0.0.0 255.0.0.0
iroute 192.168.0.0 255.255.0.0

CLIENT 2 CCD:

Code: Select all

push "dhcp-option DNS 10.1.5.69"
push "route 10.142.128.0 255.255.240.0"
push "route 172.16.0.0 255.240.0.0"
push "route 10.0.0.0 255.0.0.0"
push "route 192.168.0.0 255.255.0.0"
push "route 10.142.142.0 255.255.255.0"

There's nothing in the logs that indicate a problem, the routing just doesn't seem to work. I can see some places where my routing might overlap between clients/server/etc. However, it seems like it wouldn't work *either* way if those were hosed really bad. It's possible maybe that it's having issues with 10/8 being there on client 2 and it's not letting the most specific 10.X stuff take effect maybe? I don't know. I'll try dropping that 10/8 out and see what happens. But for now, I thought I'd toss the question out there and see if anyone has any ideas. Thanks.

[Mimiko]

Hi.

First, show the LAN's that are on each party and explain where each IP masks are located.

Then, "client-to-client" option is used to allow acces accross client's and their LANs. It's not affecting server and server's LANs to be accessed by clients.

You have in your server:

Code: Select all

local 10.1.5.69
route 10.0.0.0 255.0.0.0

You bind OpenVPN to local interface with IP 10.0.5.69 Mask /8, or /16, or /24. Also you tell to OpenVPN to route all traffic for LAN 10.0.0.0/8 to tunnel, which also contains local interface IP so it's like bind to tunnel, wich is not good. Also for tunnel's IPs you use 10.8.0.0/24, which falls to the same pushing address 10.0.0.0/8.

I'm guesing that problem arrive when you tried to connect the second client, which have that 10.0.0.0/8 LAN.
You can resolve OpenVPN's tunnel IP address pool to use another, but you'll have always problems accessing those two LAN's on server and client side. You will have to change address pool from 10.0.0.0/8 on client to something else, or change address pool on server's side LAN.

[rhyas]

The 10.1.5.69 is a /24 on that network. In my experience you can have multiple routes for networks. The router will either use the most specific route, or the one with the higher metric. Since there aren't really any metrics getting defined, I assume it should be using most specific, in which case, the routing *should* be just fine.

The funny thing, is that the Client 1 and the Server wok in conjunction just fine. It's only when I add in Client 2, and enable client-to-client that I lose connectivity to the Server. So while yeah, client-to-client *shouldn't* effect routing to the Server, it does. And the routing that seems to overlap....isn't a problem on the two hosts that have those networks, when there's no client-to-client enabled. I don't know why, or even how to really troubleshoot it. When I tcpdump any, there's no traffic displayed on the server when I ping the servers local interface. So it's getting eaten up before the sniffer gets any data.


As for the LANS that are on each party's networks:

Server has:
10.1.2.0/24, 10.1.5.0/24 and 10.8.0.0/whatever for the tunnel interfaces.

Client 1 has:
10.142.128.0 255.255.240.0
172.16.0.0 255.240.0.0
10.0.0.0 255.0.0.0
192.168.0.0 255.255.0.0
10.142.142.0 255.255.255.0

Client 2 has:
192.168.1.0/24 (but doesn't need to share this, so should just be using the tunnel interface)

[Mimiko]

Well, you don't control the metrics, so you can't be sure which route is in effect. It may come that both routes are the same metric.

Just post routing table from all three systems in both cases.

[janjust]

tricky setup: remember that routing is done differently when using 'client-to-client' : in that case some routing is handled internally by the openvpn server process. In your setup, the openvpn server process may not know about the route to the server LAN, or the 10/8 route may overrule other routes.

you can use client-to-client routing without using 'client-to-client' by

*) enabling IP forwarding on the server (/proc/sys/net/ipv4/ip_forward)
*) enabling forwarding in iptables:

Code: Select all

iptables -I FORWARD -i tun+ -j ACCEPT
iptables -I FORWARD -o tun+ -j ACCEPT

in that case all routing is done using the system routing tables (and iptables) and the "normal" routing rules (i.e. a more specific rule to a particular subnet "wins") apply.