KPC
Kevin Powell - Community•6d ago
Jochem

Wireguard and non-VPN external connections

I'm using a raspberry pi with raspbian. It's permanently connected to a wireguard VPN (the VPN doesn't support port forwarding from the external VPN address). I also want to host something on the raspberry pi and make it accessible over my home internet. When the VPN is not connected: The service works from inside my network. The service works from outside my network. So the issue is not port forwarding from my modem to the pi When the VPN is connected: The service works from inside my network. The service does not work from outside my network.
1 Reply
Jochem
JochemOP•6d ago
The config for nftables 
table ip6 wg-quick-mullvad-se10 {
        chain preraw {
                type filter hook prerouting priority raw; policy accept;
                iifname != "mullvad-se10" ip6 daddr _external_vpn_ip_ fib saddr type != local drop
        }

        chain premangle {
                type filter hook prerouting priority mangle; policy accept;
                meta l4proto udp meta mark set ct mark
        }

        chain postmangle {
                type filter hook postrouting priority mangle; policy accept;
                meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark
        }
}
table ip wg-quick-mullvad-se10 {
        chain preraw {
                type filter hook prerouting priority raw; policy accept;
                iifname != "mullvad-se10" ip daddr _external_vpn_ip_ fib saddr type != local drop
        }

        chain premangle {
                type filter hook prerouting priority mangle; policy accept;
                meta l4proto udp meta mark set ct mark
        }

        chain postmangle {
                type filter hook postrouting priority mangle; policy accept;
                meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark
        }
}
table ip6 wg-quick-mullvad-se10 {
        chain preraw {
                type filter hook prerouting priority raw; policy accept;
                iifname != "mullvad-se10" ip6 daddr _external_vpn_ip_ fib saddr type != local drop
        }

        chain premangle {
                type filter hook prerouting priority mangle; policy accept;
                meta l4proto udp meta mark set ct mark
        }

        chain postmangle {
                type filter hook postrouting priority mangle; policy accept;
                meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark
        }
}
table ip wg-quick-mullvad-se10 {
        chain preraw {
                type filter hook prerouting priority raw; policy accept;
                iifname != "mullvad-se10" ip daddr _external_vpn_ip_ fib saddr type != local drop
        }

        chain premangle {
                type filter hook prerouting priority mangle; policy accept;
                meta l4proto udp meta mark set ct mark
        }

        chain postmangle {
                type filter hook postrouting priority mangle; policy accept;
                meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark
        }
}
output of ip rule: 
0:      from all lookup local
32755:  from all lookup main suppress_prefixlength 0
32756:  not from all fwmark 0xca6c lookup 51820
32766:  from all lookup main
32767:  from all lookup default
0:      from all lookup local
32755:  from all lookup main suppress_prefixlength 0
32756:  not from all fwmark 0xca6c lookup 51820
32766:  from all lookup main
32767:  from all lookup default
I've tried marking traffic with a fwmarker if it's incoming on port {80,443} and sending it to a different route table, and adding some log lines in nftables. That logs some stuff out in journalctl but the furthest I've come is having the SYNs come in to the server when accessing the service from outside the network, but it doesn't appear to be sending ACKs back as far as I can tell, nothing in nftables should be blocking traffic coming into or going out of other services. The preraw chain rule starting with iifname != "mullvad-se10" shouldn't match traffic coming in on the network, and removing that rule doesn't solve the issue. Flushing the entire nftables table doesn't solve it either. my routing table is pretty basic too: 
default via 192.168.178.1 dev eth0 proto dhcp src 192.168.178.76 metric 202
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.76 metric 202
default via 192.168.178.1 dev eth0 proto dhcp src 192.168.178.76 metric 202
192.168.178.0/24 dev eth0 proto dhcp scope link src 192.168.178.76 metric 202
x.1 is my router, x.76 is the pi itself My current theory is that the packages are arriving on the server, hitting Apache properly, but then getting sent into oblivion down the tunnel on the reply. I have no idea how to fix that though, or if that's even the case.

Did you find this page helpful?