no route to host

[ssrsec]

server

The IP address of this host is 1.1.1.1, and it is running the servers wg and dtlspipe

./dtlspipe.linux-amd64 -psk 5b7feba846ec1b202964ef7c82270676 server 0.0.0.0:2815 127.0.0.1:65431

wg0.conf:

[Interface]
PrivateKey = CNU9UfCMSeMYZNMX4vuX77SBaPzsauQatvt4gxhQO1k=
Address = 10.77.0.1/32 
PostUp   = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 65431
DNS = 10.77.0.1
[Peer]
PublicKey = fc3+l2JqbG3cygjc1+7ncWZvCJlbwT0TiDv1OrF7KXI=
AllowedIPs = 10.77.0.2/24,127.0.0.1/32

client

This is my local computer, running the wg client and dtlspipe client

./dtlspipe.darwin-arm64 -psk 5b7feba846ec1b202964ef7c82270676 client 127.0.0.1:2816 1.1.1.1:2815

wg.conf:

[Interface]
PrivateKey = UCtPUEQotx7VOqLheMdrB0X6b1Q0sNIT+L7aeQ7hWUQ=
Address = 10.77.0.2/24
DNS = 8.8.8.8
MTU = 1420

[Peer]
PublicKey = WyoTpynMJohbLDQBX0ioWY0lhg+bvIM25icikRVkpEk=
AllowedIPs = 0.0.0.0/8, 1.0.0.0/16, 1.1.0.0/24, 1.1.1.0/32, 1.1.1.2/31, 1.1.1.4/30, 1.1.1.8/29, 1.1.1.16/28, 1.1.1.32/27, 1.1.1.64/26, 1.1.1.128/25, 1.1.2.0/23, 1.1.4.0/22, 1.1.8.0/21, 1.1.16.0/20, 1.1.32.0/19, 1.1.64.0/18, 1.1.128.0/17, 1.2.0.0/15, 1.4.0.0/14, 1.8.0.0/13, 1.16.0.0/12, 1.32.0.0/11, 1.64.0.0/10, 1.128.0.0/9, 2.0.0.0/7, 4.0.0.0/6, 8.0.0.0/5, 16.0.0.0/4, 32.0.0.0/3, 64.0.0.0/2, ::/0
Endpoint = 127.0.0.1:2816
PersistentKeepalive = 25

error msg

client msg:

DTLSPIPE: 2024/09/15 23:24:26.469448 main.go:235: starting dtlspipe client: 127.0.0.1:2816 =[wrap into DTLS]=> 1.1.1.1:2815
DTLSPIPE: 2024/09/15 23:25:41.259927 client.go:111: [+] conn 127.0.0.1:2816 <=> 127.0.0.1:54397
DTLSPIPE: 2024/09/15 23:25:41.260715 client.go:146: remote dial failed: DTLS handshake with remote server failed: handshake error: write udp [::]:58494->1.1.1.1:2815: sendto: no route to host
DTLSPIPE: 2024/09/15 23:25:41.260747 client.go:147: [-] conn 127.0.0.1:2816 <=> 127.0.0.1:54397
DTLSPIPE: 2024/09/15 23:25:46.310565 client.go:111: [+] conn 127.0.0.1:2816 <=> 127.0.0.1:54397
DTLSPIPE: 2024/09/15 23:25:56.311961 client.go:146: remote dial failed: DTLS handshake with remote server failed: handshake error: context deadline exceeded
DTLSPIPE: 2024/09/15 23:25:56.312021 client.go:147: [-] conn 127.0.0.1:2816 <=> 127.0.0.1:54397

Note: Neither server 1.1.1.1 nor my local computer has firewall enabled

[Snawoot]

Oh, now I see.

It won't work like that. You're trying to use both dtlspipe client and server on the same machine, which makes no sense.

dtlspipe wraps traffic into UDP and sends it over the network in encapsulated form of DTLS. Even if you'll run both dtlspipe client and server on the same computer properly, it will send UDP in the same form as it was before encapsulation, because client encapsulates traffic and server decapsulates it to make it usable with original application (wireguard in your case).

Normally wireguard client should point to dtlspipe client port, dtlspipe client listens port and points to remote dtlspipe server, dtlspipe server listens port and points to wireguard server. In your case you're trying to point dtlspipe client straight to Cloudflare 1.1.1.1 server.

You need to host dtlspipe server somewhere else (e.g. on VPS) and only then dtlspipe server should point to WG endpoint.

[ssrsec]

你理解错了，这里的1.1.1.1不是Cloudflare，而是我的服务器ip，只是我在issus中用1.1.1.1来代替。而且dtlspipe客户端和服务器并不是同一台主机上运行。

[Snawoot]

Oh, okay. Can you please try to remove ::/0 from the list of AllowedIPs and check once again?

[ssrsec]

I removed::/0 and found the same error.

[Snawoot]

I'm looking at logs and I see this:

DTLSPIPE: 2024/09/15 23:25:41.259927 client.go:111: [+] conn 127.0.0.1:2816 <=> 127.0.0.1:54397
DTLSPIPE: 2024/09/15 23:25:41.260715 client.go:146: remote dial failed: DTLS handshake with remote server failed: handshake error: write udp [::]:58494->1.1.1.1:2815: sendto: no route to host

First line is printed when we receive first packet of the connection, it's fine. Second line reports the error. Now take a look at the timing: it happened in less than millisecond. I'm pretty sure something is not letting traffic through on the local machine, otherwise error delay would be much bigger.

Now why I'm thinking it has something to do with firewall. Wireguard itself typically installs some firewall rules to not allow any traffic outside of tunnel. Normally modified AllowedIPs fix that, but I feel like it's not the case.

Do you use Wireguard from AppStore or you use some custom version of Wireguard? Does it have any additional leak protection options? Can you please try to change them?

[ssrsec]

我使用的是AppStore的Wireguard。我本机wg客户端允许0.0.0.0/0，并且我本机没有其他的防火墙开着

[Snawoot]

I'm out of ideas for now. Probably I'll need to test it on Mac myself, but I don't have one at my disposal at this moment.

[ssrsec]

我发现了一个问题，在客户端中，也就是我本机，我需要再开启一台虚拟机，确保wg-client和dtlspipe client在不同的主机上，然后在wg-client的conf文件中指向虚拟机的地址就可以正常使用了。

虽然目前解决了问题，但是很奇怪，这应该不是你们设计的方式，或许还是某些地方配置不对，我只是误打误撞成功了

[Snawoot]

Yeah, somehow wg activates and breaks dtlspipe connectivity even though dtlspipe server IP is excluded.