| 30 Apr 2026 |
 K900 | Uhh is 185.254.79.30 the internal address of the peer on the tunnel | 14:05:28 |
| K900 | Or is it the external endpoint | 14:05:32 |
| K900 | Cause it feels like the latter | 14:05:35 |
 Cadair | yeah the latter | 14:05:39 |
| K900 | Then it should absolutely not have a route on the Mullvad interface | 14:06:01 |
| K900 | Because what you're saying is "to get to the endpoint of the tunnel, go through the tunnel" | 14:06:13 |
| K900 | Which makes no sense | 14:06:16 |
| Cadair | oh it's neither sorry | 14:06:38 |
| Cadair | it's the random IP on the wider internet I want to get to over the tunnel | 14:06:47 |
| Cadair | * it's the "random" IP on the wider internet I want to get to over the tunnel | 14:07:09 |
| K900 | Can you ping the actual endpoint of the tunnel? | 14:07:33 |
| K900 | On the tunnel link | 14:07:38 |
| * Cadair can't get packets to his email host over his home internet without tunneling it over a VPN for some reason he can't get to the bottom on | 14:07:55 |
| * Cadair * can't get packets to his email host over his home internet without tunneling it over a VPN for some reason he can't get to the bottom of | 14:07:55 |
| Cadair | I'm not sure I know what the IP address of the endpoint is over the tunnel | 14:08:20 |
 Ramses 🇵🇸 | My first course of action would be to tcpdump the wg iface to check whether packets are going out and whether replies are coming back | 14:13:40 |
| Cadair | well nothing seems to be coming back | 14:19:44 |
| Cadair | # tcpdump -i mullvad
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on mullvad, link-type RAW (Raw IP), snapshot length 262144 bytes
15:19:10.597713 IP penygader > kolabnow.com: ICMP echo request, id 13, seq 1, length 64
15:19:11.628561 IP penygader > kolabnow.com: ICMP echo request, id 13, seq 2, length 64
15:19:12.652563 IP penygader > kolabnow.com: ICMP echo request, id 13, seq 3, length 64
| 14:20:17 |
| Cadair | I enabled debug logging on the wireguard kernel module and it seems to be fine, and wg shows data coming back, so it's up | 14:24:07 |
| K900 | Is Mullvad maybe just not forwarding ICMP | 14:24:39 |
| K900 | Have you tried an actual TCP connection | 14:24:44 |
| Cadair | # tcpdump -i mullvad
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on mullvad, link-type RAW (Raw IP), snapshot length 262144 bytes
15:26:01.904094 IP penygader.49524 > kolabnow.com.https: Flags [S], seq 1722299121, win 65520, options [mss 1260,sackOK,TS val 1736116169 ecr 0,nop,wscale 7], length 0
15:26:01.937688 IP kolabnow.com.https > penygader.49524: Flags [S.], seq 1954783574, ack 1722299122, win 64240, options [mss 1340,nop,nop,sackOK,nop,wscale 7], length 0
15:26:02.104493 IP penygader.54126 > kolabnow.com.https: Flags [S], seq 1411843678, win 65520, options [mss 1260,sackOK,TS val 3195388376 ecr 0,nop,wscale 7], length 0
15:26:02.133932 IP kolabnow.com.https > penygader.54126: Flags [S.], seq 2178859904, ack 1411843679, win 64240, options [mss 1340,nop,nop,sackOK,nop,wscale 7], length 0
| 14:26:33 |
| Cadair | I seem to be getting | 14:26:38 |
| Cadair | * I seem to be getting something back | 14:26:42 |
| Cadair | but curl hangs forever | 14:26:49 |
| Cadair | well it eventually times out | 14:28:28 |
| Cadair | ok, I've found something odd. Apparently you can use 10.64.0.1 as a gateway inside the mullvad tunnel, so I setup a static route for this address:
10.64.0.1 dev mullvad proto static scope link metric 128
Which I then ping'ed
# ping 10.64.0.1
PING 10.64.0.1 (10.64.0.1) 56(84) bytes of data.
^C
--- 10.64.0.1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4111ms
Looking at tcp dump, this time I'm getting responses:
# tcpdump -i mullvad
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on mullvad, link-type RAW (Raw IP), snapshot length 262144 bytes
15:45:31.453827 IP penygader > 10.64.0.1: ICMP echo request, id 18, seq 1, length 64
15:45:31.481398 IP 10.64.0.1 > penygader: ICMP echo reply, id 18, seq 1, length 64
15:45:32.492560 IP penygader > 10.64.0.1: ICMP echo request, id 18, seq 2, length 64
15:45:32.519818 IP 10.64.0.1 > penygader: ICMP echo reply, id 18, seq 2, length 64
15:45:33.516554 IP penygader > 10.64.0.1: ICMP echo request, id 18, seq 3, length 64
15:45:33.543803 IP 10.64.0.1 > penygader: ICMP echo reply, id 18, seq 3, length 64
15:45:34.540552 IP penygader > 10.64.0.1: ICMP echo request, id 18, seq 4, length 64
15:45:34.567838 IP 10.64.0.1 > penygader: ICMP echo reply, id 18, seq 4, length 64
15:45:35.564545 IP penygader > 10.64.0.1: ICMP echo request, id 18, seq 5, length 64
15:45:35.591841 IP 10.64.0.1 > penygader: ICMP echo reply, id 18, seq 5, length 64
| 14:47:11 |
| Cadair | so why is tcpdump seeing responses, but ping is not seeing them? | 14:47:31 |
| Ramses 🇵🇸 | your firewall might be intercepting them | 14:57:59 |
| Ramses 🇵🇸 | or things like the kernel reverse path filter | 14:58:27 |
