UDP reverse proxy
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
Is there any easy way of doing userspace UDP reverse proxying?
Specifically, I want the equivalent of
ssh -R 10000:localhost:10000 $server
but for UDP.
I want this approach to be unreliable in the sense that if a packet gets lost between me and the server no retransmit occurs.
Also assume the client machine is unable to receive UDP packets.
Research / approaches considered
- Openvpn does this tunnelling at the IP level. It feels like of heavy weight in terms of configuration, requires quite a lot of settings
socat
might be able to magically do this. But I couldn't find a way from looking at the docs- There is something called a "VPN TAP" interface which sounds kind of like a virtual wire between you and a server. I found some open source programs that claimed to create a user space TAP interface
This page discusses routing UDP over TCP (note that this creates retransmission)
frp looks potentially easy - but I can't tell what it does from an initial inspection.
Openvpn
As people have made clear in the comments in terms of raw performance OpenVPN is the best approach (as it is for TCP packet forwarding for that matter - assuming encryption is required). Of course the downside is this requires root processes on both sides of the connection, certificates, configuration files, a couple of IP addresses and some routing rules for these IP addresses.
networking port-forwarding udp
 |Â
show 1 more comment
up vote
1
down vote
favorite
Is there any easy way of doing userspace UDP reverse proxying?
Specifically, I want the equivalent of
ssh -R 10000:localhost:10000 $server
but for UDP.
I want this approach to be unreliable in the sense that if a packet gets lost between me and the server no retransmit occurs.
Also assume the client machine is unable to receive UDP packets.
Research / approaches considered
- Openvpn does this tunnelling at the IP level. It feels like of heavy weight in terms of configuration, requires quite a lot of settings
socat
might be able to magically do this. But I couldn't find a way from looking at the docs- There is something called a "VPN TAP" interface which sounds kind of like a virtual wire between you and a server. I found some open source programs that claimed to create a user space TAP interface
This page discusses routing UDP over TCP (note that this creates retransmission)
frp looks potentially easy - but I can't tell what it does from an initial inspection.
Openvpn
As people have made clear in the comments in terms of raw performance OpenVPN is the best approach (as it is for TCP packet forwarding for that matter - assuming encryption is required). Of course the downside is this requires root processes on both sides of the connection, certificates, configuration files, a couple of IP addresses and some routing rules for these IP addresses.
networking port-forwarding udp
1
Openvpn is super easy to configure and as lightweight as it can. About +30 bytes / packet.
â Ipor Sircer
Jun 21 at 16:33
Openvpn Hmm, Root + kernel components + certificates + IP address + the potential for ip address collisions feel like a bit of a pain when compared to ssh tunnelling if you just want to say "take these UDP packets here and feed them into this port on localhost"
â Att Righ
Jun 21 at 16:39
> But if you know everything better than me, then please don't ask anything! A bit offensive there don't you think? Umm, I don't really know if I know more than you. I probably know more about my intended use case :P. Though I imagine you might know more about openvpn as I haven't set up openvpn for a couple of years and then it was a pain. I'm quite sure you are correct that openvpn is more performant than ssh tunnels. I'm more interested in something that I can use for hacky one off tasks in a similar way to ssh... in there's a way to use openvpn likessh -R
that'd be awesome!
â Att Righ
Jun 21 at 16:49
If you know more about the intended use case, please edit the question and add the information - it's difficult for us to guess (OpenVPN does UDP as required, and does have less overhead, and does create a tun/tap interface), it makes it harder for us to answer the question, and without it, it can easily become an XY-Problem.
â dirkt
Jun 21 at 17:54
If you know more about the intended use case, please I feel the question is clear as it stands. it's difficult for us Who is us? I guess it's a rhetorical majority excluding me right? it can easily become an XY-Problem. boring, everything is an X-Y problem. Do you want my whole live history as well? Let me offer you an alternative explanation: people don't know how to answer the question so they insist on saying "X-Y Problem!" in the hope that they might get to something they know. I think your comment adds nothing and amounts to little more than cliched back-patting.
â Att Righ
Jun 21 at 18:25
 |Â
