Hi,
So Andrew Oakley's suggestion re connection marking seems to be the last piece needed. If only I understood it :-) This is the same principal as if you have a router doing Dual WAN. You need to ensure packets coming in one interface go back out the same interface. That's all it is.
A) Create a Routing table /routing table add fib name=wireguard1_Traffic B) Create a mangle rule to mark connections that come in and are forwarded in interface wireguard1. We mark these with the connection mark wireguard1_pfw /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" C) Now when a packet come in through the interface bridge-local or whatever our bridge is, that already has the connection mark wireguard1_pfw, we add the routing mark wireguard1_Traffic to that packet. /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 D) now I missed this out from my original post, you also need to tell the routing table what to do with such packets. Where X.X.X.X is the internal IP on the wireguard tunnel at the non Starlink end. So this is where the outbound packet from the starlink end goes so it goes back out the same way it came in /ip route add dst-address=0.0.0.0/0 gateway=X.X.X.X distance=1 routing-table= wireguard1_Traffic disabled=no comment=" wireguard1_Traffic" So for completeness A-D above is normally combined with 2 rules on the input/output chain also so packets on the input chain (i.e. destined for the router at the starlink end, not being forwarded through the router) also go back up the wireguard tunnel. # what comes from wireguard1, gets out from wireguard1 /ip firewall mangle add action=mark-connection chain=input in-interface=wireguard1 new-connection-mark=wireguard1_conn passthrough=yes disabled=no comment="in wireguard1,out wireguard1" /ip firewall mangle add action=mark-routing chain=output connection-mark=wireguard1_conn new-routing-mark=wireguard1 passthrough=no disabled=no So a complete set that deals with forwarding and input/output traffic at your starlink end would look like this. This might make more sense outlined in this fashion. - Where 192.168.31.1 is the remote (non-starlink end out the wireguard interface) - if you take a dummy router with # Define routing table and routes /routing table add fib name=wireguard1_Traffic /ip route add dst-address=0.0.0.0/0 gateway=192.168.31.1 distance=1 routing-table=wireguard1_Traffic disabled=no comment="Wireguard1" # Input/output rules # what comes from wireguard1, goes out from wireguard1 /ip firewall mangle add action=mark-connection chain=input in-interface=wireguard1 new-connection-mark=wireguard1_conn passthrough=yes disabled=no comment="in wireguard1,out wireguard1" /ip firewall mangle add action=mark-routing chain=output connection-mark=wireguard1_conn new-routing-mark=wireguard1 passthrough=no disabled=no # Forwarding rules # If you have port forwards (NAT) or simply forwarding through the router, you need to ensure packets 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 passthrough=no disabled=no Final words. Fix the above with a) correct IP for the remote gateway on the wireguard interface b) name of the wireguard interface c) name of the lan interface Then put your remote starlink end router in safe mode and paste it in. Andrew PS - I am available for consulting. -----Original Message----- From: Public <public-bounces@talk.mikrotik.com.au> On Behalf Of Karl Auer via Public Sent: Tuesday, November 7, 2023 10:07 PM To: MikroTik Australia Public List <public@talk.mikrotik.com.au> Cc: Karl Auer <kauer@nullarbor.com.au> Subject: Re: [MT-AU Public] Puzzled why forwarding no work On Tue, 2023-11-07 at 19:19 +1100, Roger Plant via Public wrote:
The dstnat rule is one way to enforce internet packets. If the mikrotik is the main gateway, you can choose source interface. If not you can have match source address to not (address list of lan addresses).
Thanks Roger. I've puzzled over the above for a while, and have to confess I don't understand your second and third sentences unless they both relate to dstnat. The dstnat rule is there to make sure that a packet coming in for a particular port gets sent to the right place - basic port-forwarding. And I have indeed chosen the source interface in the dstnat rule ("in- interface=e1-uplink"). As far as srcnat is concerned I have had a bit of a LOL moment; it's really not part of the solution. Progress has been made though, in my understanding if nothing else. I have allowed my own outside address as one of the remote end's allowed- addresses (0.0.0.0/0 will be needed at both ends eventually I guess). Sniffing shows that my dstnatted packets are now arriving at the remote end of the wireguard link, and also shows that replies are trying to get home over the remote end's uplink, instead of back over the wireguard link. So Andrew Oakley's suggestion re connection marking seems to be the last piece needed. If only I understood it :-) Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer@nullarbor.com.au) work +61 2 64957435 http://www.nullarbor.com.au mobile +61 428 957160 _______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au