| 30 Apr 2026 |
 K900 | That would imply no NAT | 14:02:35 |
 Cadair | I've also tried making it the default route on this host and that didn't work either | 14:03:31 |
| K900 | Are you sending traffic directly from the router | 14:03:51 |
| K900 | Or from one of the hosts on the LAN | 14:03:56 |
| Cadair | I'm at the point where I'm assuming something is messed up because of the extra networking complexity on this host | 14:03:56 |
| Cadair | yes | 14:03:58 |
| K900 | Because you probably need to NAT | 14:03:59 |
| Cadair | I can't ping out from the router across the tunnel | 14:04:11 |
| Cadair | I have this route:
185.254.79.30 dev mullvad proto static scope link metric 512
and I can't ping 185.254.79.30 from the router | 14:05:00 |
| 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 |