show 1 more comment
up vote
1
down vote
favorite
up vote
1
down vote
favorite
Is there any easy way of doing userspace UDP reverse proxying?
Specifically, I want the equivalent of
ssh -R 10000:localhost:10000 $server
but for UDP.
I want this approach to be unreliable in the sense that if a packet gets lost between me and the server no retransmit occurs.
Also assume the client machine is unable to receive UDP packets.
Research / approaches considered
- Openvpn does this tunnelling at the IP level. It feels like of heavy weight in terms of configuration, requires quite a lot of settings
socat
might be able to magically do this. But I couldn't find a way from looking at the docs- There is something called a "VPN TAP" interface which sounds kind of like a virtual wire between you and a server. I found some open source programs that claimed to create a user space TAP interface
This page discusses routing UDP over TCP (note that this creates retransmission)
frp looks potentially easy - but I can't tell what it does from an initial inspection.
Openvpn
As people have made clear in the comments in terms of raw performance OpenVPN is the best approach (as it is for TCP packet forwarding for that matter - assuming encryption is required). Of course the downside is this requires root processes on both sides of the connection, certificates, configuration files, a couple of IP addresses and some routing rules for these IP addresses.
networking port-forwarding udp
Is there any easy way of doing userspace UDP reverse proxying?
Specifically, I want the equivalent of
ssh -R 10000:localhost:10000 $server
but for UDP.
I want this approach to be unreliable in the sense that if a packet gets lost between me and the server no retransmit occurs.
Also assume the client machine is unable to receive UDP packets.
Research / approaches considered
- Openvpn does this tunnelling at the IP level. It feels like of heavy weight in terms of configuration, requires quite a lot of settings
socat
might be able to magically do this. But I couldn't find a way from looking at the docs- There is something called a "VPN TAP" interface which sounds kind of like a virtual wire between you and a server. I found some open source programs that claimed to create a user space TAP interface
This page discusses routing UDP over TCP (note that this creates retransmission)
frp looks potentially easy - but I can't tell what it does from an initial inspection.
Openvpn
As people have made clear in the comments in terms of raw performance OpenVPN is the best approach (as it is for TCP packet forwarding for that matter - assuming encryption is required). Of course the downside is this requires root processes on both sides of the connection, certificates, configuration files, a couple of IP addresses and some routing rules for these IP addresses.
networking port-forwarding udp
edited Jun 21 at 18:36
asked Jun 21 at 16:24
Att Righ
574312
574312
1
Openvpn is super easy to configure and as lightweight as it can. About +30 bytes / packet.
â Ipor Sircer
Jun 21 at 16:33
Openvpn Hmm, Root + kernel components + certificates + IP address + the potential for ip address collisions feel like a bit of a pain when compared to ssh tunnelling if you just want to say "take these UDP packets here and feed them into this port on localhost"
â Att Righ
Jun 21 at 16:39
> But if you know everything better than me, then please don't ask anything! A bit offensive there don't you think? Umm, I don't really know if I know more than you. I probably know more about my intended use case :P. Though I imagine you might know more about openvpn as I haven't set up openvpn for a couple of years and then it was a pain. I'm quite sure you are correct that openvpn is more performant than ssh tunnels. I'm more interested in something that I can use for hacky one off tasks in a similar way to ssh... in there's a way to use openvpn likessh -R
that'd be awesome!
â Att Righ
Jun 21 at 16:49
If you know more about the intended use case, please edit the question and add the information - it's difficult for us to guess (OpenVPN does UDP as required, and does have less overhead, and does create a tun/tap interface), it makes it harder for us to answer the question, and without it, it can easily become an XY-Problem.
â dirkt
Jun 21 at 17:54
If you know more about the intended use case, please I feel the question is clear as it stands. it's difficult for us Who is us? I guess it's a rhetorical majority excluding me right? it can easily become an XY-Problem. boring, everything is an X-Y problem. Do you want my whole live history as well? Let me offer you an alternative explanation: people don't know how to answer the question so they insist on saying "X-Y Problem!" in the hope that they might get to something they know. I think your comment adds nothing and amounts to little more than cliched back-patting.
â Att Righ
Jun 21 at 18:25
 |Â
