> I believed the problem with pinging from tunneled hosts was
> still there, but if it works for you, I must have forgotten.
It is a bit unclear what is going on. From a host that is exclusively on the IPIP
mesh the ping does not return (I see only the outgoing IPIP packet). From a host that is
both on the IPIP mesh and BGP-routed on internet it does work.
It looks like it replies "directly" (via the BGP route) to the replies sent as IPIP.
Rob
> A standard ripd won't ever see the RIP44 packets because they're
> encapsulated in an IPIP tunnel packet. The standard ripd doesn't
> know how to de-encapsulate them first.
Of course when you have a single multi-point tunnel interface like in Linux (tunl0), you
could have ripd listening on that interface and it would see the correct packet format.
However, I think the default ripd does some sanity checks that make it fail on the special
assumptions made in RIP44.
Rob
Hi all,
I just saw this project on the Github, and it looks related and might
be very interesting to you. Check it out!
https://github.com/brannondorsey/chattervox
An AX.25 packet radio chat protocol with support for digital
signatures and binary compression. Like IRC over radio waves.
Chattervox implements a minimal packet radio protocol on top of AX.25
that can be used with a terminal node controller (TNC) like Direwolf
to transmit and receive digitally signed messages using audio
frequency shift keying modulation (AFSK). In the United States, it's
illegal to broadcast encrypted messages on amateur radio frequencies.
Chattervox respects this law, while using elliptic curve cryptography
and digital signatures to protect against message spoofing.
--
Regards,
Quan Zhou
Hello Group,
I'd like to start experimenting building my own gateway (For
learning purpose).
I am reading different way to do it. Now I am in limbo bettwing :
amprd 2.1 or Mikrotik RIPv2 AMPR Gateway
Can you tell me your experience if you are using any of those options.
Thank you
73 de Jean, VA2OM / VE2PKT
--
Sysop de: VE2PKT (BBS), VE2PKT-13 (URONode)
: VE2RCN-1, VE2RGM-1, VE2RGC-1, VE2RVA-1, (The-Net)
: VE2PKT-9 (DXCluster), VE2PKT-10 (Winlink Gateway)
RF:
147.435 Mhz (1200 Bps),
Internet:
Telnet://nodes-ve2pkt.dyndns.org <http://xrouter-ve2pkt.dyndns.org/> port
23 (Network Node)
Telnet://fbb-ve2pkt.dyndns.org port 6300 (FBB BBS)
Telnet://ve2pkt.dyndns.org port 9000 (DXCluster)
E-Mail:
packet: ve2pkt(a)ve2pkt.#qbc.qc.can.noam
ampr net: ve2pkt(a)ve2pkt.ampr.org
Inet: ve2pkt(a)gmail.com
> I'll read this carefully and figure it out...I was a BASIC and C++
> man...shouldn't be too hard.
There is always a lot to learn...
But in shell scripting, the following two do the same thing:
if command
then
and:
command
if [ $? -eq 0 ]
then
Similarly:
if ! command
then
is the same as:
command
if [ $? -ne 0 ]
then
It reads easier (once you know) and it avoids the situation where someone
inadvertently puts something between the command and the 'if' that resets the $?
e.g. some attempt at debugging like 'echo $?'.
Rob
> Also, don't put a space between these two lines:
> > ipset -N ipipfilter hash:ip 2>/dev/null
> > if [ $? -eq 0 ]
It would not be a problem to have a space between those, but of course there should
not be other things, and having a space there maybe invites that.
You would better write this as:
if ipset -N ipipfilter hash:ip 2>/dev/null
then
...
else
...
fi
so it is clear what is going on and that the result $? of the ipset is to be processed by the if.
Rob
> I believe a significant number of people who have AMPRNet addresses
> and are BGP-connected really don't care much about communicating
> with other IPIP mesh-connected hosts; their interest is the rest
> of the Internet.
Of course traffic mostly tends to be local and we see some IPIP mesh
traffic to stations in the area that are IPIP mesh connected, including
country networks like Germany.
Most traffic is between AMPRnet addresses connected on radio or VPN,
and between those and internet.
It is understandable, because many IPIP mesh stations are small islands
at the other side of the world and there is little chance that someone
here would want to send a lot of data to them.
On the other hand, connections internal to our network are used to
interconnect repeaters (both voice and ATV) and for things like echolink
and they transport a lot of data, mostly local.
> Since there's no way to capture flow data for these folks, we'll
> never know where their traffic is going. All we can do is guess
> from anecdotal data.
Maybe we can setup some ip flow export...
Rob
You can also use ipset in Linux and OpenWrt to filter from the RIP44 announcements. I only allow Protocol No. 4 from you all.
I have the script; it's a slight modification of the one found on the Firewall Wiki.
It can be set to run with the -x argument after each RIP44 announcement on ampr-ripd.
Let me know and I'll send a TXT file of it.
- Lynwood
KB3VWG
> Ah ah ah, it's very complex to common mortals as me :)
> Perhaps it is mature the time to adopt, after many
> years, the *SIMPLE* implementation created by Maiko
> VE4KLM for JNOS2, applying it to our systems:
> ------------
> 3) Configuration
> -------------
> When adding a 44 route, typically one uses something like this :
> route add 44.0/8 encap a.b.c.d
But does that automatically add the two levels of firewalling that we are
discussing here? If not, it does not seem very relevant. It is quite easy
to make a configuration that basically works (especially when using RIP which
makes route statements like the above unnecessary), but the point is that it
is not secure against abuse by malicious people. That is why additional
work is needed.
Rob
> It is also a good idea to block forwarding from/to AMPR interfaces other
> than your own internal 44 network.
That is right! At first you filter IPIP packets in the input chain to allow only
packets from the list of gateways (public addresses). In Linux this can be done
with ipset and on the MikroTik using an "address list" (which is just their UI around
ipset), or you can dynamically maintain a list of rules.
(which allows to maintain counters per rule, also possible with recent kernels and ipset)
Then, there should be a forward chain rule on the tunnel interface that only accepts
incoming packets to the net-44 subnets you have published in the portal. You don't
want to accept traffic destined for other addresses and then forward that.
It would also be good to filter traffic forwarded TO the tunnel interface to only
accept valid source addresses (your own networks), mostly to cover one's own mistakes
in handling NAT.
Both of those rulesets would have blocked the described scan.
Probably it would be a good idea to include some working firewall example on the
Wiki (for the different environments desrcibed) so everyone can have a secure firewall
without in-depth knowledge about this matter.
Unfortunately I have little knowledge about the particular methods used to load iptables
on the different Linux distributions: the first thing I always do when installing a
machine that does advanced routing is to remove their firewall maintenance packages
and replace them by a init.d script that just uses iptables statements to build it at
boot (or reload) time. That allows me to use variables, comments, shell constructs,
etc which is much more maintainable than those "iptables-save" or automatic firewall
maintenance solutions (when you install some package, corresponding ports are opened).
Rob
