Marius,
This would only apply:
* if there were a malicious node on AMPR sending as 44.0.0.1
* someone "accidentally" configured RIP to broadcast routes on their AMPR
interface (though there likely won't be AMPR-routes here and not 44.0.0.1; but this
could wipe our tables with a misconfigured SNAT rule lying around)
And yes indeed, I currently use the 2 rules - similar to what you mentioned, and you know
I'm ever grateful you made sure ampr-ripd works with it!
It will also ensure that a u32 rule works as ampr-ripd does not "pull the route
packets off the wire". ;-)
I had to upgrade my QTH router/AMPR gateway to OpenWrt 20.04.1 running on an x86_64 (I
just cross-compiled with the SDK to the musl-based C running on it), so I have some more
CPUs to work with for more firewall, logging, IDS/IPS, etc. now.
73,
- Lynwood
KB3VWG
----
Excuse the OpenWrt Syntax:
config rule
option src 'wan'
option name 'Allow-AMPR_IPENCAP'
option family 'ipv4' option proto '4'
option ipset ' ipipfilter'
option target 'ACCEPT'
config rule option target 'ACCEPT'
option proto 'udp' option dest_port '520'
option name 'Allow-AMPR_RIP'
option family 'ipv4'
option src 'amprwan' option src_ip
'44.0.0.1' option src_port '520'
option dest_ip '224.0.0.9'