show 1 more comment
1
Openvpn is super easy to configure and as lightweight as it can. About +30 bytes / packet.
â Ipor Sircer
Jun 21 at 16:33
Openvpn Hmm, Root + kernel components + certificates + IP address + the potential for ip address collisions feel like a bit of a pain when compared to ssh tunnelling if you just want to say "take these UDP packets here and feed them into this port on localhost"
â Att Righ
Jun 21 at 16:39
> But if you know everything better than me, then please don't ask anything! A bit offensive there don't you think? Umm, I don't really know if I know more than you. I probably know more about my intended use case :P. Though I imagine you might know more about openvpn as I haven't set up openvpn for a couple of years and then it was a pain. I'm quite sure you are correct that openvpn is more performant than ssh tunnels. I'm more interested in something that I can use for hacky one off tasks in a similar way to ssh... in there's a way to use openvpn likessh -R
that'd be awesome!
â Att Righ
Jun 21 at 16:49
If you know more about the intended use case, please edit the question and add the information - it's difficult for us to guess (OpenVPN does UDP as required, and does have less overhead, and does create a tun/tap interface), it makes it harder for us to answer the question, and without it, it can easily become an XY-Problem.
â dirkt
Jun 21 at 17:54
If you know more about the intended use case, please I feel the question is clear as it stands. it's difficult for us Who is us? I guess it's a rhetorical majority excluding me right? it can easily become an XY-Problem. boring, everything is an X-Y problem. Do you want my whole live history as well? Let me offer you an alternative explanation: people don't know how to answer the question so they insist on saying "X-Y Problem!" in the hope that they might get to something they know. I think your comment adds nothing and amounts to little more than cliched back-patting.
â Att Righ
Jun 21 at 18:25
1
1
Openvpn is super easy to configure and as lightweight as it can. About +30 bytes / packet.
â Ipor Sircer
Jun 21 at 16:33
Openvpn is super easy to configure and as lightweight as it can. About +30 bytes / packet.
â Ipor Sircer
Jun 21 at 16:33
Openvpn Hmm, Root + kernel components + certificates + IP address + the potential for ip address collisions feel like a bit of a pain when compared to ssh tunnelling if you just want to say "take these UDP packets here and feed them into this port on localhost"
â Att Righ
Jun 21 at 16:39
Openvpn Hmm, Root + kernel components + certificates + IP address + the potential for ip address collisions feel like a bit of a pain when compared to ssh tunnelling if you just want to say "take these UDP packets here and feed them into this port on localhost"
â Att Righ
Jun 21 at 16:39
> But if you know everything better than me, then please don't ask anything! A bit offensive there don't you think? Umm, I don't really know if I know more than you. I probably know more about my intended use case :P. Though I imagine you might know more about openvpn as I haven't set up openvpn for a couple of years and then it was a pain. I'm quite sure you are correct that openvpn is more performant than ssh tunnels. I'm more interested in something that I can use for hacky one off tasks in a similar way to ssh... in there's a way to use openvpn like
ssh -R
that'd be awesome!â Att Righ
Jun 21 at 16:49
> But if you know everything better than me, then please don't ask anything! A bit offensive there don't you think? Umm, I don't really know if I know more than you. I probably know more about my intended use case :P. Though I imagine you might know more about openvpn as I haven't set up openvpn for a couple of years and then it was a pain. I'm quite sure you are correct that openvpn is more performant than ssh tunnels. I'm more interested in something that I can use for hacky one off tasks in a similar way to ssh... in there's a way to use openvpn like
ssh -R
that'd be awesome!â Att Righ
Jun 21 at 16:49
If you know more about the intended use case, please edit the question and add the information - it's difficult for us to guess (OpenVPN does UDP as required, and does have less overhead, and does create a tun/tap interface), it makes it harder for us to answer the question, and without it, it can easily become an XY-Problem.
â dirkt
Jun 21 at 17:54
If you know more about the intended use case, please edit the question and add the information - it's difficult for us to guess (OpenVPN does UDP as required, and does have less overhead, and does create a tun/tap interface), it makes it harder for us to answer the question, and without it, it can easily become an XY-Problem.
â dirkt
Jun 21 at 17:54
If you know more about the intended use case, please I feel the question is clear as it stands. it's difficult for us Who is us? I guess it's a rhetorical majority excluding me right? it can easily become an XY-Problem. boring, everything is an X-Y problem. Do you want my whole live history as well? Let me offer you an alternative explanation: people don't know how to answer the question so they insist on saying "X-Y Problem!" in the hope that they might get to something they know. I think your comment adds nothing and amounts to little more than cliched back-patting.
â Att Righ
Jun 21 at 18:25
If you know more about the intended use case, please I feel the question is clear as it stands. it's difficult for us Who is us? I guess it's a rhetorical majority excluding me right? it can easily become an XY-Problem. boring, everything is an X-Y problem. Do you want my whole live history as well? Let me offer you an alternative explanation: people don't know how to answer the question so they insist on saying "X-Y Problem!" in the hope that they might get to something they know. I think your comment adds nothing and amounts to little more than cliched back-patting.
â Att Righ
Jun 21 at 18:25
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
1
down vote
You could place a SOCKS proxy on the other end of the SSH tunnel. If I remember correctly, one of the example scripts that comes with libio-socket-socks-perl
should be enough after a tiny tweak of parameters.
What would this do in the case of packet loss? If possible I'd like to preserve the "unreliability" of UDP :).
â Att Righ
Jun 21 at 16:53
1
@AttRigh In UDP packet loss is packet loss, as far as I know. The tunnel only cares about the TCP layer. All the rest is UDP, so unreliable by definition.
â Tomasz
Jun 21 at 16:56
1
@AttRigh There are two layers here. TCP beneath and UDP on top of it. They don't know about each other. TCP is reliable, so in case something doesn't arrive, then it resends. If you want to have a really crap-wifi-"proof" transmission system, then you should think of a double-UDP one. OpenVPN should do exactly this, as it will be double-UDP. But if you mean TCP on top of UDP, then I'm affraid OpenVPN won't provide you with what you want. TCP requires reliability. But for streaming videos it should be ok (I guess, 99% certainty). As for the delays, I don't think relays are that stupid...
â Tomasz
Jun 21 at 17:09
1
@AttRigh ...to wait with the transmission of what's there in the buffer for a single lost packets. In fact, it's a known thing that packets will often arrived in an unsorted sequence. But they need to arrive, otherwise a resend request will be issued.
â Tomasz
Jun 21 at 17:10
1
@AttRigh I don't know what you mean by accepting inbound UDP packets from the client. If there's a service with UDP nothing has to be accepted, it works the same as TCP. I can't think of any other protocols. But then, I'm not very knowledgable. Other people might help you, but you should specify what you want in your question, as you seem not to be crystal clear about it. Also if you reply to other people address them by tag, as they won't even know you do. (See the beginning of this comment.)
â Tomasz
Jun 21 at 18:58
 |Â
