- Also, I cannot block receipt of RIP44 packets - SECURITY - a malicious person could craft a packet of AGW and still change routes - a password is sufficient, so we can still distribute routes via ampr-ripd Feature request: - keep password default - keep the -p argument - add an argument to include a password in the -f argument packets (this allows the person to specify a password if they want to receive RIP44 form and agreed 2nd source using the -p argument on their device) - KB3VWG

Marius, It's always assumed a.) the operator "wants" ALL packets and b.) that they always want them to be processed on the same device, at all times. Day by day, we increasingly see that because something isn't YET exploited...but could be, or even other GWs are misconfigured...In truth, I only need to: - See any packet bound for my WAN (broken) - INSPECT/DROP any packet on my WAN that doesn't match my network security policy (broken) - Accept IPENCAP only from assigned 44 IP endpoints (broken) - Accept other multipoint IPENCAP packets (broken) - Accept RIP44 from AMPRGW, Forward it, or to cut it off (broken) - Ability to Forward IPENCAP routing to a downstream device (broken) - get ping from your WAN interfaces - get ping from your tunl0's - Accept connections to services I offer: DNS, NTP, HTTP to 44.60.44.0/24 - The -r only model assumes that all packets on WAN are trusted, and hence accepts ANY IPENCAP packet on the WAN and drops them off on the secure side of my router, unchecked though iptables/etc. Only other iptables/ip rule/ip route statements I've added (prior) prevent this from being a security risk. - The -r uses creates a pseudo Layer 2 on my WAN, just to filter-out and process 1 particular of Layer 3 packet, from 1 particular endpoint - while forwarding the rest, unfiltered - To use the Encap File from the site and not rely on/process any packets from 44.0.0.1 (Stratum 1 redundancy/sanity checking of process AMPRGW uses to obtain the routes) - Temporally stop receipt, remove routes, etc. (more so important since ampr-ripd removes routes on exit, perhaps add an argument to make this an optional feature) - If we could see Rob's 'MAC,' we could possibly efficiently filter between the IPENCAP and inside header (i.e. detect spoofed 44.0.0.1 packet - and possibly, all other 44 addresses) - See firewall hits for this outer traffic - To firewall the other approximately 4 billion IP addresses that can send an kmod-ipip-compatible packet - that my Kernel/ampr-ripd now processes - Prevent unknown issues with interaction with kmod-ipip and ampr-ripd in raw-only mode (e.g. bypassing netfilter) - Prevent a GW/rogue machine from sending packets to - and my sending a response via AMPRGW (there's other ways to do this, but I still need to use other resources to process the outer header as an agent for netfilter, which I NO LONGER HAVE) - Block all other traffic from the Internet without use of additional CPU resources - Block traffic from individual GWs - Distribute packets to routers/sensors//LANs - based on outer header (at this point, I can't run point-to-multipoint IPENCAP tunnels for any reason - except AMPRNet). - Forward traffic to a backup router on-the-fly via change of iptables INPUT rule to a NAT FORWARD rule (possibly implement VRRP, especially for those who use BGPed tunnels) - When running point-to-multipoint kmod-ipip tunnels through your router, needing to end ampr-ripd for any reason would now also crash other non AMPR tunnels (unless the same, but now redundant iptables rule is added; but its effect on connection states are untested). - Lynwood KB3VWG

Ok. I understood a lot of your points. Let me see what can be done ;-) On 2017-05-11 13:52, lleachii--- via 44Net wrote: