Idea for direct connections

This is where we can discuss what we would like to see added or changed in OpenVPN.

Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech

Post Reply
User avatar
krzee
Forum Team
Posts: 728
Joined: Fri Aug 29, 2008 5:42 pm

Idea for direct connections

Post by krzee » Mon May 11, 2009 9:31 am

Many people have wondered if 2 clients connected through a server can connect directly using openvpn.
No they can't.
I think they could, without even forwarding a port on NAT, but it would take some code.
Here is a way I think it could be done. The downside is the clients would either require root or a suid script.

Clients would have an optional config entry to allow direct-connect (dc) with other peers.
The server would need to have the same entry in its config to facilitate the key-exchange.
when a server sees a client with the dc flag try to make a connection to another client with dc flag it should tell one of them to start a keyx with the other over the existing tunnel with the server. Because this tunnel is already secured by openvpn they can do full exchange of keys over the server without compromising security, and without using certs. They can also share anything about connecting with each other such as dc subnet.
The server would route packets for key exchange, and when they are ready they will facilitate UDP hole punching http://en.wikipedia.org/wiki/UDP_hole_punching using the openvpn server as if it were a STUN server (or we could require the server run a STUN server to have this work with less code change to openvpn).
The clients then connect to each-other and start a peer to peer connection. When they connect they will already have exchanged keys so they already have traffic encrypted.
I think the direct connection would need to be in a different unused subnet. Then each client can set a kernel route entry to route the client vpn IP through the new ptp tunnel.

Even the idea is a huge work in progress, any ideas or comments?

User avatar
ecrist
Forum Team
Posts: 237
Joined: Wed Nov 26, 2008 10:33 pm
Location: Northern Minnesota, USA
Contact:

Re: Idea for direct connections

Post by ecrist » Thu May 21, 2009 7:20 pm

I don't think it's a great idea in many scopes. In a corporate environment, there is risk of bypassing various protocols and firewalling for differing groups of users.

It would be a great feature, in and of itself, however. Similar to the static keys for a simple 1-to-1 VPN. That being said, I think there would be a great amount of code that would need to be written to support it. How many direct connections would be allowed, etc.
OpenVPN Community Administrator
IRC: #openvpn, #openvpn-devel
Co-Author of Mastering OpenVPN
Author of Troubleshooting OpenVPN

User avatar
krzee
Forum Team
Posts: 728
Joined: Fri Aug 29, 2008 5:42 pm

Re: Idea for direct connections

Post by krzee » Mon Jun 08, 2009 7:23 pm

I agree that it could be used to bypass corporate policies, but so can openvpn already. in fact the idea of having openvpn connect over a proxy (which currently exists) has no real purpose besides bypassing policies. I feel that is no reason to not include more functionality.

However, I agree 100% that this would be a HUGE amount of code, and would be anything but easy. It would be a HUGE undertaking, and therefor is not very likely to happen.

But hey, we can dream right ;)

syzzer
Developer
Posts: 2
Joined: Mon Apr 22, 2013 11:37 am

Re: Idea for direct connections

Post by syzzer » Sun Dec 28, 2014 6:56 pm

I think this could definitely work, and it would indeed be a very cool feature to have.

Compared to the client-to-client option we already have, this does not really introduce any extra bypasses. It should not be enabled by default, and an organisation that doesn't like should just not enable it I'd say :)

Furthermore, I don't think you would need any extra routes. The kernel just sends its packets to the tun device. The openvpn client can then internally detect the destination and send it to the correct peer. Much like a TLS server currently does. Makes it much more transparent to the end user too.

So, are you volunteering for a project for 2.5? ;)

cron2
Developer
Posts: 24
Joined: Tue Jan 12, 2010 8:08 pm

Re: Idea for direct connections

Post by cron2 » Tue Jan 06, 2015 12:08 pm

Yeah, auto-meshing clients sounds definitely geeky cool.

