> >/Everyone is free to use the -g option if needed /> Yes, but is eth0.2 a valid entry?
The parameter of -g is an IP address. It it not the IP address of an interface but of the gateway to the internet.
So specifying an interface like eth0.2 does not make sense.
You could use something like this:
.... -g `ip route list | grep '^default' | sed -e 's/.*via //' -e 's/ .*//'`
Rob
> Thinking about this, I recall that I run an IPv6 tunnel with Hurricane
> Electric in the same manner. They require that I allow ICMP - Echo
> Request to the border. The tunnel doesn't come online at their end,
> until they receive an Echo Reply from the IP I specified (either
> statically or with DDNS).
> Just a rule used by one ISP.
I think it is not required to allow pings to the outside address, and it may be
difficult for some people to fulfill that requirement (as it may be part of the
setup of their ISP router to disallow these).
Instead, I would like to see that pings to at least one of the gatewayed addresses
are allowed (a net-44 address inside one of the subnet(s) routed to that gateway).
This is also much more indicative of a functioning gateway.
In the IPv6 tunnel example that would mean allowing ping to one IPv6 address.
Of course our problem is that we never asked the gateway operators for the address
of their gateway on net-44. So that would have to be added in the form, the database
and the encap file (or some other file).
Rob
All,
It's my understanding that the operating systems we work with only need
1 tunnel, or one system declaration for it.
Except those OSes listed under "Non-RIP44 Workarounds", does anyone else
run an OS not on the list - that requires you to create more than one
(1) tunnel, specify a remote IP other than "Any", or create a route for
it before you receive traffic?
All I have to do is tell tunl0 to be UP and I'll receive ANYTHING. OPs
using other operating systems seem to have configuration differences
(maybe that's why they don't understand security concerns). I'm not sure
if there's a configuration difference in the Kernels, or what...?
73,
- Lynwood
KB3VWG
It looks to me like the new amprgw is working. I'd like to ask
for a brave volunteer who is willing to try changing his outgoing
route from old amprgw (169.228.66.251) to new amprgw (169.228.34.84)
to see if he's able to make connection with the outside world.
The return path will still be via old amprgw as we haven't changed
the nexthop for 44.0.0.0/8 from oldamprgw to new.
If someone would try this and let me know if it worked I'd very
much appreciate it.
- Brian
In just the past couple of days I got my gateway working. I have a CS
degree, test software for a living and considered myself proficient on
linux but found getting the gateway to work correctly difficult due to
contradictions in documentation and examples. With KB3VWG's help I was able
to get it working. I'll just say it was a little difficult to get it going,
mostly due to understanding how it all works together. I'm using ubuntu
linux as a gateway.
On the subject of non-operational gateways I would consider attempting to
send RIP broadcasts to them at a reduced rate instead of deleting them. In
my case I'm on a dynamic address. It doesn't change often, longest I've had
an address was about 5 months. It's most apt to change if I restart. I
registered my gateway in January... it was down all of Jan and Feb. It's
been intermittent but mostly down since until Monday evening of this week.
Had my gateway been deleted or removed from the list I'd now be offline
rather than online.
Lynwood was a great help with understanding policy routing rules and I'd
like to publically thank him here. He's patient and points things out that
don't work.
I plan to document my journey so others who wish to join the network can
learn from my mistakes. I'm a firm believer in understanding how it works.
--tom /n2xu
--
73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified
I'm now gathering netflow-like statistics from the router daemon.
It's a lot of data.
I've been unable to find a clear definition of the standard (v1 or v5)
netflow disk file format, so I don't have input suitable for any of the
good analysis tools. Does anyone have such a description?
And what are your favourite analysis tools?
- Brian
> IPIP is possible on the SRX but not in cluster (virtual chassis mode)
Being able to setup a single or even multiple IPIP tunnels is not suffcient to
be a member of the AMPRnet IPIP mesh. See what Brian wrote:
> This is a mesh network, not a star, so there is no default route; you
> need a separate tunnel route to each gateway you want to communicate with,
Marius has written a very nice script to get it working on a MikroTik router,
but most other commercial routers lack the scripting capabilities to pull this
off on their own. Someone wrote a script to use a Cisco router but it requires
a separate machine to run it.
Rob
> 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
> 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