show 2 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
You could place a SOCKS proxy on the other end of the SSH tunnel. If I remember correctly, one of the example scripts that comes with libio-socket-socks-perl
should be enough after a tiny tweak of parameters.
What would this do in the case of packet loss? If possible I'd like to preserve the "unreliability" of UDP :).
â Att Righ
Jun 21 at 16:53
1
@AttRigh In UDP packet loss is packet loss, as far as I know. The tunnel only cares about the TCP layer. All the rest is UDP, so unreliable by definition.
â Tomasz
Jun 21 at 16:56
1
@AttRigh There are two layers here. TCP beneath and UDP on top of it. They don't know about each other. TCP is reliable, so in case something doesn't arrive, then it resends. If you want to have a really crap-wifi-"proof" transmission system, then you should think of a double-UDP one. OpenVPN should do exactly this, as it will be double-UDP. But if you mean TCP on top of UDP, then I'm affraid OpenVPN won't provide you with what you want. TCP requires reliability. But for streaming videos it should be ok (I guess, 99% certainty). As for the delays, I don't think relays are that stupid...
â Tomasz
Jun 21 at 17:09
1
@AttRigh ...to wait with the transmission of what's there in the buffer for a single lost packets. In fact, it's a known thing that packets will often arrived in an unsorted sequence. But they need to arrive, otherwise a resend request will be issued.
â Tomasz
Jun 21 at 17:10
1
@AttRigh I don't know what you mean by accepting inbound UDP packets from the client. If there's a service with UDP nothing has to be accepted, it works the same as TCP. I can't think of any other protocols. But then, I'm not very knowledgable. Other people might help you, but you should specify what you want in your question, as you seem not to be crystal clear about it. Also if you reply to other people address them by tag, as they won't even know you do. (See the beginning of this comment.)
â Tomasz
Jun 21 at 18:58
 |Â
