> I've already tested the 44.0.0.1 address using loopback and it
> works ok, and I've tested inbound using 44.128.0.1, and it
> works ok too. I think things will be ok.
> I don't like to bother the campus networking people more than I have to.
Ah, I thought that 44.0.0.1 was running on the same machine as amprgw and
would be moved as well... so that ciould be done before. Apparently it is
a different box.
Rob
> Don't most hosts and routers ignore ICMP Redirects
> out of security concerns these days?
Certainly for such external addresses. Locally on the LAN it usually works.
(e.g. when you have two routers and one sends redirects to the address of the other,
both in the local subnet)
Rob
> - brought back option -r, to allow using multicast sockets by default
> and raw sockets as a backup for systems with multicast issues. This will
> hopefully sort out the firewall filtering inability on previous releases
> since 1.13.
I had to put back the -r option that I had cleaned up from my start script
as it still does not work with the multicast socked on Debian Linux with
kernel 3.16. I remember it failed after some kernel update and it apparenty is
still broken. However, I do not mind using the -r option, only want to
remind people that they may need to put it back.
Rob
We do not send outgoing traffic via amprgw so no change is necessary, but I updated
the address on our info page (that says "use our address instead of 169.228.66.251 as your default gw").
It would probably be a good idea to change the route for 44.0.0.1 before the incoming routes
are switched over, so it can be tested from the inside.
Rob
All,
It's my understanding that there are multiple copies of the original
Startampr script on the Internet. What I have not noticed until alerted
by two operators that attempted to implement those copies in their
devices, are the following:
- Scripts NOT distributed from my site at http://44.60.44.10 ON AMPRNET
include the misuse of the -a argument to run the RIP44 daemon(s).
- The syntax used on the Internet scripts ('use -a argument to remove
your allocation from the table' by a. specifying WAN IP IN rip44d; vs
b. specifying 44 allocation CIDR IP as in ampr-ripd, are reversed.
- This appears to be a documentation bug made by a copier who used my
original scripts (made for rip44d) and converted them to work for ampr-ripd.
- if you use my scripts placing lookups for your local 44 LAN in the
main table, this issue wouldn't affect you
73,
-Lynwood
KB3VWG
> >/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
