The idea on a network is to have traffic within the network unmonitored and unrestricted but all Internet traffic to-and fro-accounted and given priority.
Everything on the network falls within subnets of 10.0.0.0/16. User-Manager/RADIUS allocates pppoe addresses in the 10.100.0.0/16 range.
srcnat does not influence the route/next-hop/outgoing-interface that is used to forward a packet.
It’s the other way around, i.e. if the routing code decides that a packet will be send out on interface ppoe-out1 then a particular srcnat rule might be selected for this (because it has a matching out-interface), but not vice versa.
"srcnat does not influence the route/next-hop/outgoing-interface that is used to forward a packet. "
No, but the rules above should surely have the effect of giving every packet with a 10.0.0.0/16 destination address a source address of 10.0.3.2 (wlan1) and routing it via wlan1, and every other packet a source address of 10.100.3.2 (pppoe-out) and routing it via pppoe-out.
But everything, including 10.0.0.0/16 addresses, is being routed out of pppoe-out, it seems.
All these entries are dynamic so can’t be altered or deleted. I could add a dst=10.0.0.0/16 > gateway 10.0.3.2 but that would just be duplicating the firewall rule.
Well, with this routing table it’s clear that packets with destination 10.0.0.33 choose the default route and get sent out on the pppoe interface. It appears that you need to change your routing, and only after that works the way you need it to you then can take care of srcnat…
And this despite the fact that the firewall filter rule is set to send them out of the wlan1 interface.
And I read in the MT manual that routing is done BEFORE firewall rules are applied.
I can’t see the correlation between the route tables and the filter rules - yes routing would sent 10.0.0.0/16 traffic to the default route over pppoe but why doesn’t the firewall filter rule then pick them up and redirect them to wlan1?
Because redirecting something is not the srcnat’s job at all. The out-interface parameter in the srcnat rule is not an action parameter; it does not work the way of “when the packet is handled by this rule, then set the out-interface to this”. The out-interface parameter is a match condition for the srcnat rule. It works like “if the packet will go out on that interface (as has already been decided by routing before the srcnat rule is even checked) then this srcnat rule will apply, otherwise skip it altogether”.
Okay… So in fact I don’t really need two srcnat rules? A simple:
“If destination=anything forward, src.nat it=masquerade.” would do?
I’m guessing that would result in some data being srcnatted with the wlan1 address and some with the pppoe interface but I don’t see how that would be a problem.