Its not perfect. I was just curious as to the shift now being done
direct with BGP.
Probably the most useful information for many would be to correlate
gateways or network space with a rough location.
One might like to coordinate some coordinate some tunneled
activities/traffic with someone in a geographic area for instance. I
for one, would like to know who else in my state is reachable over
44net.
But I don't see an easy way to do that.
> Actually, Steve, because of the host-level filtering at amprgw,
> only 17652 hosts addresses implied in the encap file go anywhere.
> - Brian
That is what I wanted to suggest as well. You cannot calculate the number of
reachable hosts from the subnet sizes alone. Not even when you subtract two
(network- and broadcast address) for every subnet you know about.
And please do not try to resolve this puzzle by trying to ping every host...
Rob
Rob,
Its a count of the number of routed hosts, taken from the encap file
and the BGP announce list.
Small math bug, but the number of hosts was right. So about 10% of
the 44/8 allocation actually goes somewhere.
10/22/16 Routeable Ampr.org 44/8 Net Stats:
ENCAP Total Hosts: 1224922
ENCAP Percent: 7
BGP Total Hosts: 581204
BGP Percent: 3
I created a little script because I was curious, so I figured I'd
share what it told me:
10/22/16 Routeable Ampr.org 44/8 Net Stats:
ENCAP Total Hosts: 1224922
ENCAP Percent: 13
BGP Total Hosts: 581204
BGP Percent: 28
> Quick question, is the EdgeRouter wiki page outdated? Just did it by the
> letter, but I got no outside ping to my router's IP.
Well, what is described there does not constitute a proper AMPRnet gateway,
i.e. with such a setup you can only communicate between your own subnet and
internet via the amprgw at UCSD, *not* with other users of the AMPRnet network!
When you cannot ping from addresses outside 44.0.0.0/8, check:
- is your router IP (and other IPs you want to use) registered in DNS for .ampr.org?
- is protocol-4 traffic being passed to your EdgeRouter?
(not filtered by some other modem/router you may have in front of it)
Rob
Hey folks!
Quick question, is the EdgeRouter wiki page outdated? Just did it by the
letter, but I got no outside ping to my router's IP.
--
Miguel Rodriguez
12th Grade Student
miguemely101(a)gmail.com
Tel: *561-758-0631*
*Accredited District Since 2008; Re-certification - January 2013*
Home of Florida's first LEED Gold Certified School
*Disclaimer*: Under Florida law, e-mail addresses are *public records*. If
you do not want your e-mail address released in response to a public
records request, do not send electronic mail to this entity. Instead,
contact this office by phone or in writing.
> I have implemented the dynamic IPENCAP firewall script in OpenWRT; and
> it works!
I did not mention in the mail that I had to resolve those catch-22 effects as well...
In my system, I initialize the firewall using a shell script that has a long list
of iptables commands in it. I prefer that over manipulating it ad-hoc and then
saving it using iptables-save, because I can put comments in the script, use
variables to hold values like the external and internal IP addresses, etc.
Inside this script, after the commands to erase any existing rules, I first call
the update script I posted that populates the ipipfilter so I can add that in
the rule for incoming -p 4 traffic without getting a nonexisting chain error.
(it is not possible to forward-reference chains in iptables)
For other purposes I now use "ipset" to hold such lists of addresses instead of
a long list of rules that matches them one by one. Is more efficient as well,
but in my Linux version it is not possible to keep hit counters for ipset members,
which I would like to do (to occasionally check which gateways actually send traffic to us).
Using an ipset could resolve the issues that you have been facing, as one can create
the empty ipset before setting up the iptables, put the public address of amprgw
in it (hardwired), then start ampr-ripd and let it receive the tunnel information
and put it in the ipset. You never have unresolved values while doing that.
You can use ipset like this:
ipset create gateways hash:ip
ipset add gateways 169.228.66.251
and then in the firewall:
iptables -A INPUT -p 4 -m set --match-set gateways src -j ACCEPT
The script called from ampr-ripd would then use "ipset add", "ipset del" and
"ipset list" commands to manipulate the set similar to what I did with iptables.
Rob
> Rob,
> You stated:
> "When you are worried about intrusions it is probably more effective to
> block IPIP packets from sources that are not in the gateway list. I do
> that as well (via ampr-ripd)."
> What command/script do you use to add the endpoints to iptables?
I have posted it before on this mailinglist:
http://hamradio.ucsd.edu/mailman/private/44net/2014-November/003577.html
This script manipulates an iptables chain. It would be possible to do a similar
thing with the "ipset" command to manipulate an address list when you are
familiar with that (I wasn't when I wrote this script).
Advantage of using iptables is you have statistics per rule in the table
so you can see which IPIP peers are sending traffic to you. New versions
of ipset support counters but the one I am running doesn't.
With a command like this you get a quick overview of your active IPIP peers:
iptables -L ipipfilter -vn | grep -v ' 0 ACCE'
Rob
> For years, my node had similar behavior, causing various kinds of
> intermittent issues. The problem was solved when I added an iptables
> rule permitting inbound IPENCAP:
Ok in your case it was a configuration error?
Of course we should make sure that there is no error outside the router, e.g. by using
wireshark to confirm that IPIP packets are not arriving when the source is new.
Well, it will be a tricky investigation especially when we have to instruct those that
are not so proficient in networking to determine the cause of the problem.
(gateway system, internet router, maybe ISP filters or cgNAT)
Rob
