shadowsocks + WireGuard

[ivan-avalos]

Hey, everyone! I'm trying to setup Shadowsocks to bypass my school's restrictive firewall that blocks WireGuard handshake packets. I'm having a tough time setting it up with my EC2 instance, where I have both WireGuard and Shadowsocks installed.

I'm trying to setup this: https://lists.zx2c4.com/pipermail/wireguard/2019-January/003809.html

In the server, I have shadowsocks-libev installed (because it is the only one available in Debian). In the client-side, I have tried almost all the implementations with no success. Port 4000 is open in the server, I tested that it works properly using Netcat. There is no indication whatsoever that the server is receiving any packet, and there's no indication that the client is sending any packet. I'm pointing the WireGuard client to 127.0.0.1:51820.

Is there anything I'm doing wrong?

Server (-libev)

Config

{
    "server": ["0.0.0.0"],
    "mode": "udp_only",
    "server_port": 4000,
    "local_port": 51820,
    "password":"xxxx",
    "timeout": 60,
    "method": "chacha20-ietf-poly1305"
}

Output

Feb 07 00:49:54 ip-172-31-31-135 systemd[1]: Started Shadowsocks-libev Default Server Service.
Feb 07 00:49:54 ip-172-31-31-135 ss-server[8841]:  2023-02-07 00:49:54 INFO: UDP relay enabled
Feb 07 00:49:54 ip-172-31-31-135 ss-server[8841]:  2023-02-07 00:49:54 INFO: TCP relay disabled
Feb 07 00:49:54 ip-172-31-31-135 ss-server[8841]:  2023-02-07 00:49:54 INFO: initializing ciphers... chacha20-ietf-poly1305
Feb 07 00:49:54 ip-172-31-31-135 ss-server[8841]:  2023-02-07 00:49:54 INFO: udp server listening at 0.0.0.0:4000

Client (-rust)

Config

{
    "server": "yyyy",
    "server_port": 4000,
    "password": "xxxx",
    "method": "chacha20-ietf-poly1305",
    "locals": [
        {
            "mode": "udp_only",
            "protocol": "tunnel",
            "forward_address": "yyyy",
            "forward_port": 51820,
            "local_address": "127.0.0.1",
            "local_port": 51820
        }
    ]
}

Output

2023-02-06T19:29:16.851339915-06:00 DEBUG [160460:140670870608640] [shadowsocks_rust::sys] rlimit NOFILE adjusted rlimit { rlim_cur: 524288, rlim_max: 524288 }
2023-02-06T19:29:16.851418896-06:00 INFO  [160460:140670870608640] [shadowsocks_rust::service::local] shadowsocks local 1.15.2 build 2023-02-06T22:50:22.849285882+00:00
2023-02-06T19:29:16.852838983-06:00 WARN  [160460:140670870608640] [shadowsocks_service::local::loadbalancing::ping_balancer] no valid UDP server serving for UDP clients, consider disable UDP with "mode": "tcp_only", currently chose 3.13.12.160:4000
2023-02-06T19:29:16.852970087-06:00 INFO  [160460:140670647924416] [shadowsocks_service::local::tunnel::udprelay] shadowsocks UDP tunnel listening on 127.0.0.1:51820
2023-02-06T19:29:21.226291261-06:00 DEBUG [160460:140670851425984] [shadowsocks::dns_resolver::resolver] auto-reload /etc/resolv.conf
2023-02-06T19:29:22.058544117-06:00 DEBUG [160460:140670851425984] [shadowsocks_service::local::net::udp::association] created udp association for 127.0.0.1:21841

[madeye]

It seems ss-rust cannot receive any UDP responses from server. Maybe your school's firewall blocks all the UDP traffic?

[ivan-avalos]

I'm not at school right now, and, as I mentioned, I tested UDP port 4000 and it seemed to work.

[madeye]

Can you try ss-tunnel in ss-libev as well?

[ivan-avalos]

