wireguard – Fixing ‘Destination Address Required’ Error in Wireguard

You'll want to get the remote end to enable NAT-T on their end of the connection as well.

IPSec communication cryptographically signs the entire packet - any change to the IP header will invalidate that signature. NAT works by rewriting the source and/or destination IP fields; having NAT on either end of the connection means that every packet is having the header changed in transit; the source is changed on packets leaving your 192.168 network, and the destination is changed on inbound packets.

NAT-T counteracts this by encapsulating the entire ESP packet in a new UDP packet. The UDP packet can safely have its headers mangled to the satisfaction of any NAT devices, while the ESP payload will make the entire trip unchanged. The remote node will need to enable this to protect the packets they're sending your way from the NAT modifications, and you'll both need to be allowing UDP port 4500.

This may not be the only issue in the configuration of the VPN tunnel, but it would certainly explain a malformed payload message; give it a shot, and let us know if any further issues come up!

Turns out doing DNAT like that for 127.0.0.1 appears to be infeasible (well, at least for the case of OUTPUT), probably due to the fact that 127.0.0.0/8 are of scope host or similar reasons.

However, the following nftables ruleset should help you achieve what you want:

table ip rewrite {
        chain unloop {
                type route hook output priority filter; policy accept;
                ip daddr 127.0.0.1 tcp dport 80 ip daddr set 10.7.0.2 ip saddr set 10.7.0.1
        }

        chain reloop {
                type filter hook input priority 101; policy accept;
                ip saddr 10.7.0.2 tcp sport 80 ip saddr set 127.0.0.1 ip daddr set 127.0.0.1
        }
}
table ip realnat {
        chain dest {
                type nat hook output priority filter; policy accept;
                ip daddr 192.168.1.183 tcp dport 80 dnat to 10.7.0.2
        }

        chain source {
                type nat hook postrouting priority srcnat; policy accept;
                ip daddr 10.7.0.2 tcp dport 80 snat to 10.7.0.1
        }
}

Instead of doing "proper" destination NAT, you need to instead do sort of an "untracked" rewrite of the destination (and the source) address. With the help of a type route chain, a new route lookup will be performed. Additionally, you'll need to make the replying traffics have their source and destination addresses change back to 127.0.0.1 so that curl can recognize the traffics.

With hook input, it should (i.e. NOT TESTED) avoid unwanted rewrite for traffics that are not for the host itself (i.e. replying traffics for forwarded traffics). On the other hand, priority 101 (i.e. 1 larger than srcnat / all standard priorities) will avoid unwanted rewrite to replies that are responding to requests that have been properly NAT'd.

As you can see, for the 192.168.1.183 case, another table that does normal NAT'ing follows the one for the 127.0.0.1 special case.

Note that this ruleset is only for curling from inside the container (or at most, its host; I'm not familiar with containers and as far as I know, there can be different networking approach for them). If you for example need the container to forward for some other hosts in 192.168.1.0/24, you'll additionally need the same dnat rule in a chain of type nat hook prerouting priority dstnat. IP forwarding will need to be enabled and allowed as well. And as I said, I'm NOT sure if the rewriting tricks above for 127.0.0.1 will conflict with that.