44net April 2017

44net@mailman.ampr.org

41 participants
78 discussions

Small corrections and a bug fix: ampr-ripd 1.6.2 and amprd 1.6
by Marius Petrescu 07 Apr '17

07 Apr '17

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.tgz http://www.yo2loj.ro/hamprojects/amprd-1.6.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.16.2.tgz http://yo2tm.ampr.org/hamprojects/amprd-1.6.tgz Have fun! Marius, YO2LOJ

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 06 Apr '17

06 Apr '17

> 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

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 06 Apr '17

06 Apr '17

> 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

4 4

New ampr-ripd 1.16 and amprd 1.5 released
by Marius Petrescu 06 Apr '17

06 Apr '17

Hello! Today I released an update to ampr-ripd (1.16) and amprd (1.5) to support ipip encapsulation on subnets which have their endpoints BGP announced in the 44net space. Just compile and replace your current daemon executable file (stop the old one first). No changes in configuration should be necessary. Get them as usual from my ham project page: Internet: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.16.tgz http://www.yo2loj.ro/hamprojects/amprd-1.5.tgz 44net: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.16.tgz http://yo2tm.ampr.org/hamprojects/amprd-1.5.tgz 73 de Marius, YO2LOJ

4 9

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 06 Apr '17

06 Apr '17

> 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

1 0

Re: [44net] Gatway up
by Rob Janssen 06 Apr '17

06 Apr '17

> 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

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 06 Apr '17

06 Apr '17

> 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

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 05 Apr '17

05 Apr '17

> 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

2 1

Re: [44net] Gatway up
by Rob Janssen 05 Apr '17

05 Apr '17

> 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

3 2

Returning an assignment
by James Sharp 05 Apr '17

05 Apr '17

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?

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net April 2017