I have my doubts that it's relevant enough to warrant the effort... especially the effort to implement NAT traversal methods for the umpteen different broken variants you find in the market (people say half of Skype's code is only to poke holes through NATs).

User avatar
maikcat
Forum Team
Posts: 4200
Joined: Wed Jan 12, 2011 9:23 am
Location: Athens,Greece
Contact:

Re: Idea for direct connections

Post by maikcat » Wed Jan 07, 2015 10:00 am

just curious...

client A from public ip x.x.x.x connects to openvpn server
client B from public ip y.y.y.y connects to openvpn server

we want client A & B to talk directly to each other bypassing openvpn server completely.

this means that packets from x.x.x.x must reach y.y.y.y and vice versa while both (probably)
they are behind NAT network.

can this be done WITHOUT any type of port forwarding on any client? :shock:

Michael.

User avatar
krzee
Forum Team
Posts: 728
Joined: Fri Aug 29, 2008 5:42 pm

Re: Idea for direct connections

Post by krzee » Thu Jan 08, 2015 9:51 pm

yes, because nat itself has a sort of dynamic port forwarding built in. I will try to explain it for you:

When you are behind a NAT and you go to a web page, you send traffic to the web server with some source port, lets say 56789, and a destination port of 80. The web server then sends traffic back to your public IP with destination port 56789, and it gets to you behind the NAT because NAT is nice enough to keep a table of who is using what ports. This is the reason you can get responses from the internet without configuring port forwarding for the responses to know how to get to you.

Using the above knowledge, and the fact that you have an existing secure channel to handle communicating information (via the server) you can make each NAT table do the port forwarding for you. I have used this before to create ptp vpns without access to add a nat rule. Each side connects to the other side's srcport, and it will just work. For example lets say client1 connects to client2 with srcport=55555 dstport=22222 and then client2 connects to client1 with srcport=22222 dstport=55555.

Did that make sense?

User avatar
Traffic
OpenVPN Protagonist
Posts: 4066
Joined: Sat Aug 09, 2014 11:24 am

Re: Idea for direct connections

Post by Traffic » Fri Jan 09, 2015 1:17 am

This can be done already by running a server and client instance on all nodes.
Obviously that means all nodes require one port_forward for the server.

As for the debate regarding NAT .. define NAT.

The more clearly you define NAT ..
The less likely you can punch a "hole" through it ..

Code: Select all

src:ip+src:prt -> NAT.1o -> dst:ip+dst:prt
src:ip+src:prt <- NAT.1i <- dst:ip+dst:prt

does not necessarily include: 

src:ip+src:prt -> NAT.1o -> dst:ip+dst:prt
src:ip+src:prt <- NAT.1i <- any:ip+dst:prt
Sounds like a lot of work .. that will go nowhere .. for no good reason ..
But I have been proven wrong before ..
Good luck :ugeek:

User avatar
maikcat
Forum Team
Posts: 4200
Joined: Wed Jan 12, 2011 9:23 am
Location: Athens,Greece
Contact:

Re: Idea for direct connections

Post by maikcat » Fri Jan 09, 2015 7:50 am

Thank you krzee for your response,
When you are behind a NAT and you go to a web page, you send traffic to the web server with some source port, lets say 56789, and a destination port of 80. The web server then sends traffic back to your public IP with destination port 56789, and it gets to you behind the NAT because NAT is nice enough to keep a table of who is using what ports
this is the case when your gateway (your internet router) performs many-to-one NAT (most of the time) and actually
performs SNAT (static NAT) meaning that it alters source ip address field on outgoing packets,
also involves a connection tracking module (conntrac in iptables) to keep a local table of the NAT sessions,
also AFAIK the router itself CAN use the same source port (and its wan ip) but destined to a different destination
port but same destination since its a different socket.
Using the above knowledge, and the fact that you have an existing secure channel to handle communicating information (via the server) you can make each NAT table do the port forwarding for you.
Thats the part i dont know and i dont quite understand,connection tracking table keeps entries
between the client and the server , so it expects packets from/to client/server.
Each side connects to the other side's srcport, and it will just work
so a 3rd party can connect to an open session between a client and server by using clients (router)source port?
shouldnt the clients router expecting packets from the servers ip?(destined to original scr port initiated by the client)

