Manual client to client connection

[sunsina]

I have two clients with common names [client_sina] and [client_extra] that are connecting to an OpenVPN server on remote place via (TUN21) running on Tomato Router

The only physical port of the router (OpenVPN server) which is connected to the internet is via WAN port is and is connected to office subnet 192.168.10.x/24

clinet_sina gets static IP address from OVPN server on 10.8.0.69 and LAN 192.168.43.0/24
clinet_extra gets static IP address from OVPN server on 10.8.0.101 and LAN 192.168.42.0/24
and the server is in 192.168.4.0/24 network

I want client_sina get access to all the avaliable networks (client_extra 192.168.42.0/24,Office 192.168.10.0/24 and 192.168.43.0/24 (own network))

While the client_extra must be very limited and just access to 192.168.42.0/24 (own network) and client_sina (192.168.43.0/24) and maybe (openvpn server 192.168.4.0/24) BUT NOT OFFICE LAN which is 192.168.10.0/24.

The client_extra internet must come from the the office (IP forwarding).

Since I want to manage the clients access privileges to each other on the SERVER side I decided to disable
to take out client-to-client option on server side and make for every client a CCD on server side.

The CCD for client_sina is as follows:

ifconfig-push 10.8.0.69 10.8.0.70
# Automacitcally generated (client_sina ip address will be in 43 network
not 42)
iroute 192.168.43.0 255.255.255.0
# Make Serever side avaliable to client_sina
push "route 192.168.4.0 255.255.255.0"
push "route 192.168.10.0 255.255.255.0"
push "route 192.168.42.0 255.255.255.0"

The CCD for client_extra is as follows:

# Automacitcally generated (client_extra will reside in nwtwork 42)
iroute 192.168.42.0 255.255.255.0

ifconfig-push 10.8.0.101 10.8.0.102
# Forwarding internet traffic from workpalce
push "redirect-gateway def1"
push "dhcp-option DNS 10.8.0.1"
push "route 192.168.43.0 255.255.255.0"

The server conf file is as follows:
daemon
server 10.8.0.0 255.255.255.0
proto udp
port 50443
dev tun21
cipher AES-256-CBC
comp-lzo adaptive
keepalive 15 60
verb 3
client-config-dir ccd
ccd-exclusive
route 192.168.42.0 255.255.255.0
route 192.168.43.0 255.255.255.0
ca ca.crt
dh dh.pem
cert server.crt
key server.key
status-version 2
status status
verb 5
mute 5
client-config-dir /jffs/ccd
max-clients 20

The implemented scenario client_sina can access to OfficeLAN,OpenVPN server but not client_extra.

How can I fix the problem!? I want client_sina get access to client_extra subnet network (I am using routing over TUN) and client_extra can not access to 192.168.10.x/24 office network ON SERVER side.

[sunsina]

Thanks for your reply.
I read the link content.
As I understood from the link somewhere (that I do not know) in the openvpn server side
the server automatically executes some commands like push "route 192.168.10.0 255.255.255.0" that I am unaware of !

In my server side config I never push that route to the clients even in the clients CCD files.
I am not sure why that subnet (192.168.10.0/24) gets accessible automatically to the clients when clients are connected to the server!!!

Even I can not track how the packets get routed in the OpenVPN network ---> traceroute just shows the next hop the openvpn server 10.8.0.1.


In fact on the OpenVPN server side I have two subnets.
Subnet (SRV-SUB-A) ---> 192.168.4.0/24 [OpenVPN server sits in this subnet and its IP address is 192.168.4.7]
Subnet (SRV-SUB-B) ---> 192.168.10.0/24 [This subnet is available to OpenVPN server over vlan2]

What I want is to revoke the access to (SRV-SUB-B) to the client_extra.
To clarify I want OpenVpn Server side does not promote or push SRV-SUB-B subnet on client_extra side.
So client_extra does not get access to that subnet at all.
And I do not care if client_extra can get access to SRV-SUB-A network or not.

But the server MUST promote or offer access to SRV-SUB-B subnet to client_sina since It has higher privileges.
I googled about it and I found an old link on http://backreference.org/2010/06/18/ope ... et-filter/
and from that old link I understood packet filter needs compilation.

Since I would rather not to do cross-compilation [openvpn server runs on embedded device] I want to know if there exists an elegant way to solve this problem using OpenVPN options,iptables,ebtables,.... instead of dealing with cross compiling a code and ....

I am not sure if sending routing table of OpenVPN client/server side will give you more hints or not ?
If so what routing command will generate the most comprehensive output for that purpose ?

As additional question if on the openVPN server side I activate client-to-client option and client_sina and client_extra
access to each other subnets does client_sina expose SRV-SUB-B subnet (192.168.10.0/24) to client_extra ? If so how can I prevent it from client_sina side ?
Thanks again

[sunsina]

No, This is not fully describing what I meant in the scenario.

The server is a tomato router (let's call it TR) which has its own subnet 192.168.4.0/24 and connected to a bridged network via vlan2 where the bridged network subnet is 192.168.10.0/24 note that the server local IP address is 192.168.4.7 which means if I connect my PC to that router TR via LAN port and put 192.168.4.7 then the router TR webpage shows up .

Assume that if no OpenVPN was running on the TR server, if I connect my PC to that router TR via one of its LAN port, then I can access to both networks 192.168.4.0/24 and 192.168.10.0/24.

Now consider if I run OpenVPN server via TUN on that TR router, the OpenVPN server running on the TR will expose automatically all its subnets (192.168.4.0/24) and (192.168.10.0/24) to its clients which is not desirable.

Some of the clients (not all) should not get access to the 192.168.10.0/24 network once they are connected to the server.

How this is achievable ? Via OpenVPN push commands and settings in server side,via iptables and firewall rules,.... or something else? Can I forcibly delete a route on the client from server side so even if the client manually add a route he could not access to 192.168.10.0/24 network or what else is considered as a solution.

Thanks