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
> No, it is not ok.
> It is working because of connection tracking if YOU access the page.
> Here the output ofhttp://yo2tm.ampr.org/nettools.php ping:
> Ping Output:
> PING 44.153.32.97 (44.153.32.97) 56(84) bytes of data.
> --- 44.153.32.97 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 2999ms
Indeed, it is not working correctly.
He sent me a mail telling me that he could ping me at 44.137.41.97 and I happened to be
at the computer when it came in, I immediatelu tried to ping back and it worked.
Then I waited an hour, tried again, and again it did not work.
So all symptoms point to a stateful firewall of IPIP traffic, probably in his ISP router.
I suspect that some NAT routers do a connection tracking firewall even when the DMZ HOST
is set in the config. The DMZ HOST only receives all TCP and UDP traffic, but not protocol-4.
However, just like all other hosts on the LAN, it can send out protocol-4 traffic and
receive the "reply" traffic. So doing outbound connections works, but inbound on an
idle tunnel is not working.
It would be interesting to investigate which routers suffer from this bug, so a list can
be made on the WiKi page. I think quite some gateway stations have this fault.
The operator believes he has a working gateway because he can connect whatever other
gateway station he tries, but incoming connects do not work when there has been no
prior traffic.
(of course the same thing happens when DMZ HOST is not set at all, so this has to be
properly investigated)
Rob
Hello !! as I can test the ping to my ip ..
my route in dmz activated addressed to my pc
I tried the page http://yo2tm.ampr.org/nettools.php
and it's OK !
my ip is 44.153.32.97
---------
Hola !! como puedo testear el ping hacia mi ip ..
mi route en dmz activado dirigido a mi pc
yo probe la pagina http://yo2tm.ampr.org/nettools.php
y esta bien !
mi ip es 44.153.32.97
--
======================================================================
La vida nunca nos depara lo que queremos en el momento apropiado. Las
aventuras ocurren, pero no puntualmente.
-- Edward Morgan Foster.
======================================================================
__ __ __ __
| / \(__\| \/ |_ BBS GF05OM TORTUGUITAS 145010Mhz
|__\__/ __/|__/\__|__ TELNET LU9DCE.DYNU.COM PORT 6300
== power by linux === NODO LU9DCE.DYNU.COM PORT 3694
## AMPR NET 44 // LU9DCE.AMPR.ORG // 44.153.32.97 ##
*** https://www.facebook.com/groups/newpacketradio/
Hello everyone
I have a running FBB baires
I would like to have a fwd with a colleague
europe or usa network by 44
if there is any colleague who could - I would appreciate
I leave my email lu9dce(a)gmail.com
regards
73
--
======================================================================
El joven conoce las reglas, el viejo las excepciones.
======================================================================
__ __ __ __
| / \(__\| \/ |_ BBS GF05OM TORTUGUITAS 145010Mhz
|__\__/ __/|__/\__|__ TELNET LU9DCE.DYNU.COM PORT 6300
== power by linux === NODO LU9DCE.DYNU.COM PORT 3694
## AMPR NET 44 // LU9DCE.AMPR.ORG // 44.153.32.97 ##
*** https://www.facebook.com/groups/newpacketradio/
> Subject:
> [44net] test ampr bbs
> From:
> Eduardo Castillo <lu9dce(a)gmail.com>
> Date:
> 10/12/2016 06:46 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> pls test bbs 44.153.32.97 port 6300 !!
>
> send report !! my mail lu9dce(a)gmail.com !! tks !!
I can't connect it. There appears to be a tunnel route to 44.153.32.97 via 181.192.58.28 but I
can't even ping 44.153.32.97 so probably there is some issue, maybe the wellknown NAT DMZ issue?
Rob