when you have the time can you please clarify the above?

thank you in advance.

Michael.

User avatar
krzee
Forum Team
Posts: 728
Joined: Fri Aug 29, 2008 5:42 pm

Re: Idea for direct connections

Post by krzee » Fri Jan 09, 2015 1:25 pm

maikcat wrote: so a 3rd party can connect to an open session between a client and server by using clients (router)source port?
No, because the 3rd party will be coming from a different source IP, the NAT table should not pass it.
shouldnt the clients router expecting packets from the servers ip?(destined to original scr port initiated by the client)
yes, but in our example there are 2 clients connecting to eachother ptp style. I think you're basically just asking if IP matters... Yes it does.
Traffic wrote: Sounds like a lot of work .. that will go nowhere .. for no good reason ..
But I have been proven wrong before ..
https://en.wikipedia.org/wiki/NAT_traversal
Give this a read, and remember that with what I'm talking about the clients already have a secure channel to eachother through the server, so they can agree on anything they want, such as ports, IPs, proto, mtu, etc. This removes the need for a stun server like most other client-to-client communications (like voip) would need.
I also think this would be a lot of work, that will go nowhere. But only because I do not think anybody will want to actually do the work. The idea is solid but without someone to implement it that does not actually matter.
Your point that there are different types of NAT is valid, but there are also different types of hole punching, and with our server to handle the back channel to the other client we have an advantage over other projects who want to hole punch.

I also feel the need to point out that ipv6 should eliminate the need to traverse nat, if both clients are ipv6 enabled. also this will not work with symmetric nat, but it should not be too difficult to detect that and simply mark the client as unable to make direct connections.
https://en.wikipedia.org/wiki/STUN
Not all voip clients work with STUN, but those who do should be able to be supported by openvpn for this idea. TURN is what voip users who cannot use stun would use, but that is effectively what our current client-to-client code does.

User avatar
krzee
Forum Team
Posts: 728
Joined: Fri Aug 29, 2008 5:42 pm

Re: Idea for direct connections

Post by krzee » Tue Dec 20, 2022 8:48 pm

i just read this again and realized that i keep saying NAT but i really mean adding the entry to the conntrack table in a similar way that NAT holepunching works. I never actually meant that it would use NAT. Just clarifying since I saw how unclear I was being. Although i suppose the act of adding it to contrack by sending packets with proper src and dst would also punch holes through the nat if it's there.

User avatar
Pippin
Forum Team
Posts: 1201
Joined: Wed Jul 01, 2015 8:03 am
Location: irc://irc.libera.chat:6697/openvpn

Re: Idea for direct connections

Post by Pippin » Thu Dec 22, 2022 7:44 pm

Hi,

After 6 years..... :)

Makes me remember this:
Synology has Quick Connect, they use an unencrypted tunnel or at least they did at that time.
client
mute-replay-warnings
auth-nocache
nobind
tun-mtu 1400
ping-exit 10
connect-retry-max 3
proto udp
remote 59.120.128.184
port 443
dev tun1000
ca /usr/syno/etc/synorelayd/ca/ca.crt
script-security 2
auth-user-pass /tmp/.tunnel.006827843
remap-usr1 SIGTERM
cipher none
comp-lzo adaptive
reneg-sec 0
verb 0
route-up /usr/syno/etc.defaults/synorelayd/scripts/
That ^^^ was about 6/7 years ago.

I see they extended it quite a bit in the last years.
For who is interested: https://kb.synology.com/nl-nl/WP/Synolo ... te_Paper/4
PDF is here: https://global.download.synology.com/do ... _Paper.pdf
I gloomily came to the ironic conclusion that if you take a highly intelligent person and give them the best possible, elite education, then you will most likely wind up with an academic who is completely impervious to reality.
Halton Arp

Post Reply