|
|
hi! I'm not sure this is true. Consider that most firewalls, upon seeing an outgoing UDP packet fly by on port X, will open up a temporary hole allowing return packets on port X, from the destination address of the outgoing packet. hmmm - over here we're using a tunnel server and multiple tunnel clients. some of the tunnel clients have dynamically changing ips, and sit behind a firewall that does not forward any ports to the client (that were not initiated from the client and therefore not listed in the connection table). i.e. if the client connects to the server, and the server tries to connect to a port of the client, it won't work. in this case the firewall has to listen to and understand the initial communication on the connection the client made to the server (i.e. no fw supports that yet, explicit openvpn-support had to be implemented in the connection tracker of each single fw-product (that supports application-level connection tracking, which not every fw-product does) ) to open/nat the negotiated port. if the client initiates the data (i.e. 2nd) connection to the server, that would work - until the client is hardened by closing all unused ports, then a 'static' port would be useful again (i.e. nothing won), or there's again need for a connection tracker listening to and understanding the control connection... with udp, just theoretically, a connection could still be identified by src-ip:src-port,dst-ip:dst-port. but here ends my knowledge, i don't know how udp sockets are actually handled. so i made a test with vtund, and created two tun tunnels via udp, even between the same hosts. this is what netstat -an tells me (vtund is listening on port 5000): udp 0 0 10.0.0.28:5000 10.0.0.69:32785 ESTABLISHED udp 0 0 10.0.0.28:5000 10.0.0.69:32784 ESTABLISHED so it seems to work like with tcp, a socket seems to be identified by src and dst ip and port. also, there seem to be two different processes dealing with the different sockets: 19036 ? S< 0:00 vtund[s]: test tun tun3 19078 ? S< 0:00 vtund[s]: test2 tun tun4 Suppose client A is connected to UDP 53. The network hiccups and the client reconnects to TCP 80. But the OpenVPN process on UDP 53 still thinks it's connected to the client, so it holds on to client-specific resources such as return routes or tunnel endpoint addresses. hm - well, a tunnel has to be identified (if everybody connects to the same socket - could be done by remote-ip, remote-port (both imho a bad idea), encryption-key, and/or an explicit id). so the server would know if a client with a connection the server believes to be alive tries to reconnect (and could kill the old connection). [from a different mail, regarding implementing a userspace ip stack] >hm, did you understand my idea of simply using an arp library instead? You mean implementing a kind of userspace ethernet switch? right. i think that would save a hell lot of work (implementing a whole ip-stack in userspace just sounds really really big to me), while providing the same/comparable functionality (just with the kernel doing routing and filtering) - and to be frank, i personally consider it even more elegant... :) +- remote tun
tap -- openvpn-switching --+- temote tun
+- remote tunopenvpn's arp-tasks would simply be to assign MACs to the interfaces and answer arp-requests. the rest should be plain ethernet switching. i think it should be possible to make the tap device a non-broadcast multiple access type of interface, by never switching packets from tun devices to other tun devices, but to the tap device instead. this way iptables could even be used between the tun devices. regards, Chris PS: sbdy mentioned complexity/security issues: having an udp port for each single tunnel creates certainly far more complexity than having just one... to check that, one just has to try to deal with mentioned protocols in a setup involving firewalls... (and having to open a port in the fw-ruleset for each tunnel that is created is certainly also not more secure (but more complex) than with having just one port for the same service)
|