I've added code to the rip sender that watches for ICMP unreachable packets coming back to amprgw during the rip sending cycle, which repeats every 5 minutes.
Make sure you act only on ICMP unreachables that refer to the protocol 4, not to the port 520!
When protocol 4 is unreachable, it sure means the gateway is not operational, as it rejects operational traffic. When it rejects port 520, it could be that it is not using RIP to update its tables (it could be downloading encap files!) or even that it *is* using RIP but via raw sockets (ampr-ripd -r) and has a firewall that rejects the packets. ampr-ripd would still see and process them!
That condition could be flagged in yet another status report, but it should not be a base to declare the gateway inactive.
Also, we recently have seen some postings that indicate that some people operate a gateway that has tunnels to all other gateways, but explicitly have excluded a tunnel to amprgw. Because that brings mostly internet traffic and they don't want to have that.
Of course another (not exclusively deciding) check on gateway activity could be to check if you actually receive any tunneled packets from them. I do have that as a byproduct of having an access list that accepts protocol 4 traffic only from addresses of registered gateways. At the moment it shows traffic from 34 different gateways (including amprgw). Of course, when the external address of a gateway changes, its history is lost.
Rob
The collecting ripsender ICMP data is available for you to look at on the web site in file /private/gwlog.txt. It has as the last two columns the ICMP type and code, so 'port unreachable' (code 3) can be distinguished from 'host unreachable' (code 1), 'net unreachable' (code 0), and 'protocol unreachable' (code 2), etc. I'm currently recording all 16 kinds of 'unreachable' in that file.
The amprgw daily gateway statistics files show the number and size of all sent and received traffic for each subnet and gateway, and the age of the route. It should be quite possible to analyze these and find gateways that aren't sending any traffic to amprgw. Of course, there can be gateways such as the one in Germany which uses asymmetric shortcut routing so it never does send any traffic to amprgw even though it's quite active. These files are available via the web server as eg, /private/gwstats.17-05-16.txt.
You're quite right that it's not an easy task to determine whether a gateway deserves to be removed from the portal's encap list. I believe it will take the combination of several factors before that decision can be made. Collecting statistics toward that end is the first step; we can't make decisions without data. - Brian
On Wed, May 24, 2017 at 09:41:19AM +0200, Rob Janssen wrote:
Of course another (not exclusively deciding) check on gateway activity could be to check if you actually receive any tunneled packets from them. I do have that as a byproduct of having an access list that accepts protocol 4 traffic only from addresses of registered gateways. At the moment it shows traffic from 34 different gateways (including amprgw). Of course, when the external address of a gateway changes, its history is lost.
Brian,
I can't find the private data. I see no link on portal.ampr.org, even if I log into the portal. If I log in with FTP, I see only encap and gateways files. How do I find this /private directory?
Off net reply: n6mef at the league.
Michael N6MEF
-----Original Message----- From: 44Net [mailto:44net-bounces+n6mef=mefox.org@hamradio.ucsd.edu] On Behalf Of Brian Kantor Sent: Wednesday, May 24, 2017 2:10 AM To: AMPRNet working group 44net@hamradio.ucsd.edu Subject: Re: [44net] non-operational gateways
(Please trim inclusions from previous messages) _______________________________________________ The collecting ripsender ICMP data is available for you to look at on the web site in file /private/gwlog.txt. It has as the last two columns the ICMP type and code, so 'port unreachable' (code 3) can be distinguished from 'host unreachable' (code 1), 'net unreachable' (code 0), and 'protocol unreachable' (code 2), etc. I'm currently recording all 16 kinds of 'unreachable' in that file.
The amprgw daily gateway statistics files show the number and size of all sent and received traffic for each subnet and gateway, and the age of the route. It should be quite possible to analyze these and find gateways that aren't sending any traffic to amprgw. Of course, there can be gateways such as the one in Germany which uses asymmetric shortcut routing so it never does send any traffic to amprgw even though it's quite active. These files are available via the web server as eg, /private/gwstats.17-05-16.txt.
You're quite right that it's not an easy task to determine whether a gateway deserves to be removed from the portal's encap list. I believe it will take the combination of several factors before that decision can be made. Collecting statistics toward that end is the first step; we can't make decisions without data.
- Brian
On Wed, May 24, 2017 at 09:41:19AM +0200, Rob Janssen wrote:
Of course another (not exclusively deciding) check on gateway activity
could be
to check if you actually receive any tunneled packets from them. I do
have that
as a byproduct of having an access list that accepts protocol 4 traffic
only
from addresses of registered gateways. At the moment it shows traffic
from 34
different gateways (including amprgw). Of course, when the external
address of
a gateway changes, its history is lost.
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
First of all thank you by the names of all of us
in the last few month you raised up the info of the AMPRNET to something that is not shame high tech companies
Now
I dont know how to interprate the numbers
in the left colon i see 3 what is it ? and in right colon i see mostly 3 and 2 and some 10 and 1 what are these ?
For example my gateway show 3 2 what is it is ?it good ? bad ? all i can tell is that my gateway fully operational but dont know what these numbers reflect
can an explain to the numbers added to the stat colon ?
Thanks Forward
Ronen 4Z4ZQ
________________________________
Ronen,
I assume you mean the gwlog.txt file.
This is raw data, designed for a program to read, not humans.
column 1 is the IP address of the gateway columns 2 & 3 are the UTC date and time column 4 is the icmp type, always '3' for 'destination unreachable' column 5 is the icmp code why. '2' is 'unreachable protocol', '3' is 'unreachable port'.
Refer to RFC792 and later RFCs, or the Unix/Linux source code for the meanings of the type/code combinations. Or do a google search for 'icmp type 3'.
For example: 69.85.86.85 17-05-24 02:30:00 3 2
So '3 2' means that the gateway rejected a packet with the message 'unreachable protocol'.
I don't see your gateway '5.29.18.144' in the gwlog file, so it's not rejecting packets from the RIP sender and you're ok. - Brian
On Wed, May 24, 2017 at 02:11:44PM +0000, R P wrote:
I dont know how to interprate the numbers in the left colon i see 3 what is it ? and in right colon i see mostly 3 and 2 and some 10 and 1 what are these ? For example my gateway show 3 2 what is it is ?it good ? bad ? all i can tell is that my gateway fully operational but dont know what these numbers reflect can an explain to the numbers added to the stat colon ?
Thank U
So in other Other words gateways that appear there are ones that consider not responding ..... That what was missing to me....
Thank U
Ronen - 4Z4ZQ
________________________________
I don't see your gateway '5.29.18.144' in the gwlog file, so it's not rejecting packets from the RIP sender and you're ok. - Brian
Well, not exactly. These are gateways or hosts/routers upstream of the gateway that said 'no' to the RIP transmissions. A gateway that is completely dead won't be there either, because it didn't respond at all.
So if they're in the list, something is probably wrong but it's not enough information to declare it dead. - Brian
On Wed, May 24, 2017 at 02:45:57PM +0000, R P wrote:
So in other Other words gateways that appear there are ones that consider not responding ..... That what was missing to me....
-----Original Message----- So if they're in the list, something is probably wrong but it's not enough information to declare it dead.
- Brian
If the gateway doesn't use RIP, then it may also not open that port in its firewall. So it may either drop the packets silently or return ICMP unreachables. Right? If so, then the most we can say about this situation is that the site is not accepting RIP, not that something is "probably wrong". Or am I missing something?
Likewise, regarding a point made in an earlier email: the lack of traffic sent from a gateway to amprgw doesn't mean that the gateway is not operational. In our case, we use amprnet tunnels to communicate directly with other amprnet sites. And non-amprnet folks use our external IP. So, none of our traffic passes through amprgw.
BTW, I applaud all of the stats, Brian. It will help us detect problems we didn't even know existed. We just need to be careful about the conclusions we draw from the data. I know you are. I just didn't see the above points made yet (or perhaps I missed them).
Michael N6MEF
You're right, of course.
I think Rob made much the same points in an earlier email. - Brian
On Wed, May 24, 2017 at 09:47:47AM -0700, Michael Fox - N6MEF wrote:
If the gateway doesn't use RIP, then it may also not open that port in its firewall. So it may either drop the packets silently or return ICMP unreachables. Right? If so, then the most we can say about this situation is that the site is not accepting RIP, not that something is "probably wrong". Or am I missing something?
Likewise, regarding a point made in an earlier email: the lack of traffic sent from a gateway to amprgw doesn't mean that the gateway is not operational. In our case, we use amprnet tunnels to communicate directly with other amprnet sites. And non-amprnet folks use our external IP. So, none of our traffic passes through amprgw.
BTW, I applaud all of the stats, Brian. It will help us detect problems we didn't even know existed. We just need to be careful about the conclusions we draw from the data. I know you are. I just didn't see the above points made yet (or perhaps I missed them).
Michael N6MEF
On 24.05.2017 19:47, Michael Fox - N6MEF wrote:
If the gateway doesn't use RIP, then it may also not open that port in its firewall. So it may either drop the packets silently or return ICMP unreachables. Right? If so, then the most we can say about this situation is that the site is not accepting RIP, not that something is "probably wrong". Or am I missing something?
Sorry to ask but what has accepting RIP to do with the gateway IP? RIP is encapsulated into IPIP, so no firewall will ever care about that. And no sane firewall setup will accept RIP on its WAN. From both the gateway's point of view it's just protocol 4, nothing else.
On 24.05.2017 19:47, Michael Fox - N6MEF wrote:
If the gateway doesn't use RIP, then it may also not open that port in its firewall. So it may either drop the packets silently or return ICMP unreachables. Right? If so, then the most we can say about this
situation
is that the site is not accepting RIP, not that something is "probably wrong". Or am I missing something?
Sorry to ask but what has accepting RIP to do with the gateway IP? RIP is encapsulated into IPIP, so no firewall will ever care about that. And no sane firewall setup will accept RIP on its WAN. From both the gateway's point of view it's just protocol 4, nothing else.
Marius,
I'm not sure I understand your question. But the answer to what I think you're asking is: Correct, for the external firewall. But an inner firewall that acts on the traffic within the tunnel should only accept what it needs and block everything else.
Michael
It is not a question, it is a statement. And it is about detecting inactive gateways.
Brian proposed to collect ICMP unreachable from the gateway IPs, so he could get a list of certainly unreachable gateways. This method is sound, with very improbable false positive results, and could successfully be used for this goal.
And then all started to talk about RIP and the fact that not all gateways use it and so on.
As I said: Gateway reachability has nothing to do with the fact that a certain gateway uses or not RIP, or if RIP passes its firewall or not.
The "ICMP unreachable" pertains only IPIP traffic to the public gateway IP which will be classified as unreachable by the last router before it, route which is totally agnostic about the firewall settings of the (unreachable) target or about its ability to process or not RIP multicasts.
And this holds true as long as no "smart" network manager turns off all ICMP for some delusional security advantages.
On 24.05.2017 20:29, Michael Fox - N6MEF wrote:
(Please trim inclusions from previous messages) _______________________________________________
On 24.05.2017 19:47, Michael Fox - N6MEF wrote:
If the gateway doesn't use RIP, then it may also not open that port in its firewall. So it may either drop the packets silently or return ICMP unreachables. Right? If so, then the most we can say about this
situation
is that the site is not accepting RIP, not that something is "probably wrong". Or am I missing something?
Sorry to ask but what has accepting RIP to do with the gateway IP? RIP is encapsulated into IPIP, so no firewall will ever care about that. And no sane firewall setup will accept RIP on its WAN. From both the gateway's point of view it's just protocol 4, nothing else.
Marius,
I'm not sure I understand your question. But the answer to what I think you're asking is: Correct, for the external firewall. But an inner firewall that acts on the traffic within the tunnel should only accept what it needs and block everything else.
Michael
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Marius,
Not delusional at all, in my security instance, if I were to have IPENCAP closed, I wouldn't configure my device to send ICMP Unreachable messages for it. The perceived gain is that my router doesn't use CPU resources to process a packet I don't want. This is a common configuration of a Firewall that Drops by default - I'm not "forcing" my firewall to do it. It takes additional configuration to accept-then-reject. The drop by default is helpful in scenarios like a DDoS attack at the border attempting to use you for an amplification attack.
- For example, If I don't have SSH open, I won't send ICMP Port Unreachable if a scanner or hacker attempts to connect. Besides, a scanner is probably ignoring them and looking for SYN-ACKs only. - For something like PMTU Discovery, I simply allow ICMP - Fragmentation Needed messages. - On AMPR, the operators have made a troubleshooting case for a need to Ping me, so I permit ICMP Echo Request from your GW IPs and 44 allocations. - Traceroute causes CPU resources to be used on my router or other downstream devices, even for a destination IP other than itself, so I block TTLs >= 7. - In any case, unsolicited packets on my WAN are not considered "legitimate" to me, so DROPping is OK. - In all cases, outbound is allowed, so the reverse path is OK.
http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject When reading this link, recall:
- I have 0 "legitimate users" on the WAN - The only knowledge I'm giving to an attacker whom I drop is my IP, which they already possess - I WANT port scans to fail, even from the LAN (the writer makes an opposite assumption)
73,
- Lynwood KB3VWG
for some delusional security advantages.
It still doesn't improve your security at all. It will just impair proper networking and prevent debugging.
But it's your system, your the boss :-)
On 24.05.2017 22:26, lleachii--- via 44Net wrote:
(Please trim inclusions from previous messages) _______________________________________________ Marius,
Not delusional at all, in my security instance, if I were to have IPENCAP closed, I wouldn't configure my device to send ICMP Unreachable messages for it. The perceived gain is that my router doesn't use CPU resources to process a packet I don't want. This is a common configuration of a Firewall that Drops by default - I'm not "forcing" my firewall to do it. It takes additional configuration to accept-then-reject. The drop by default is helpful in scenarios like a DDoS attack at the border attempting to use you for an amplification attack.
Marius,
LOL my friend, indeed true. In general, it doesn't matter, I suppose...since everyone knows the IP exists on the Internet, but they don't know for certain there's an endpoint on line, or what it serves. The only people who "know" about my [dynamic] endpoint are:
- Me - AMPR OPs - those visiting my HTTP server - those scanning IPs (which I work on blocking); and - those to whom I initiate a connection
They're reduced to guessing and soliciting responses from IPs, while uncertain a device is in fact on line. As for debugging, the only people I permit to debug from the WAN....are you guys. You're all now allowed by your IPs in the portal and your 44 addresses.
:)
73,
- KB3VWG
But it's your system, your the boss :-)
-
Brian Kantor -
lleachii＠aol.com -
Marius Petrescu -
Michael Fox - N6MEF -
R P -
Rob Janssen