Hi,

blz wrote:
> I have an OpenVPN server running in TAP mode on a Linux server where 
> 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.
>
> I have full access over the Linux server. I have iptables and ebtables 
> and all other facilities at my disposal.
>
> Right now cient-to-client is enabled on the server and allows all nodes 
> on a given client to communite with those on another, as well as to the 
> server. We require a bridging setup like this for our rather specific 
> needs that cannot be accomplished with a TUN based setup.
>
> What I would like to do is turn off client-to-client and do it manually 
> so that packets from one client to another actually go through the 
> kernel so they are subject to iptables and ebtables; with 
> client-to-client enabled, such packages bypass the kernel as they are 
> routed internally by OpenVPN. I want to be able to some occasional 
> filtering when it is needed (mainly for anything that needs to be 
> isolated to it's respective site and not cross the bridge.
>
> What I can't quite figure out is how to do this exactly. I have 
> conducted a lot of searching of both all of openvpn.net as well as 
> various general search engine queries to no avail.
>
>   
on most modern Linux kernels you can mimick client-to-client behaviour 
in tap mode using proxy_arp_pvlan; don't add 'client-to-client' to the 
server config, but run an "up" script on the server side which does 
little more than

  echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp_pvlan

(replace 'tap0' with the name of the actual tap device); for bridged 
devices you might have to set this feature on the bridge i/f as well.
After setting this flag you will initially see some packet loss and 
redirect messages:

 > ping 10.222.0.2
PING 10.222.0.2 (10.222.0.2) 56(84) bytes of data.
64 bytes from 10.222.0.2: icmp_seq=1 ttl=63 time=912 ms
 From 10.222.0.1: icmp_seq=2 Redirect Host(New nexthop: 10.222.0.2)
64 bytes from 10.222.0.2: icmp_seq=2 ttl=63 time=4.45 ms
 From 10.222.0.1: icmp_seq=3 Redirect Host(New nexthop: 10.222.0.2)
64 bytes from 10.222.0.2: icmp_seq=3 ttl=63 time=4.49 ms
 From 10.222.0.1: icmp_seq=4 Redirect Host(New nexthop: 10.222.0.2)
 From 10.222.0.1: icmp_seq=5 Redirect Host(New nexthop: 10.222.0.2)
64 bytes from 10.222.0.2: icmp_seq=5 ttl=63 time=105 ms

but after a few seconds the link should be stable.
This kernel flag (available in 2.6.34+ but also in RHEL6/CentOS6) tells 
the interface that when an ARP message comes in it should send it back 
out the same interface again - this ensures that all other clients in 
the VPN will get the ARP request.

As for monitoring or controlling the traffic: ebtables only works on 
bridges , so your set *must* use a bridge or otherwise the traffic is 
never passed throught ebtables (I just verified this).


HTH,

JJK


------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Reply via email to