16:07 anyone have experience with wireguard 16:07 i've got some, amdj has a lot 16:07 i'm trying to get a vm on my homelab to use the public ip of a vm on my dedi 16:11 I'm assuming you've gotten wireguard itself working (i.e. both VMs can ping eachother's tunnel addresses) 16:12 once you're at that point, it's just a matter of telling the homelab VM to use the wireguard device as its default gateway (AllowedIPs = 0.0.0.0/0, ::/0), and enabling masquerading NAT on the dedi VM (using e.g. iptables or nftables or whatever firewall frontend of choice) 16:13 oh and enable IP forwarding on the dedi VM. 16:14 not turning that on has tripped me up more times than I care to admit 16:16 i have a bunch of knowledge as well, yeah 16:16 ben: public ipv4? 16:16 or well 16:17 oh man. that dance 16:17 yeah, masquerading NAT is probably the easiest solution. the alternative is to take an IP, set up an ip route into the wireguard interface; but masquerading is really the only sane option if you already have a VM up that you want to take over the IP from 16:24 yeah public ipv4 16:24 i ahve PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens18 -j MASQUERADE 16:24 and then 0.0.0.0/0 in allowedips on the homelab vpn 16:24 and sysctl net.ipv4.ip_forward=1 16:24 on the dedi vm 16:25 if you have any other kind of firewall on the dedi VM, -A isn't sufficient, swap it for -I (to put the rule at the top of the chain). 16:25 no firewall, it's a fresh debian11 16:25 I thought debian switched to nftables 16:27 (you can't have the iptables NAT and nftables NAT kernel modules loaded at the same time; if you do, NAT doesn't work) 16:33 i'm still using iptables on debian fwiw 16:34 (it's iptables-nft behind a symlink) 16:34 and as always tcpdump(8) is your friend. e.g. 16:34 homelab # ping 1.1.1.1 16:35 homelab # tcpdump -vnpi wg0 'host 1.1.1.1' # confirms that the traffic is being sent down wg0 (so your routing table is set up correctly) 16:35 homelab # tcpdump -vnpi eth0 'udp port 51820' # confirms that wireguard is encapsulating that traffic properly and sending it to the correct endpoint 16:35 dedivm # tcpdump -vnpi ens18 'udp port 51820' # confirms the dedi VM is receiving the wireguard traffic 16:35 dedivm # tcpdump -vnpi wg0 'host 1.1.1.1' # confirms the traffic is being decapsulated properly (so your AllowedIPs on this side is correct) and has the correct private source IP address (that you assigned to wg0 on the other side) 16:35 dedivm # tcpdump -vnpi ens18 'host 1.1.1.1' # confirms that the dedi vm is forwarding the traffic back out to the WAN, and will confirm the source address it's using -- it should be the IP address assigned to ens18, not the remote side's wg0