$ ss-tunnel -v -s yyyy -p 4000 -l 51820 -L yyyy:51820 -k xxxx -m chacha20-ietf-poly1305 -U

 2023-02-06 21:53:59 INFO: initializing ciphers... chacha20-ietf-poly1305
 2023-02-06 21:53:59 INFO: listening at 127.0.0.1:51820
 2023-02-06 21:53:59 INFO: UDP relay enabled
 2023-02-06 21:53:59 INFO: TCP relay disabled
 2023-02-06 21:54:01 INFO: [udp] server receive a packet
 2023-02-06 21:54:01 INFO: [51820] [udp] cache miss: 3.13.12.160:51820 <-> 127.0.0.1:21841
 2023-02-06 21:54:06 INFO: [udp] server receive a packet
 2023-02-06 21:54:06 INFO: [51820] [udp] cache hit: 3.13.12.160:51820 <-> 127.0.0.1:21841
 2023-02-06 21:54:11 INFO: [udp] server receive a packet
 2023-02-06 21:54:11 INFO: [51820] [udp] cache hit: 3.13.12.160:51820 <-> 127.0.0.1:21841
 2023-02-06 21:54:17 INFO: [udp] server receive a packet
 2023-02-06 21:54:17 INFO: [51820] [udp] cache hit: 3.13.12.160:51820 <-> 127.0.0.1:21841
 2023-02-06 21:54:22 INFO: [udp] server receive a packet
 2023-02-06 21:54:22 INFO: [51820] [udp] cache hit: 3.13.12.160:51820 <-> 127.0.0.1:21841

[database64128]

2023-02-06T19:29:16.852838983-06:00 WARN [160460:140670870608640] [shadowsocks_service::local::loadbalancing::ping_balancer] no valid UDP server serving for UDP clients, consider disable UDP with "mode": "tcp_only", currently chose 3.13.12.160:4000

Your client config is missing the mode field for the server.

[ivan-avalos]

Thanks! The warning is gone, but still no connectivity.

$ sudo wg show
...
peer: <public_key>
  endpoint: 127.0.0.1:51820
  allowed ips: 0.0.0.0/0
  transfer: 0 B received, 1.88 KiB sent

[ivan-avalos]

I have a working pair of configuration that I tested using Netcat. I can send and receive data in both ends. However, when testing with the actual WireGuard, the client doesn't seem to be able to send anything to the server.

I have a theory: once the WireGuard connection is activated, the ss tunnel is routed through WireGuard as well, causing some sort of self-referencial meta situation.

Server (-libev)

ss-server -v -s 0.0.0.0 -p 4000 -k xxxx -m chacha20-ietf-poly1305 -U

Client (-libev)

ss-tunnel -v -s yyyy -p 4000 -l 51820 -L 127.0.0.1:51820 -k xxxx -m chacha20-ietf-poly1305 -U

[madeye]

Yes, you need to use iptables to filter out all the packets to your ss-server's port. Otherwise, you will get some cyclic routing issue.

[database64128]

You most likely already have a fwmark configured for your outgoing WireGuard traffic. Set the same fwmark in your shadowsocks client and it should just work.

Using Shadowsocks to forward WireGuard traffic requires you to reduce your WireGuard tunnel's MTU. There are simpler and better solutions for proxying WireGuard traffic, like https://github.com/database64128/swgp-go. Its zero-overhead mode only does minimal obfuscation and does not affect tunnel MTU.

[ivan-avalos]

It worked like magic! Thanks, @database64128! However, it is a bit intermittent. How much should I reduce the MTU?

{
    ...
    "outbound_fwmark": 51852,
    ...
}

I'll check out swgp-go and see how it works! It would be nice if it was available in Debian, though. I always forget to update packages when I have to do it manually.

[ivan-avalos]

swgp-go works flawlessly! Nice job! I think I'll stick with it.

[database64128]

It would be nice if it was available in Debian, though. I always forget to update packages when I have to do it manually.

Packaging for Debian is a very complicated and delicate process, and you still end up distributing very outdated versions of your software to end users, which is probably not what you want with censorship circumvention software. The version of shadowsocks-libev available in Debian is likely several versions behind the latest release and lacks many useful bug fixes.

There are distributions out there that does a better job in this regard. If you use Arch Linux or one of its derivatives, you'll notice that almost everything you use has its latest stable version in either the official repos or AUR. I also packaged my own projects to the AUR and maintain these packages myself. They get immediate updates whenever I publish a new release.