Hi This is the standard output coming on from the amprgw gateway over protocol 4 tcpdump -ni eth# proto 4 on your linux server in/out interface to gatewaay (firewalled) address entry for the 44net subnets that my system serves to mine and my downstream UK link partners over amprnet IP over UDP tunnels)
Address 3 and Address 4 would (idealy) normally be axpected to be from 44net. Those that are non 44net, are mostly from attacking scanning system. I am not going to mention countries for too many.
How do you determing a valid non amprnet address as being trusted you can not.
(I have other security filtering devices (Firewalls) infront of my gb7cip system including it's own denigh all firewall in/out unless a valid rule is in place) So I only see BANDITs scanning attacking via the protocol 4 (tunl0) all get blocked as rule state address3 and address must be from 44net /9 and /10 (restricted valid range as of July 2019)
Someone else can do the trace themselves on their server Internet facing interfaces dmz. and output interfaces to their system running their services. This issue is not new. Just getting worse de Paul g4apl
On 11/11/2020 12:27 lleachii--- via 44Net 44net@mailman.ampr.org wrote:
Paul,
Wait...are you saying that you're receiving IPENCAP packets from a registered gateway - that contains malicious or invalid traffic?
Or that you see malicious traffic with an internal source IP matching the subnet registered to GB7CIP??? (AMPRGW doesn't send 44 packets unless they's BGP, as I recall...)
Or that you're receiving routes from a source other than AMPRGW???
In networking context, it's not completely clear what you mean by "pairs of addresses". I don't understand the need to obfuscate the IPs.
<gb7cip hosted 44net: gateway routes>
- KB3VWG
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
This email has been scanned by Netintelligence http://www.netintelligence.com/email