show 2 more comments
up vote
1
down vote
You could place a SOCKS proxy on the other end of the SSH tunnel. If I remember correctly, one of the example scripts that comes with libio-socket-socks-perl
should be enough after a tiny tweak of parameters.
What would this do in the case of packet loss? If possible I'd like to preserve the "unreliability" of UDP :).
â Att Righ
Jun 21 at 16:53
1
@AttRigh In UDP packet loss is packet loss, as far as I know. The tunnel only cares about the TCP layer. All the rest is UDP, so unreliable by definition.
â Tomasz
Jun 21 at 16:56
1
@AttRigh There are two layers here. TCP beneath and UDP on top of it. They don't know about each other. TCP is reliable, so in case something doesn't arrive, then it resends. If you want to have a really crap-wifi-"proof" transmission system, then you should think of a double-UDP one. OpenVPN should do exactly this, as it will be double-UDP. But if you mean TCP on top of UDP, then I'm affraid OpenVPN won't provide you with what you want. TCP requires reliability. But for streaming videos it should be ok (I guess, 99% certainty). As for the delays, I don't think relays are that stupid...
â Tomasz
Jun 21 at 17:09
1
@AttRigh ...to wait with the transmission of what's there in the buffer for a single lost packets. In fact, it's a known thing that packets will often arrived in an unsorted sequence. But they need to arrive, otherwise a resend request will be issued.
â Tomasz
Jun 21 at 17:10
1
@AttRigh I don't know what you mean by accepting inbound UDP packets from the client. If there's a service with UDP nothing has to be accepted, it works the same as TCP. I can't think of any other protocols. But then, I'm not very knowledgable. Other people might help you, but you should specify what you want in your question, as you seem not to be crystal clear about it. Also if you reply to other people address them by tag, as they won't even know you do. (See the beginning of this comment.)
â Tomasz
Jun 21 at 18:58
 |Â
