> 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.
What I mentioned in my earlier post is that a "protocol unreachable" (for
protocol 4 packets) is a serious condition although it could still be valid
when encountered by amprgw and not by the other gatways.
A "port unreachable" for UDP port 520 indeed is not an error condition.
The gateway may not be using RIP. Or, the firewall may have been configured
to reject port 520 traffic while ampr-ripd -r is still processing it.
(not likely because the RIP traffic is multicast so would not normally be
replied to by the firewall)
To do some better "gateway alive" testing I think some extra steps are
required:
1. a mandatory field has to be added to a gateway registration entry,
with an IP address inside the routed subnets that is pingable.
(of course getting everyone to enter this data will be difficult)
2. a separate "monitoring station" has to be setup that acts as a gateway
and pings that address regularly (but not overly often) and keeps
stats on the returned pings.
The monitoring station has to be separate from amprgw because some people
choose not to tunnel to amprgw.
Alternatively, a checkbox could be added to gateway registrations to specify
if the gateway wants to receive internet traffic (to be handled by the
amprgw firewall table) and it could be made mandatory to tunnel to amprgw.
That would probably be preferable, as it would also make 44.0.0.1 reachable
for those gateways that do not want to get internet traffic.
Adding the fields to the gateway registration system should be straightforward,
but of course getting everyone to enter them wouldn't be.
Not responding to a request to enter information of course could be treated
as an indication that the gateway is no longer active.
Rob
> There is also the question of how this data is to be transferred
> from the portal to amprgw. We currently download the same encap
> file that any gateway would use. Some new file format would also
> be needed.
It should be trivial to add another file, gateways.txt, that contains
the per-gateway information. Or it could be added as comment lines into
the existing encap.txt file. Maybe it would also make some tunnel
creation scripts simpler when there is a section with gateway info
(one line for each gateway, with a unique ID, the external IP, and
info like proposed today: an internal IP and the "accept internet traffic"
flag) ahead of the traditional route lines. It would allow the preparation
of all required tunnel interfaces in environments where that is required
before parsing the subnet routes.
Rob
All,
FYI, I'm not sure if anyone may be interested in setting up a portion of
their allocation with an AX.25 ports (I definitely am). I informed the
LEDE developers that they provide the kmod-ax25 package and its
dependency; but do not provide libax25, ax25-tools and ax25-apps.
The bug report can be found here:
https://bugs.lede-project.org/index.php?do=details&task_id=802
73,
- Lynwood
KB3VWG
I got to thinking about Ronen's question as to how to find non-functional
gateway, and I've come up with a scheme.
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.
If an ICMP unreachable packet is received, the matching gateway is
removed from that cycle, so with luck (if the unreachables get here
quickly enough) we'll only send one or two packets to a gateway that's
not reachable.
The time and gateway address are logged; some future process should be
able to analyze this log and do something about the gateway if it's out
of service long enough. (What it will do about it isn't exactly clear
right now.)
This doesn't seem to have slowed down the rip sender much if at all.
- Brian
> That's actually a limitation on how multicast works. In usual
> circumstances, a router does not listen to multicasts not originating
> from the subnet its interface is connected to.
Could that be the reason why ampr-ripd multicast mode does not work for me?
I always put the local address /32 on the tunnel interface. Maybe it would
work when that is changed to /8 ?
Rob
> I'm curious, what Router OS are you using?
Debian Wheezy with backport kernel 3.16
Also Raspbian Wheezy with kernel 4.1.19+
Well, it probably is some setting. It has worked before but lately I
have not seen any RIP packet in the iptables counters, even though I see
them with tshark.
Now I just use -r and that works. Not worth to spend effort on.
Rob
Hi there
I understand that two ways optional to send RIP info
1) multicast (what now is operative)
2) direct transfer
The multicast require that both interfaces AMPRGW and the ham gateway will have same netmask (in our case /8)
is it the same with the direct transmit ?
If yes why the multicast way was chosen ? what is the benefit ?
Thanks for any info on the subject
Ronen - 4Z4ZQ
Well, when you implement it correctly a dynamic block of incoming scanners
will not block the replies to your own outgoing connections.
First allow ESTABLISHED,RELATED and then block the IPs of detected scanners.
Rob
I was in the process of selecting a netflow viewer -- most of them are
web-based -- when it occured to me that someone using it could discover
every connection that someone has made through the amprgw router.
The flow data records source and destination address and ports, how much
traffic was transferred, the time of day, and how long the connection
lasted. Every flow record is about 50 bytes of data, and there can
easily be a hundred of them per second. In aggregate, it's a lot of data.
And it has privacy implications.
I was originally considering making an interactive netflow inquiry tool
available on the gateways section of the gw.ampr.org website so gateway
operators could see what traffic their AMPRNet router is handling.
But because there's no way to restrict it so that someone could only
view flows involving their own endpoint or subnet, I think it's too
much information to be made freely available for people to browse.
And there is the consideration that inquiries could wind up presenting
a significant load on the system.
I think that presenting anonymized aggregate data wouldn't be a problem,
so I'm going to look into that. Probably some traffic density graphs
would be ok. And I'm willing, once the tools are installed and working,
to make extracts of the data for a gateway operator who is having a
problem with his traffic flow.
What's people's opinion of this?
- Brian
Hi
I was "playing" with my AMPR Router yesterday
I had a open user (on purpose) and saw that from that user few IP (not my ones) were logged in
after some more research i have discovered that this users was opening connections to other hosts ....
That made me suspicious on what going on ....
I have checked one of the IP that was connected and back resolve showed customer.worldstream.nl comming via SSH
I understand something not good happening i have closed this user rebooted the router (to clear the connection )
and then i started to get alot of connections to port 22 to my router from that host
I had to put Firewall rule (drop) for that address and destination port (22)(although im against fire-walling)
After less then 24 hours the traffic stopped from that host the trafic (Via UCSD (Encapped) went down from 19 KBytes/sec to less then 1 Kbyte/sec
now. I know how to deal with the technical aspects (firewall .etc)
What is not understand to me is what is the purpose ... If it is a robot what is the point of fluddling SSH connections is it brute force ? or anything else ? and how come that after 24 hours it stopped it supposed to be endless loop if it is an automated process
Please light my eyes on that if you have more experience then me
currently the router is "quiet" without non wanted users logged in and un necessary connections
I see on the log here and there breake attempt mainly to Ports 23 22 and SIP from various hosts but it is few in a minute
Regards
Ronen - 4Z4ZQ
http://www.ronen.org
Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/>
www.ronen.orgronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com
