Dedicated tap interface on the server for each client

[iliyan85]

Dear all,

I tested the topology variants and read the openvpn site, but didn't find any information about the case, when each client must be connected to given tap adapter on the server side, not to the same tap.

The case is absolutely possible for implementation in ssh tunnels.

Example commands:

Code: Select all

client1@workstation1:~$ ssh -o tunnel=ethernet -w 1:1 remotehost

Code: Select all

client2@workstation2:~$ ssh -o tunnel=ethernet -w 2:2 remotehost

The reason is that, the virtual ethernet segments must be bridged with the relevant physical ethernet segments on the both sides and must still isolated each other.

Example infra:
Physical server eth1 - bridge1 - tap1 server - TUNNEL - tap1 client1 - bridge - Physical eth to client 1 local network
Physical server eth2 - bridge2 - tap2 server - TUNNEL - tap2 client2 - bridge - Physical eth to client 2 local network
...
and so on.

VLAN ID assignment on tap adapters could be used, but it doesn't solve the problem in real.

[openvpn_inc]

I tested the topology variants and read the openvpn site, but didn't find any information about the case, when each client must be connected to given tap adapter on the server side, not to the same tap.

The case is absolutely possible for implementation in ssh tunnels.

Example commands:

Code: Select all

client1@workstation1:~$ ssh -o tunnel=ethernet -w 1:1 remotehost

Code: Select all

client2@workstation2:~$ ssh -o tunnel=ethernet -w 2:2 remotehost

And a similar approach works in openvpn. See how you are using different ssh instances? Use different openvpn instances.

A multi-client server uses a single tun/tap device to serve all clients. You can connect other clients to a different server. Or, use p2p mode. Note, each instance requires a unique port.

The reason is that, the virtual ethernet segments must be bridged with the relevant physical ethernet segments on the both sides and must still isolated each other.

Example infra:
Physical server eth1 - bridge1 - tap1 server - TUNNEL - tap1 client1 - bridge - Physical eth to client 1 local network
Physical server eth2 - bridge2 - tap2 server - TUNNEL - tap2 client2 - bridge - Physical eth to client 2 local network
...
and so on.

VLAN ID assignment on tap adapters could be used, but it doesn't solve the problem in real.

What is the actual problem and goal? Why does this need tap and bridging? If it's a matter of complex access control, that can be done with tun/routing.

regards, rob0

[iliyan85]

And a similar approach works in openvpn. See how you are using different ssh instances? Use different openvpn instances.

A multi-client server uses a single tun/tap device to serve all clients. You can connect other clients to a different server. Or, use p2p mode. Note, each instance requires a unique port.

The port is the same (TCP 22) for the both commands

What is the actual problem and goal? Why does this need tap and bridging? If it's a matter of complex access control, that can be done with tun/routing.

Each client MUST BE isolated in L2 ETH segment! L3 only supporting is not enough in any cases.
If openvpn implements vSwitch, the problem will be solved with 1 tap adapter and VLAN tagging.
But vSwitch is difficult for implemention. The easy way is working with multiple tap interfaces in combination with bridges on the server side.

[TinCanTech]

The easy way

[iliyan85]

The easy way

I give you advice, how to make openvpn enterprise solution. But you laugh.
At now, openvpn is appropriate for end users in apartments in residential complexes, not for in a real live.

The topic is closed.

[TinCanTech]

I give you advice

I give you advice:

You do not need a L2 bridge ... If you knew anything about computers then you would know this already.

[openvpn_inc]

I'm not interested in the trolling, although I strongly suggest that the poster adopt a better attitude. And the topic is not closed as long as I have some interest in it. Tin and I, we are forum moderators, and we will close topics if/when necessary.

What does interest me is: why does vSwitch (I assume you are talking about Open vSwitch?) not work with openvpn tap adapters? I don't know about this, but a quick Google search found a post from 2010 which says it does. Why would it not, since the tap adapter creates and sends Ethernet packets? If something can be done with Ethernet, why not with tap?

If you have some information about this, please share. Thank you.

regards, rob0

[TinCanTech]

What does interest me is: why does vSwitch (I assume you are talking about Open vSwitch?) not work with openvpn tap adapters?

Works for me.

My question is: Why is full L2 required if that is the very security risk itself.

(ie. Must have muggle-tap over the cursed-bridge .. must have security by complexity foo-bar !!??)