show 2 more comments
up vote
1
down vote
up vote
1
down vote
You could place a SOCKS proxy on the other end of the SSH tunnel. If I remember correctly, one of the example scripts that comes with libio-socket-socks-perl
should be enough after a tiny tweak of parameters.
You could place a SOCKS proxy on the other end of the SSH tunnel. If I remember correctly, one of the example scripts that comes with libio-socket-socks-perl
should be enough after a tiny tweak of parameters.
answered Jun 21 at 16:50
Tomasz
8,01552560
8,01552560
What would this do in the case of packet loss? If possible I'd like to preserve the "unreliability" of UDP :).
â Att Righ
Jun 21 at 16:53
1
@AttRigh In UDP packet loss is packet loss, as far as I know. The tunnel only cares about the TCP layer. All the rest is UDP, so unreliable by definition.
â Tomasz
Jun 21 at 16:56
1
@AttRigh There are two layers here. TCP beneath and UDP on top of it. They don't know about each other. TCP is reliable, so in case something doesn't arrive, then it resends. If you want to have a really crap-wifi-"proof" transmission system, then you should think of a double-UDP one. OpenVPN should do exactly this, as it will be double-UDP. But if you mean TCP on top of UDP, then I'm affraid OpenVPN won't provide you with what you want. TCP requires reliability. But for streaming videos it should be ok (I guess, 99% certainty). As for the delays, I don't think relays are that stupid...
â Tomasz
Jun 21 at 17:09
1
@AttRigh ...to wait with the transmission of what's there in the buffer for a single lost packets. In fact, it's a known thing that packets will often arrived in an unsorted sequence. But they need to arrive, otherwise a resend request will be issued.
â Tomasz
Jun 21 at 17:10
1
@AttRigh I don't know what you mean by accepting inbound UDP packets from the client. If there's a service with UDP nothing has to be accepted, it works the same as TCP. I can't think of any other protocols. But then, I'm not very knowledgable. Other people might help you, but you should specify what you want in your question, as you seem not to be crystal clear about it. Also if you reply to other people address them by tag, as they won't even know you do. (See the beginning of this comment.)
â Tomasz
Jun 21 at 18:58
 |Â
show 2 more comments
What would this do in the case of packet loss? If possible I'd like to preserve the "unreliability" of UDP :).
â Att Righ
Jun 21 at 16:53
1
@AttRigh In UDP packet loss is packet loss, as far as I know. The tunnel only cares about the TCP layer. All the rest is UDP, so unreliable by definition.
â Tomasz
Jun 21 at 16:56
1
@AttRigh There are two layers here. TCP beneath and UDP on top of it. They don't know about each other. TCP is reliable, so in case something doesn't arrive, then it resends. If you want to have a really crap-wifi-"proof" transmission system, then you should think of a double-UDP one. OpenVPN should do exactly this, as it will be double-UDP. But if you mean TCP on top of UDP, then I'm affraid OpenVPN won't provide you with what you want. TCP requires reliability. But for streaming videos it should be ok (I guess, 99% certainty). As for the delays, I don't think relays are that stupid...
â Tomasz
Jun 21 at 17:09
1
@AttRigh ...to wait with the transmission of what's there in the buffer for a single lost packets. In fact, it's a known thing that packets will often arrived in an unsorted sequence. But they need to arrive, otherwise a resend request will be issued.
â Tomasz
Jun 21 at 17:10
1
@AttRigh I don't know what you mean by accepting inbound UDP packets from the client. If there's a service with UDP nothing has to be accepted, it works the same as TCP. I can't think of any other protocols. But then, I'm not very knowledgable. Other people might help you, but you should specify what you want in your question, as you seem not to be crystal clear about it. Also if you reply to other people address them by tag, as they won't even know you do. (See the beginning of this comment.)
â Tomasz
Jun 21 at 18:58
What would this do in the case of packet loss? If possible I'd like to preserve the "unreliability" of UDP :).
â Att Righ
Jun 21 at 16:53
What would this do in the case of packet loss? If possible I'd like to preserve the "unreliability" of UDP :).
â Att Righ
Jun 21 at 16:53
1
1
@AttRigh In UDP packet loss is packet loss, as far as I know. The tunnel only cares about the TCP layer. All the rest is UDP, so unreliable by definition.
â Tomasz
Jun 21 at 16:56
@AttRigh In UDP packet loss is packet loss, as far as I know. The tunnel only cares about the TCP layer. All the rest is UDP, so unreliable by definition.
â Tomasz
Jun 21 at 16:56
1
1
@AttRigh There are two layers here. TCP beneath and UDP on top of it. They don't know about each other. TCP is reliable, so in case something doesn't arrive, then it resends. If you want to have a really crap-wifi-"proof" transmission system, then you should think of a double-UDP one. OpenVPN should do exactly this, as it will be double-UDP. But if you mean TCP on top of UDP, then I'm affraid OpenVPN won't provide you with what you want. TCP requires reliability. But for streaming videos it should be ok (I guess, 99% certainty). As for the delays, I don't think relays are that stupid...
â Tomasz
Jun 21 at 17:09
@AttRigh There are two layers here. TCP beneath and UDP on top of it. They don't know about each other. TCP is reliable, so in case something doesn't arrive, then it resends. If you want to have a really crap-wifi-"proof" transmission system, then you should think of a double-UDP one. OpenVPN should do exactly this, as it will be double-UDP. But if you mean TCP on top of UDP, then I'm affraid OpenVPN won't provide you with what you want. TCP requires reliability. But for streaming videos it should be ok (I guess, 99% certainty). As for the delays, I don't think relays are that stupid...
â Tomasz
Jun 21 at 17:09
1
1
@AttRigh ...to wait with the transmission of what's there in the buffer for a single lost packets. In fact, it's a known thing that packets will often arrived in an unsorted sequence. But they need to arrive, otherwise a resend request will be issued.
â Tomasz
Jun 21 at 17:10
@AttRigh ...to wait with the transmission of what's there in the buffer for a single lost packets. In fact, it's a known thing that packets will often arrived in an unsorted sequence. But they need to arrive, otherwise a resend request will be issued.
â Tomasz
Jun 21 at 17:10
1
1
@AttRigh I don't know what you mean by accepting inbound UDP packets from the client. If there's a service with UDP nothing has to be accepted, it works the same as TCP. I can't think of any other protocols. But then, I'm not very knowledgable. Other people might help you, but you should specify what you want in your question, as you seem not to be crystal clear about it. Also if you reply to other people address them by tag, as they won't even know you do. (See the beginning of this comment.)
â Tomasz
Jun 21 at 18:58
@AttRigh I don't know what you mean by accepting inbound UDP packets from the client. If there's a service with UDP nothing has to be accepted, it works the same as TCP. I can't think of any other protocols. But then, I'm not very knowledgable. Other people might help you, but you should specify what you want in your question, as you seem not to be crystal clear about it. Also if you reply to other people address them by tag, as they won't even know you do. (See the beginning of this comment.)
â Tomasz
Jun 21 at 18:58
 |Â
