[b]Brief description of network and setup:[/b] I have an OpenVPN server running in TAP mode on a Linux server. tap0 is bridged with eth0 (the server's LAN interface) into br0. Two client sites connect and results in one big LAN in the same /16 subnet. 192.168.0.0/16 is used on the LAN on the server's side of the bridge. 192.168.10.0/16 is used at client A's side of the bridge. 192.168.20.0/16 is used at client B's side of the bridge. Each site as a router on .254 following the above convention that handles DHCP and general Internet access. OpenVPN at each site is hosted on systems separate from those routers. [b]The issue:[/b] All is well except for one small thing. While I can prevent DHCP traffic from crossing over to either of the client and the server's side of the bridge using the following ebtables rules:[code]ebtables -A INPUT -i tap0 -p ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP ebtables -A INPUT -i tap0 -p ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP[/code] The problem is DHCP traffic still some how makes it between the two client sites; nodes on one client configured for DHCP sometimes get an IP from the router on the other client's side of the bridge. I tried adding the following to prevent that but doesn't seem to change anything:[code]ebtables -A FORWARD -o tap0 -p ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP ebtables -A FORWARD -o tap0 -p ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP[/code] tcpdump still shows it going through:[code]# tcpdump -vv -n -i tap0 | ack '\.(bootp[sc]|6[78])\b' tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes 192.168.10.5.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from de:a2:93:b6:f6:29, length 244, xid 0xe1c9b9a9, Flags [Broadcast] (0x8000) 192.168.20.250.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 323, xid 0xe1c9b9a9, Flags [Broadcast] (0x8000) 192.168.10.254.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 274, xid 0xe1c9b9a9, Flags [Broadcast] (0x8000)[/code] Thanks for any help. --- [b]Server config looks like this:[/b][code]mode server proto udp port 1194 dev tap0 keepalive 10 120 daemon comp-lzo max-clients 16 user nobody group nobody persist-key persist-tun client-to-client log-append /var/log/openvpn.log status /var/run/openvpn/status-server-tap verb 3 mute 20 tls-server tls-auth ...../ta.key 0 cipher BF-CBC ca ...../ca.crt cert ...../server.crt key ...../server.key dh ...../dh1024.pem up /etc/openvpn/bridge-start down /etc/openvpn/bridge-stop[/code] [b]Clients configs look like this:[/b][code]client proto udp dev-node tap0 remote

[quote="Traffic"]Packets sent from one client to another, while passing over the OpenVPN server, do not pass through the OpenVPN server iptables. Try blocking DHCP on both clients.[/quote]How would one allow client to client communication [i]without[/i] the "client-to-client"' directive being active? I have both iptables and ebtables and such at my disposal. Thanks.

You could also try running two TAP adapters in your bridge: serv1.conf: [list]dev tap0 port 1194[/list] client1.conf: [list]remote #.#.#.# 1194[/list] serv2.conf: [list]dev tap1 port 11942[/list] client2.conf: [list]remote #.#.#.# 11942[/list] I believe traffic from client LAN A to client LAN B will have to pass over tap0 and tap1 on the server and will therefore pass through iptables.

TAP + ebtables + client-to-client

blz

Brief description of network and setup:

I have an OpenVPN server running in TAP mode on a Linux server.
tap0 is bridged with eth0 (the server's LAN interface) into br0.
Two client sites connect and results in one big LAN in the same /16 subnet.
192.168.0.0/16 is used on the LAN on the server's side of the bridge.
192.168.10.0/16 is used at client A's side of the bridge.
192.168.20.0/16 is used at client B's side of the bridge.
Each site as a router on .254 following the above convention that handles DHCP and general Internet access.
OpenVPN at each site is hosted on systems separate from those routers.

The issue:

All is well except for one small thing. While I can prevent DHCP traffic from crossing over to either of the client and the server's side of the bridge using the following ebtables rules:

ebtables -A INPUT   -i tap0 -p ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT   -i tap0 -p ipv4 --ip-protocol udp --ip-source-port      67:68 -j DROP

The problem is DHCP traffic still some how makes it between the two client sites; nodes on one client configured for DHCP sometimes get an IP from the router on the other client's side of the bridge.

I tried adding the following to prevent that but doesn't seem to change anything:

ebtables -A FORWARD -o tap0 -p ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD -o tap0 -p ipv4 --ip-protocol udp --ip-source-port      67:68 -j DROP

tcpdump still shows it going through:

# tcpdump -vv -n -i tap0 | ack '\.(bootp[sc]|6[78])\b'
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 262144 bytes
    192.168.10.5.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from de:a2:93:b6:f6:29, length 244, xid 0xe1c9b9a9, Flags [Broadcast] (0x8000)
    192.168.20.250.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 323, xid 0xe1c9b9a9, Flags [Broadcast] (0x8000)
    192.168.10.254.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 274, xid 0xe1c9b9a9, Flags [Broadcast] (0x8000)

Thanks for any help.

---

Server config looks like this:

mode server
proto udp
port 1194
dev tap0
keepalive 10 120
daemon
comp-lzo
max-clients 16
user nobody
group nobody
persist-key
persist-tun
client-to-client
log-append /var/log/openvpn.log
status /var/run/openvpn/status-server-tap
verb 3
mute 20
tls-server
tls-auth ...../ta.key 0
cipher BF-CBC
ca   ...../ca.crt
cert ...../server.crt
key  ...../server.key
dh ...../dh1024.pem
up   /etc/openvpn/bridge-start
down /etc/openvpn/bridge-stop

Clients configs look like this:

client
proto udp
dev-node tap0
remote <server's ip address> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
comp-lzo
verb 3
mute 20
script-security 2
cipher BF-CBC
ca   CA/ca.crt
cert certs/client.crt
key  private/client.key
tls-auth keys/ta.key 1
up "C:\\Program\ Files\\OpenVPN\\config\\up.bat"
up-restart

Traffic

Packets sent from one client to another, while passing over the OpenVPN server, do not pass through the OpenVPN server iptables.

Try blocking DHCP on both clients.

blz

Traffic wrotePackets sent from one client to another, while passing over the OpenVPN server, do not pass through the OpenVPN server iptables.

Try blocking DHCP on both clients.

How would one allow client to client communication without the "client-to-client"' directive being active? I have both iptables and ebtables and such at my disposal.

Thanks.

Traffic

You could also try running two TAP adapters in your bridge:

serv1.conf:

dev tap0
port 1194

client1.conf:

remote #.#.#.# 1194

serv2.conf:

dev tap1
port 11942

client2.conf:

remote #.#.#.# 11942

I believe traffic from client LAN A to client LAN B will have to pass over tap0 and tap1 on the server and will therefore pass through iptables.

tspf

If you want to do some sort of filtering or additional routing etc. do NOT use the "client-to-client" directive!
OpenVPN tries to forward the packets in the OpenVPN-Server-Process when you are using "client-to-client".

We do something similar and use iptables to filter the traffic and allow only specific clients to talk to each other. To make this work, the packets have to "exit" the OpenVPN-Server process and become visible to the kernel (iptables and so on) again. Then we can do filtering and route the traffic back into the VPN.

If you want to be able to reach a subnet behind a client, use the "iroute" directive in the client-config-file. This informs the OpenVPN-Server process which networks are available behind which clients. If you do not use "client-to-client" you have to get your routing right on the server side, otherwise the OpenVPN-Server process handles the routing internally. This means: Every network which should be reachable behind a VPN-Client has to route back into the TUN device (the IP of the Openvpn-Server process) and is then routed internally.

Client ---> OpenVPN-Server TUN ---> Kernel / iptables, ebtables, routing .... ---> OpenVPN-Server TUN ----> Other Client ---> Network