|
|
On Mon, 5 Mar 2007 10:12:34 +0100 Serge Wautier wrote: > Because if bridges don't do that, I confess I don't see the point: > TAP/bridge OpenVPN clients (and LAN clients) appear on the same subnet. > Pardon my ignorance but why would that be interesting if the subnet members > can't see each other? OpenVPN does have the concept of a "server" and a "client" side. If you use a TAP configuration, everything will be forwarded from the server side of your network to every client side and vice versa, but not amongst the client networks unless you use the client-to-client option. I am not sure about the rationale but I believe it would be for historical or symmetrical reasons. In a TUN configuration having traffic routed among client nets before the kernel sees it is a quick & dirty solution to make "everyone sees everyone" happen. However, this does not make much sense in most cases - usually you have VPN clients needing to access a specific network behind the central VPN gateway without the need for the clients to communicate with each other. As you want to filter your client-to-client traffic, you will have to route, not bridge, your traffic through the kernel routing tables. You will need to remove the client-to-client option in this case, make sure the kernel routing works correctly and set up your netfilter rules. What was the reason you decided to use a TAP configuration in the first place? -- Denis Jedig syneticon networks GbR http://syneticon.net/service/ ______________________ OpenVPN mailing lists https://lists.sourceforge.net/lists/listinfo/openvpn-users |