show 2 more comments
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f451148%2fudp-reverse-proxy%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Openvpn is super easy to configure and as lightweight as it can. About +30 bytes / packet.
â Ipor Sircer
Jun 21 at 16:33
Openvpn Hmm, Root + kernel components + certificates + IP address + the potential for ip address collisions feel like a bit of a pain when compared to ssh tunnelling if you just want to say "take these UDP packets here and feed them into this port on localhost"
â Att Righ
Jun 21 at 16:39
> But if you know everything better than me, then please don't ask anything! A bit offensive there don't you think? Umm, I don't really know if I know more than you. I probably know more about my intended use case :P. Though I imagine you might know more about openvpn as I haven't set up openvpn for a couple of years and then it was a pain. I'm quite sure you are correct that openvpn is more performant than ssh tunnels. I'm more interested in something that I can use for hacky one off tasks in a similar way to ssh... in there's a way to use openvpn like
ssh -R
that'd be awesome!â Att Righ
Jun 21 at 16:49
If you know more about the intended use case, please edit the question and add the information - it's difficult for us to guess (OpenVPN does UDP as required, and does have less overhead, and does create a tun/tap interface), it makes it harder for us to answer the question, and without it, it can easily become an XY-Problem.
â dirkt
Jun 21 at 17:54
If you know more about the intended use case, please I feel the question is clear as it stands. it's difficult for us Who is us? I guess it's a rhetorical majority excluding me right? it can easily become an XY-Problem. boring, everything is an X-Y problem. Do you want my whole live history as well? Let me offer you an alternative explanation: people don't know how to answer the question so they insist on saying "X-Y Problem!" in the hope that they might get to something they know. I think your comment adds nothing and amounts to little more than cliched back-patting.
â Att Righ
Jun 21 at 18:25