Hello,
I made some small fixes without major functional impact to ampr-ripd:
- Routes where not cleaned up in debug mode, after hitting CTRL-C
- If RIP forwarding was used and the forward interface became
inactive/disappeared, the daemon would not be able to send any RIP
updates. This use case can occur e.g. if ampr-ripd is providing RIP
broadcasts for a jnos via a tunnel. On jnos crash the tunnel would fail
and would not receive route updates after restart (tnx. Gus, I0OJJ for
report and testing the fix).
If these issues have not bothered you until now, there is no urge to
upgrade.
There was also a bug in amprd, which would not set the needed host
routes if rip_set_routes was set to 'no'.
Also, the password is hard coded in amprd, too (like in ampr-ripd).
Sooo:
http://www.yo2loj.ro/hamprojects/ampr-ripd-1.16.2.tgzhttp://www.yo2loj.ro/hamprojects/amprd-1.6.tgzhttp://yo2tm.ampr.org/hamprojects/ampr-ripd-1.16.2.tgzhttp://yo2tm.ampr.org/hamprojects/amprd-1.6.tgz
Have fun!
Marius, YO2LOJ
> I've sorted the source address and am now originating with a source
> address of 44.131.14.255.
Now I can ping those two other mentioned addresses
> I guess this also highlights another issue, does anyone have a pointer
> to the correct way to set up filters for this? I have added some quick
> rules to prevent my gateway being a public IP relay, but it looks like
> many others have not. I am not sure the correct way to configure these
> filters for the general use case. I should now be discarding all
> packets that don't have a source or destination within my network, but
> I do not check for spoofing beyond that. This should be "good enough"?
> Clearly, others have gone further.
Well, what I have done up to now is a filter to allow IPIP traffic only
from registered IPIP tunnel hosts, but no further. There is no strict
"reverse path" checking yet, so anyone with a registered tunnel could in
fact spoof traffic for any source IP. Maybe I'll fix that later, but
for now I decide to allow traffic that may be routed somewhere else and
then forwarded in a tunnel. The main purpose of the filter is to keep
out the opportunists on Internet that could try to get around a firewall
using tricky tunneled packets, not to regulate what the AMPRnet users can do.
(I have seen examples of unwanted IPIP traffic, and lately GRE is a popular
target as well, so similar filters are in place to allow GRE only from
locally registered GRE endpoints)
The filter is done as a -x script called by ampr-ripd when it updates the
route table. The script is like this:
#!/bin/sh
# script called when ampr-ripd updates route table
# load encap.txt into ipipfilter list
AMPRGW="169.228.66.251"
gwfile="/dev/shm/gw"
cd /var/lib/ampr-ripd || exit 1
grep addprivate encap.txt | sed -e 's/.*encap //' | sort -u >$gwfile
if iptables -N ipipfilter 2>/dev/null
then
iptables -F ipipfilter
iptables -A ipipfilter -s $AMPRGW -j ACCEPT
while read ip
do
iptables -A ipipfilter -s $ip -j ACCEPT
done <$gwfile
iptables -A ipipfilter -j LOGREJECT
else
iptables -L ipipfilter -n | grep ACCEPT | fgrep -v $AMPRGW | \
sed -e 's/.*-- //' -e 's/ .*//' | sort | diff - $gwfile | \
while read d ip
do
case "$d" in
">")
iptables -I ipipfilter -s $ip -j ACCEPT
;;
"<")
iptables -D ipipfilter -s $ip -j ACCEPT
;;
*)
;;
esac
done
fi
rm -f $gwfile
This updates the "ipipfilter" chain that is used in the input firewall like this:
iptables -A firewall -p 4 -j ipipfilter
I use this method to have some statistics of traffic per endpoint as well, when you
don't need that it would be better to use ipset to maintain an address set to be
matched by a single iptables line.
Rob
> If you want to test it, 44.131.14.254 is a second loopback on the
> gateway that is used for status monitoring. 44.131.14.192 is a unicast
> node "inside" my network to check end to end connectivity.
Your network is OK in our routing table. I can ping 44.131.14.255 but not
those other addresses.
Rob
> Can you ping .254? .255 should go direct and .254 should be
> encapsulated to the same machine.
No
> Do you have an address I can test to? I have been doing a few tests
> and it would appear that there are some issues here.
44.137.0.1 should be fine, and 44.137.41.97 as well
> Previously I was able to access services that were public the same as
> an external host, but now many of those are not working. As an example
> 44.137.0.1 works fine from an external IP address, but not a
> 44.131.14/24 one. I have found at least 1 host responding to my
> encapsulated packets with ICMP Administratively Denied, which makes me
> suspect that the problem is actually my anycast setup with my source
> address not matching the gateway address.
It is. Now I see what is wrong, the firewall log is full of:
Apr 6 19:47:01 Packet REJECT: IN=eth0 OUT= SRC=45.63.97.98 DST=213.222.29.194 LEN=104 TOS=0x00 PREC=0x00 TTL=52 ID=19182 DF PROTO=4
That source address apparently belongs to you but it is not the tunnel endpoint.
We reject all protocol 4 traffic from hosts not in the RIP broadcast for tunnels.
Rob
> We do this for a large percentage of our customers without issue. We route public subnets to customer specific firewalls which then translate those addresses to internal hosts:
You are doing NAT. I know this is customary in commercial internet practice but in HAMNET/AMPRnet we don't like NAT.
(too much time is wasted by debugging the issues caused by inserting NAT into networks that also have direct routing)
Rob
> Now another question about directly connected 44net addresses - is there
> a way for them to reach tunneled addresses? I would prefer to have my
> services accessible from all 44net addresses when I start offering
> something serious later this year. ATM, it appears my /24 would be
> unreachable from these addresses, because even if there is a host route
> to an endpoint, the 44net address is not exposed to directly connected
> endpoints (they see the public IP of my router). And those direct
> connected addresses not running tunnels wouldn't reach me for obvious
> reasons.
When you get BGP routing on internet for a certain subnet, you should install
and register an IPIP tunnel gateway for the same subnet as well.
Until now this required a public (outside net 44) IP address on the gateway
system, but with the mod discussed in this thread you may be able to put the
tunnel endpoint inside your BGP routed subnet.
Of course it will take some time for all people to pickup the necessary
software and configuration changes for this to actually work. So you will
still be reachable for only part of the users for some time.
Rob
> Now, ampr-ripd does identify this host as directly connected, which
> appears to be the expected behaviour with the new version. All well and
> good from the Pi, but there is one significant implication - the source
> IP is no longer my 44 net IP, but it's the public IP of my router, and
> the internal IP is the 10.x IP of the Pi (my regular IP range. I think
> that's where things are breaking.
Ah yes, it would be better when ampr-ripd added a "src" option with the IP
of the tunnel interface to the /32 routes it adds to the table...
Rob
> Good morning all,
> I seem to have my gatway up (44.131.192.128)
> It responds to some of the ampr ping tools in the service list but not others. Could I ask a few of you to ping it and see if you can see it.
It works!
Note it is a bit controversial to use the first (and last) address of your subnet.
You may run into problems sometime. You have a /29 so you should use 6 addresses.
Also, please register DNS names for your addresses.
Rob
I have a small subnet I was assigned by the Florida administration. I
have since moved to Nevada. Should I return the assigned block and get
a new one from the Nevada coordinator, just to keep things square and
straight?
