[HACK] UDP tunneling over TCP for WireGuard

[HACK] UDP tunneling over TCP for WireGuard

[Luca Beltrame]

[-- Attachment #1: Type: text/plain, Size: 2428 bytes --]

Hello,

at one of the places I use WireGuard, outgoing UDP is *completely* blocked by 
the perimeter firewall. In addition, only a handful of ports are open. (Not 
that this has helped security in any way, but I digress)

This meant that I could not connect to my WireGuard-using OpenWRT router which 
is somewhere else. 

As a happy WireGuard user, I thought about how to handle this. Port was an 
easy solution: 587 is open, so I could just have the router redirect it to the 
actual endpoint port. UDP, not so much.

What came out was a horrid hack involving socat and sacrifices to the Great 
Old Ones, but that it worked enough for me.

tl;dr: Use socat to tunnel local UDP port via TCP to a remote port, then 
redirect UDP there to the actual WireGuard endpoint port.

First of all, I set a systemd unit to have this running continuously:

[Unit]
Description=UDP over TCP forwarder
After=autossh@tsugumi.service

[Service]
ExecStart=/usr/bin/socat -t600 -T600 -d -d UDP4-LISTEN:51821 tcp4:ENDPOINT_IP:
587
User=nobody
Group=nobody
Restart=always
ProtectSystem=full
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

I set fairly high timeouts because WireGuard is not very chatty and socat 
usually exists when there's no traffic for a while.

Then, I set the relevant bits in wg0.conf:

[Interface]
ListenPort = 51820
PrivateKey =<redacted>
Address = 10.64.0.4/32
MTU=1280

[Peer]
PublicKey = <redacted>
AllowedIPs = 10.64.0.1/32,<internal router LAN IP range>
Endpoint = 127.0.0.1:51821
PersistentKeepalive = 60

As you notice, it goes to localhost then it's pushed via TCP to the remote 
endpoint. At this time, I had to lower the MTU to adjust for overhead (as 
discussed on IRC) that I introduced with this monstrosity. 

On the remote side, I have (running through openWRT's init):

/usr/bin/socat -d -d tcp4-listen:587,reuseaddr,fork UDP4:127.0.0.1:51820

which brings packets back to port 51820, where wg is listening.

And voila', it works:

interface: wg0
  public key: <redacted>
  private key: (hidden)
  listening port: 51820

peer: <redacted>
  endpoint: 127.0.0.1:51821
  allowed ips:  10.64.0.1/32, <LAN>
  latest handshake: 30 seconds ago
  transfer: 300.68 MiB received, 175.78 MiB sent
  persistent keepalive: every 1 minute

Very hacky, but gets the job done. Any suggestions on how to make it better?

-- 
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: A29D259B

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [HACK] UDP tunneling over TCP for WireGuard

[Tim Sedlmeyer]

I have done similar in the past using socat but found I got better
reliability and performance by running ppp over pseudo ttys created
using socat and then having wireguard use the ppp interfaces for their
traffic. An example of the socat and ppp configuration:

On the server side:
socat pty,link=/dev/ttyp10,raw,echo=0 TCP4-LISTEN:587,reuseaddr
sudo pppd noauth /dev/ttyp10 10.10.50.10:10.10.60.10

On the client side:
sudo socat pty,link=/dev/ttyp10,raw,echo=0 TCP4:server_address:587,reuseaddr
sudo pppd noauth /dev/ttyp10 10.10.60.10:10.10.50.10



On Wed, Apr 18, 2018 at 7:55 AM, Luca Beltrame <lbeltrame@kde.org> wrote:
> Hello,
>
> at one of the places I use WireGuard, outgoing UDP is *completely* blocked by
> the perimeter firewall. In addition, only a handful of ports are open. (Not
> that this has helped security in any way, but I digress)
>
> This meant that I could not connect to my WireGuard-using OpenWRT router which
> is somewhere else.
>
> As a happy WireGuard user, I thought about how to handle this. Port was an
> easy solution: 587 is open, so I could just have the router redirect it to the
> actual endpoint port. UDP, not so much.
>
> What came out was a horrid hack involving socat and sacrifices to the Great
> Old Ones, but that it worked enough for me.
>
> tl;dr: Use socat to tunnel local UDP port via TCP to a remote port, then
> redirect UDP there to the actual WireGuard endpoint port.
>
> First of all, I set a systemd unit to have this running continuously:
>
> [Unit]
> Description=UDP over TCP forwarder
> After=autossh@tsugumi.service
>
> [Service]
> ExecStart=/usr/bin/socat -t600 -T600 -d -d UDP4-LISTEN:51821 tcp4:ENDPOINT_IP:
> 587
> User=nobody
> Group=nobody
> Restart=always
> ProtectSystem=full
> ProtectHome=true
> PrivateTmp=true
>
> [Install]
> WantedBy=multi-user.target
>
> I set fairly high timeouts because WireGuard is not very chatty and socat
> usually exists when there's no traffic for a while.
>
> Then, I set the relevant bits in wg0.conf:
>
> [Interface]
> ListenPort = 51820
> PrivateKey =<redacted>
> Address = 10.64.0.4/32
> MTU=1280
>
> [Peer]
> PublicKey = <redacted>
> AllowedIPs = 10.64.0.1/32,<internal router LAN IP range>
> Endpoint = 127.0.0.1:51821
> PersistentKeepalive = 60
>
> As you notice, it goes to localhost then it's pushed via TCP to the remote
> endpoint. At this time, I had to lower the MTU to adjust for overhead (as
> discussed on IRC) that I introduced with this monstrosity.
>
> On the remote side, I have (running through openWRT's init):
>
> /usr/bin/socat -d -d tcp4-listen:587,reuseaddr,fork UDP4:127.0.0.1:51820
>
> which brings packets back to port 51820, where wg is listening.
>
> And voila', it works:
>
> interface: wg0
>   public key: <redacted>
>   private key: (hidden)
>   listening port: 51820
>
> peer: <redacted>
>   endpoint: 127.0.0.1:51821
>   allowed ips:  10.64.0.1/32, <LAN>
>   latest handshake: 30 seconds ago
>   transfer: 300.68 MiB received, 175.78 MiB sent
>   persistent keepalive: every 1 minute
>
> Very hacky, but gets the job done. Any suggestions on how to make it better?
>
> --
> Luca Beltrame - KDE Forums team
> KDE Science supporter
> GPG key ID: A29D259B
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

Re: [HACK] UDP tunneling over TCP for WireGuard

[Matthias Urlichs]

Hi,
> /usr/bin/socat -t600 -T600 -d -d UDP4-LISTEN:51821 tcp4:ENDPOINT_IP:

socat does not mark packet boundaries, which are essential. Thus, this
will not and can never work reliably.

Use a program that adds packet boundaries (i.e. packet length words, PPP
encoding, whatever).
socat alone cannot do this.

-- 
-- Matthias Urlichs

Re: [HACK] UDP tunneling over TCP for WireGuard

[Ximin Luo]

[-- Attachment #1: Type: text/plain, Size: 643 bytes --]

(reposting to the list, not used to gmail)

On Wed, Apr 18, 2018 at 1:55 PM, Luca Beltrame <lbeltrame@kde.org> wrote:

> [..]
>
> Very hacky, but gets the job done. Any suggestions on how to make it
> better?
>

I wonder if anyone has written a program (likely it has to be a kernel
module) to tunnel UDP packets over "fake TCP" i.e. just put the UDP data in
a TCP packet but not actually run TCP. I'm not sure how deeply firewalls
check TCP headers to see if they are "actually" running TCP "properly", but
I'd guess it's possible to fake enough aspects of it so that it "looks
legit" and no firewall would be able to tell the difference.

X

[-- Attachment #2: Type: text/html, Size: 1107 bytes --]

Re: [HACK] UDP tunneling over TCP for WireGuard

[Luca Beltrame]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

In data mercoledì 18 aprile 2018 21:29:11 CEST, hai scritto:

> You can use this:
> https://github.com/wangyu-/udp2raw-tunnel
> instead of socat to avoid TCP over TCP effect.

This is interesting . I'll give it a shot in the next few days and see how it 
fares (and report back).

-- 
Luca Beltrame - KDE Forums team
GPG key ID: A29D259B

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Beware of udp2raw-tunnel (was: [HACK] UDP tunneling over TCP for WireGuard)

[tomli]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

>> You can use this:
>> https://github.com/wangyu-/udp2raw-tunnel
>> instead of socat to avoid TCP over TCP effect.
> This is interesting . I'll give it a shot in the next few days and see how it 
> fares (and report back).

This is a great project, but the last time I've looked into the code, showed some
serious problems, including hardcoding "iptables" commands and execute them as
root[0]. It also comes with an "encryption" scheme "authenticated" by plain MD5
in a MAC-then-encrypt basis, and never used HMAC[1], but still claims the encryption
provided a certain level of security... If the only purpose is traffic obfuscation,
why bother to have AES in the first place? But at least random number generation
has been done correctly, but instead of calling getrandom() or getentropy(), it
opens /dev/urandom with O_RDONLY, and read() some bytes[2]...

So, better compile the whole program with CFLAGS="-D_FORTIFY_SOURCE=2 -fstack-protector-all
--param ssp-buffer-size=1 -fPIE" to get some protections. At least don't run the
program at root, it may break your system, set CAP_NET_RAW instead.

This much being said, I'm not blaming the developers, considering the fact that
the program probably involved from a weekend project and they did understand the
existence of problems[3].

If anyone is interested in this project, a refactoring or a re-implementation
is appreciated.

[0] https://github.com/wangyu-/udp2raw-tunnel/blob/master/misc.cpp#L1104
[1] https://github.com/wangyu-/udp2raw-tunnel/blob/master/encrypt.cpp#L278
[2] https://github.com/wangyu-/udp2raw-tunnel/blob/master/common.cpp#L48
[3] https://github.com/wangyu-/udp2raw-tunnel/blob/master/encrypt.cpp#L23

Tom Li

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 851 bytes --]