Thank you for the reply Robert, most appreciated.
While testing with snmpget I monitor traffic at 1) the SNMP manager and 2) the NAT device with: "tcpdump -n -e arp or port 161".
Setting the SNMP clientaddr seems to have the desired effect on the IP SRC in the outbound SNMP request, and the policy-route has the desired effect to send to the desired nexthop via the correct interfrace. But it still doesn't work in the end: tcpdump shows the SNMP request and the SNMP response exactly as expected at both 1 and 2 above, but the snmpget command shows a Timeout error (I use -t 5 which is a gracious plenty). The SNMP response is not making it up the stack to the application layer. I don't know where/why it's being dropped. I inserted a gratuitous ACCEPT in the filter table INPUT chain, but the packet count remains zero, so I think it's dropped by the kernel before netfilter sees it. (To further support this belief, if I change the SNMP manager to default route via bond0.2, everything works perfectly - no timeout).
>>> Rule based nat can do it, but that's not your best option. <<<
I thought this was deprecated?
>>> If you want to rewrite the address, then SNAT the packet (that's what snat is for, ha ha ha). <<<
I have spent some time configuring and testing with SNAT too, and I will likely return to that after I understand what's happening in the much simpler case of just setting clientaddr as above.
>>> iptables --append POSTROUTING --match mark --mark 256 --jump SNAT --to-source 192.168.168.7 <<<
192.168.168.7 is the NAT device, shouldn't that be the bond0.2 address of the SNMP manager (192.168.168.3)
��.n��������+%������w��{.n����z���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
