[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

Re: [Openvpn-users] Filter on tap device

  • Subject: Re: [Openvpn-users] Filter on tap device
  • From: Marco Fretz <mailinglist@xxxxxxx>
  • Date: Thu, 03 Jan 2008 22:43:06 +0100


i tested the thing a few days ago. had no time to post it till now, sry.

with client-to-client deactivated in the server config all client can 
see only the server (in TUN and TAP mode). with a tcpdump on the tap0 
(server) device i can only see bcast or ucast to / from the server. 
that's what i supposed.
so i think there's no way to filter / block client-to-client traffic in 
TAP mode.

i ll be grateful for any input or ideas.

kind regards

Jan Just Keijser schrieb:
> Hi Marco,
> did you try it without the 'client-to-client' statement? by default, 
> client-to-client traffic should NOT work using either a 'tun' setup or 
> a 'tap' setup. If not, then either this is a bug in openvpn or you 
> could add a patch to OpenVPN to make sure it blocks client-to-client 
> traffic. Note that there is no method to selectively block traffic 
> between clients, it's an All-or-Nothing option.
> Yes, OpenVPN is written in C and is quite easy to read and patch. I've 
> added a few patches myself without too many difficulties.
> cheers,
> Marco Fretz wrote:
>> thanks jjk
>> i think thats the answer i was lookin for. i need this for my 
>> broadcast gaming network project (i made another topic in the list 
>> about that). and maybe i will distribute my own openvpn or patchs for 
>> openvpn for that.
>> but fact is that i cant filter client to client traffic on the tap 
>> interface with iptables while using TAP and i need TAP :)
>> openvpn is written in C, right? do u think there is a way to create 
>> an API i can use to crontrol something like client to client rules in 
>> openvpn runtime?
>> Jan Just Keijser wrote:
>>> Marco Fretz wrote:
>>>> i think it wont work cause TAP "bridges" the clients together and 
>>>> TUN with client-to-client routes the clients together... there is 
>>>> no reason that traffic from client A to client B have to come out 
>>>> of the tap interface. and so i cant filter with iptables cause the 
>>>> forward chain only applies to forwarding traffic (from one to 
>>>> another interface). right?
>>> Right, the packet will never "leave" the openvpn server process (if 
>>> I read the source code correctly).
>>> However, the same openvpn source code also has this specific
>>>  if (m->enable_c2c) { ... } else { ... }
>>> block which suggests that it does support the (blocking of) 
>>> client-to-client traffic.
>>> cheers,
>>> JJK
>>>> anyways i ll try it :)
>>>> thanks
>>>> Jan Just Keijser wrote:
>>>>> From reading the openvpn source code (file multi.c) I'd say that 
>>>>> client-to-client is treated nearly the same for TAP or TUN 
>>>>> connections (bridged tap connections are different). Of course, 
>>>>> the easiest thing to do is to connect 2 clients *without* 
>>>>> client-to-client and then try to ping each other.
>>>>> HTH,
>>>>> JJK
>>>>> Marco Fretz wrote:
>>>>>> hi
>>>>>> but this is only in TUN mode isnt it? i cant find anything like 
>>>>>> client-to-client in TAP mode. but for my needs i have to use TAP 
>>>>>> instead of TUN
>>>>>> thx
>>>>>> marco
>>>>>> Jan Just Keijser wrote:
>>>>>>> hi Marco,
>>>>>>> as long as you don't have the server directive
>>>>>>>  client-to-client
>>>>>>> in your server config file then clients should not be allowed to 
>>>>>>> connect to each other.
>>>>>>> HTH,
>>>>>>> JJK
>>>>>>> Marco wrote:
>>>>>>>> hello
>>>>>>>> ive got an openvpn server running with TAP. i want to block 
>>>>>>>> traffic from client A to client B. client A and client B are 
>>>>>>>> both connected over the same openvpn server process (same 
>>>>>>>> server tap device)
>>>>>>>> is this possible? can i block such traffic with iptables on the 
>>>>>>>> tap0 interface on the openvpn server?
>>>>>>>> i think that want be possible cause TAP is like Layer2 and the 
>>>>>>>> packets may be forwarded inside the opevpn process and not over 
>>>>>>>> the tap0 device

Openvpn-users mailing list