# OpenVPN client-to-client. Host from LAN to remote client.

## manwe_

Hi *.

I have dozens of servers in one place, connected in 10.4.0.0/16 LAN. There are also few hosts in other data centers. I've decied to use OpenVPN and put those remote hosts in the same LAN. Initial setup was prety simple, on main server (10.4.0.1) I have eth0 with public IP and OpenVPN listening, tap and eth1 are joined to bridge. With "client-to-client" mode turned on all remote hosts are able to talk with hosts in LAN through 10.4.0.1. 

Now is the hard part. How can I "force" host in LAN (let's say 10.4.0.2) to talk with 10.4.0.3 via 10.4.0.1?  Simple "telnet 10.4.0.X 80" works from .3 to .2, but not from .2 to .3. 

Simple schema:

```

 [  Host 3  ]                           [  Host 1  ]

 [ 10.4.0.3 ] --- [ internet/VPN ] ---  [  1.2.3.4 ]                           [  Host 2  ]

                                        [ 10.4.0.1 ]  --- [ LAN/switch ]  ---  [ 10.4.0.2 ]

```

----------

## Hu

Change the address of host 3 so that it is not part of the subnet 10.4.0.0/16 or add an explicit route to it in each of the hosts which are on the LAN.  The former is a cleaner solution.  Hosts that are part of the same subnet ought to be able to see each other directly, but your configuration prevents that.

----------

## bbgermany

 *Hu wrote:*   

> Change the address of host 3 so that it is not part of the subnet 10.4.0.0/16 or add an explicit route to it in each of the hosts which are on the LAN.  The former is a cleaner solution.  Hosts that are part of the same subnet ought to be able to see each other directly, but your configuration prevents that.

 

Not really, it is possible to achieve this with a bridge config for openvpn. I do this with my home server, but i dont use a subnet config in the openvpn config file. i use static dhcp on the tun interfaces for the clients. I did it this way:

/etc/conf.d/net:

```

config_eth0="null"

tuntap_tap0="tap"

config_tap0="null"

config_br0="192.168.0.1/24"

routes_br0="default via 192.168.0.254"

dns_domain_lo="domain.tld"

dns_search_lo="domain.tld"

dns_servers_lo="127.0.0.1 192.168.23.254"

brctl_br0="setfd 0 sethello 10 stp off"

bridge_br0="eth0"

# set mac for br0 according to eth0

mac_br0="b8:27:eb:d9:02:dd"

depend_tap0() {

        need net.br0

        }

depend_br0() {

        need net.eth0

        }

depend_openvpn() {

        need net.tap0

        }

postup() {

        brctl addif br0 tap0

        }

```

You must modify it for your networks  :Wink: 

server openvpn.conf:

```

port 1194

proto udp

dev tap0

dev-type tap

mode server

ca /etc/openvpn/easy-rsa/keys/ca.crt

cert /etc/openvpn/easy-rsa/keys/raspi.crt

key /etc/openvpn/easy-rsa/keys/raspi.key

dh /etc/openvpn/easy-rsa/keys/dh4096.pem

tls-server

tls-auth /etc/openvpn/tls.key 0

comp-lzo

verb 3

status-version 2

status /etc/openvpn/openvpn-status.log

client-config-dir /etc/openvpn/ccd

persist-key

persist-tun

reneg-sec 1200

keepalive 10 120

client-to-client

duplicate-cn

```

on the client side i have this config:

```

client

dev tap

proto udp

remote 1.2.3.4 1194

nobind

persist-key

persist-tun

ca ca.crt

cert certfile.crt

key keyfile.key

tls-auth ta.key 1

comp-lzo

verb 3

pull

```

This works perfect, but be aware, the tun/tap interface on the client gets the ip from your network, not the physical ethernet interface!

greets bb

----------

## Hu

His configuration is not a bridge configuration, hence his configuration prevents direct visibility.  A bridge configuration could solve his problem, but may allow more connectivity than he wants.

----------

## bbgermany

 *manwe_ wrote:*   

> ...I have eth0 with public IP and OpenVPN listening, tap and eth1 are joined to bridge. ...

 

According to this, he is haveing a bridge config  :Wink:  But if he is using the bridge on the public interface, it will be hard to get my config working. Using the bridge on the internal interface and doing a little nat for the openvpn port everything is possible. For limiting the traffic between the vpn clients etc. a firewall is needed anyway...

greets bb

----------

