When you have full access to the Linux firewall facilities, it is usually easier to
put a "packet mark" on certain traffic arriving from internet, and then examine
that packet mark once you are past the tunnel decapsulation.
The trick of looking at the MAC address stopped working long ago, and it also
affected logging possibilities :-(
Before that, when a LOG action was done in a firewall rule matching tunneled traffic,
it would log the outer IP packet in the MAC address field and it was possible to
determine
which internet host had sent the tunneled packet (I had a script for that). No more.
But now I use this:
# amprgw AMPRnet outgoing tunnel
AMPRGW="169.228.34.84"
# MARK codes for marking packets
M_AMPRGW="1/1" # tunneled packet from AMPRGW
iptables -t mangle -A PREROUTING -p 4 -s $AMPRGW -j MARK --set-mark $M_AMPRGW
this marks the incoming traffic from AMPRGW. then in the input filter:
iptables -A INPUT -i tunl0 -m mark --mark $M_AMPRGW -j amprinp
so I can redirect traffic from AMPRGW to a separate chain and allow RIP there.
To spoof this you would have to spoof the external address as well (possible, of course).
You can do the same thing in a MikroTik router (where there already are symbolic
names for packet marks so you do not have to keep a symboltable yourself).
Rob
On 1/26/22 21:54, lleachii--- via 44Net wrote:
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