Am 08.07.20 um 09:28 schrieb Thilo-Alexander Ginkel: > On Wed, Jul 8, 2020 at 1:10 AM Florian Westphal <fw@xxxxxxxxx> wrote: >> On first pass (wireguard decap), packet x is picked up by >> connection tracking and then has NAT applied to it. >> As no matching NAT rule exists, the connection gets a 'do nothing' >> binding. When packet comes back, it will match the existing >> 'do nothing' connection and the nat table is never consulted. >> >> If thats the case, you will either need to turn off contrack for packets >> coming from wireguard (use 'notrack' keyword in raw table) or, if you >> need nat for this part as well, place the two rounds the packet takes in >> different connection tracking zones, so that the packet coming back >> from gw01/vlan252 is seen as a new flow, rather than an old packet >> matching a known connection. > > As the WireGuard interface in question doesn not need NAT, I'll try > the "notrack" approach. what about limit your NAT rules to the interface where you need it? on our nat router we have 3 interfaces * lan * wan * vpn NAT is strictly limited to "wan" and so any wireguard related traffic would never hit as well as lan-lan forwarding Chain PREROUTING (policy ACCEPT 15 packets, 2524 bytes) num pkts bytes target prot opt in out source destination 1 14 2464 NETMAP all -- * * 0.0.0.0/0 172.17.0.0/24 to:172.16.0.0/24 Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 NETMAP all -- * wan 172.16.0.0/24 0.0.0.0/0 to:172.17.0.0/24
