On Tue, 2023-11-07 at 01:19 +0000, Andrew Oakeley wrote:
Don't masquerade at the remote end Just make sure at the starkink end the traffic that come down the WG tunnel, also goes back out the WG tunnel
Sounds good.
/routing table add fib name=wireguard1_Traffic
# If you have port forwards you need to ensure they stick to the correct interfaces for the return traffic # port forwards from wireguard1, goes back out from wireguard1 /ip firewall mangle add action=mark-connection chain=forward in- interface= wireguard1 connection-state=new new-connection- mark=wireguard1_pfw passthrough=no disabled=no comment="pfw wireguard1, out wireguard1" /ip firewall mangle add action=mark-routing chain=prerouting in- interface=bridge-local connection-mark=wireguard1_pfw new-routing- mark= wireguard1_Traffic passthrough=no disabled=no
This is new territory for me! What ties the inbound interface of the arriving packet to the outbound interface of the response packet? The first mangle rule marks the new connections arriving on the wireguard interface to be forwarded with a mark called "wireguard_pfw". I am guessing this causes all future packets that are part of that connection to be similarly marked? The second mangle rule adds a policy routing mark called "wireguard1_Traffic" to any packets marked with the "wireguard_pfw" mark IF they are in the pre-routing chain and they are arriving from the LAN (i.e. on bridge-local). The routing mark ties the packets to the FIB called "wireguard1_Traffic". What I still don't quite get is how these rules send a response packet on its way via wireguard1. I see the new FIB, I just don't get how it does what it presumably does :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160