Private subnet access throught VPN client

nahemoth

Hi,

I have two clients (A and B) that they connect to the openVPN server in the subnet range 10.8.0.0. Everything works fine, and both clients can see each other. Client B has these two network interfaces:
- NIC1 tun0 : 10.8.0.0 VPN network
- NIC2 eth2 : 192.168.1.0 Private subnet

I want to access the private subnet from client A. The packets sent from client A reach the VPN server, but something is wrong because these packets are not sent to client B. That is:

Client A IP: 10.8.0.2
VPN server IP: 10.8.0.1
Client B VPN IP: 10.8.0.3
Client B private subnet IP: 192.168.1.2

From client A (gateway configured as client B VPN address):

> ping 192.16.1.2
From 10.8.0.1: icmp_seq=1 Redirect host (new nexthop: 10.8.0.3)

But there is no more answer. I listen to the client B network interface tun0:

> tcpdump -n -i tun0

And nothing is received. From VPN server:

> tcpdump -n -i tun0

IP 10.8.0.2 > 192.168.1.2: ICMP echo request

It seems like tun0 interface from the VPN server does not send these packets to client B. What is it happening? I tried either iptable rules and iproute2.

Thanks in advance!

Mimiko

In servers config file add:

push "route 192.168.1.0 255.255.255.0

Also under a ccd folder creade a file called like client's B common name and add to it:

iroute 192.168.1.0

nahemoth

Thank you very much for your reply.

For this application, is it possible to avoid the use of ccd?

Mimiko

If you whant to access the remote clients LAN you cannot avoid iroute, because it adds routes to OpenVPN internal table.

nahemoth

Mimiko wroteIf you whant to access the remote clients LAN you cannot avoid iroute, because it adds routes to OpenVPN internal table.

And what happens if a third client is connected with its own ccd file, but sharing the same range private subnet? I think that internal routes are overwritten, is there any way to avoid this behavioral?

Thanks

janjust

If 2 clients have CCD file containing the same 'iroute' statement then yes, the last client to connect will "win" (IIRC). But you, as server admin, have set this up yourself, so it is up to the same server admin to detect and allow or prevent this behaviour.

You could use a client-connect script to detect if a private subnet is already used and refuse access to the second client.

nahemoth

janjust wroteIf 2 clients have CCD file containing the same 'iroute' statement then yes, the last client to connect will "win" (IIRC). But you, as server admin, have set this up yourself, so it is up to the same server admin to detect and allow or prevent this behaviour.

You could use a client-connect script to detect if a private subnet is already used and refuse access to the second client.

I understand... how do I use the client-connect script? Is there any example?

nahemoth

nahemoth wrote
janjust wroteIf 2 clients have CCD file containing the same 'iroute' statement then yes, the last client to connect will "win" (IIRC). But you, as server admin, have set this up yourself, so it is up to the same server admin to detect and allow or prevent this behaviour.

You could use a client-connect script to detect if a private subnet is already used and refuse access to the second client.
I understand... how do I use the client-connect script? Is there any example?

I made two simple scripts, one for connections and other for disconnections. Now, only one gateway is connected to the VPN.

Anyway, is there any possibility to do the same with the VPN server in bridge mode?

Thanks.

janjust

what you do mean 'in bridge mode' ? the client-connect script works in all modes.

nahemoth

janjust wrotewhat you do mean 'in bridge mode' ? the client-connect script works in all modes.

No, I mean the access to a private subnet (like using iroute) but in bridge mode allowing packet filtering.

nahemoth

I found this patch for creating internal routes dynamically:

http://permalink.gmane.org/gmane.network.openvpn.devel/4059

Unfortunately it does not work for me... I am not sure of how it works. Any help?

Thanks

janjust

No, I mean the access to a private subnet (like using iroute) but in bridge mode allowing packet filtering.

you can do more packet filtering in 'tun' mode than in bridged mode , as far as I know - don't use 'client-to-client' and make sure all traffic passes through iptables.