44net

44net@mailman.ampr.org

3170 discussions

Re: [44net] Tunnel mesh is (mostly) down

by Rob Janssen

> Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 01/05/2015 07:26 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Mon, Jan 05, 2015 at 02:27:18PM +0200, Marius Petrescu wrote: >> >Let me get this right... You are talking about the encapsulated RIP >> >transmissions originating from 169.228.66.251 to each public gateway IP? >> > >> >-----Original Message----- >> >On Behalf Of Rob Janssen >> >Sent: Monday, January 05, 2015 11:11 >> >To: Brian Kantor >> >Cc:44net@hamradio.ucsd.edu >> >Subject: Re: [44net] Tunnel mesh is (mostly) down >> > >> >Maybe something else you can do is drop the extra transmission of RIP >> >packets from the public IP >> >address. I think nobody is really using those (if not because of the funny >> >destination port number), and >> >they only add to this problem by putting even more data in the queue. > Up until a few minutes ago, the amprgw system was sending the RIP data > twice - once UNencapsulated to the public gateway IP, once encapsulated. > > Since to the best of my knowledge, no one was using the UNencapsulated RIP > for anything, I've discontinued sending it. > > If I'm wrong and someone is using it for something, I'll turn it back on. > - Brian > > > Note that those transmissions were sent to a seemingly random destination port number, which made them kind of hard to use. The source port number was always 520. I don't know if that was a bug or a feature, but it puzzled me when I was trying to receive them and could not get the encapsulated transmission working in ampr-ripd. (an issue that I later located and Marius made a change that fixed that) Rob

10 years

AMPR Portal Error for Coordinator

by William Lewis

Chris / Brian. I had a new request for an AMPR addresses allocation from the portal, but there seems to be a couple of issues. First, I never received the new request via email as I usually do. Not sure why I didn't get this request. Second, the user that submitted the request accidentally select my network of 44.002/16 when he should have selected Daniel Curry's network of 44.004/16. In the coordinators section of the portal, when I tried to DENY the request, the page refreshes and I get an error in red stating : "There are children but selected owner is not a coordinator." and I can not deny the request. I have contacted the user who submitted the request and informed him to make another request on the correct network. But, it appears there is a bug on the portal that is not sending me email notifications and not letting me deny requests. Thanks for looking into this. ---------- Wm Lewis (KG6BAJ) AMPR Net IP Address Coordinator - Northern and Central California Regions (A 100% Volunteer Group) (530) 263-1595 (Home/Office) ______________________________________________ ---------- This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited.

10 years

Linux policy routing explained briefly

by Brian

There seems to be a bit of confusion as to how linux routes via policy routing. The tool which appears to be the most flexible is "ip" found in the iproute2 package. The two key switches are "route" and "rule", and they do exactly what they sound like; one manages routes and route-tables, while the other manages the ruleset in which these routes/tables are called upon. Linux begins with a main route table and a default ruleset in which that table is used. Typically you don't even notice this as it's created with the configuration of the standard network devices upon boot. Two rules will be applied for this main route table: 1) main 2) default The rules are such that the priority to these tables is so low almost any other rule will take priority over it. That's what makes amprnet routing for linux quite simple. The rule you want to make for amprnet is such that any inbound OR outbound routing sourced as 44-net uses it's own route table, with a priority higher than the main table rule. As long as the routes are in this matched table, the kernel will act as an amprnet router just fine even to entities such as xNOS, Xnet, etc. So if you want proper packet flow make sure all paths and rules match for the source you wish to route - in our case it's 44/8: A sample standard path would look like: commercial to commercial/nat inet/0 <----> linux-nat or com IP table main commercial to your ampr inet/0 <----> ucsd/bgp host ucsd/bgp host <---> linux 44-tunl0 via rule 1/table 1 <---> node/bbs/dxc ampr to ampr (tunnel only shown) 44/8-tunl0 <---> linux tunl0/rule 1/table 1 <---> node/bbs/dxc ampr to ampr to xNOS/Xnet (tunnel only shown) 44/8-tunl0 <---> linux tunl0/rule 1/table 1 <---> tun0/tap0-xNOS/Xnet This shows that the Xnet or xNOS tun/tap interfaces need to be included within the ruleset that matches table 1 or else it will become unroutable. Also you need to insure ip_forwarding is enabled, and your firewalling permits ip protocol 4 (ipencap), and ip protocol 93 (AX.25) A simple script which can do this for you is found at http://n1uro.ampr.org/linuxconf/dotun.html # --- dotun.sh --- #! /bin/bash # dotun.sh script written by N1URO # June, 2013 # enter in your information below, these are used for creating a # gateway and linking to the amprnet: AMPRIP='x.x.x.x' IPMASK='x.x.x.x' COMMIP='x.x.x.x' NOSIP='x.x.x.x' case "$1" in start) # Load your ipencap module in the kernel: modprobe ipip # Allow ip forwarding from amprnet to your ethernet interface echo "1" > /proc/sys/net/ipv4/ip_forward # load RIPv2 routing using the ampr-ripd daemon /usr/local/sbin/ampr-ripd -t 1 -a $COMMIP -p <password> -i tunl0 -v -s -r # Configure your ipencap tunnel interface - required for the amprnet ifconfig tunl0 $AMPRIP netmask $IPMASK up # Allow traceroutes to work on the amprnet: ip tunnel change tunl0 mode ipip ttl 64 tunl0 pmtudisc # If you run xNOS, configure a tun/tap interface: ifconfig tun0 $AMPRIP pointopoint $NOSIP up # configure your rointing accordingly: ip route add $NOSIP dev tun0 onlink table 1 src $AMPRIP ip route add default via 169.228.66.251 dev tunl0 src $AMPRIP onlink table 1 # configure policy routing so that frames from/to your 44-net IP # know how to route accordingly: ip rule add from 44/8 pref 1 table 1 ip rule add to 44/8 pref 1 table 1 # script is done, exit as a clean flush. exit 0 ;; stop) # Unload what we loaded above: ip rule del to 44/8 pref 1 table 1 ip rule del from 44/8 pref 1 table 1 ifconfig tunl0 down ifconfig tun0 down killall -TERM ampr-ripd modprobe -r ipip exit 0 ;; restart) dotun stop sleep 3 dotun start exit 0 ;; *) echo "Usage: dotun {start|stop|restart}" exit 0 ;; esac exit 0 --- EOF --- -- If Microsoft intended Windows to be for ham usage, they would have incorporated our protocols into their kernel. 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

10 years

Tunnel mesh is (mostly) down

by Rob Janssen

The tunnel mesh went down today at about 08:20 UTC. Most of our routes have disappeared, are no longer being advertised on RIP. The portal.ampr.org site is not responding anymore. It looks like the portal is no longer distributing correct information to the RIP server and so the RIP server sends incomplete broadcasts and the ampr-ripd deletes the routes. Is there some fallback scenario, e.g. loading a last correct list of routes by the RIP server to make the network come back up in the state it was just before the mishap? Rob

10 years

Re: [44net] Tunnel mesh is (mostly) down

by Rob Janssen

> Subject: > Re: [44net] Tunnel mesh is (mostly) down > From: > Eric Fort <eric.fort(a)gmail.com> > Date: > 01/03/2015 05:35 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > how about eliminating this issue perminantly from ever happening and > moving to voluntary peering between gateways. Know thy neighbor and > be responsible foryourpeers androutesseems to work really well for > everyone else yet amprnet still relies upon route distribution from a > single source. > > Eric > AF6EP It is still not clear to me what exactly happened, and how it was resolved, but what I saw here is that the number of tunnel routes decreased dramatically and this disconnected the stations on IPIP including myself. We already are BGP announced. That is not the problem. But as a properly setup gateway, we are both on BGP and the IPIP tunnel mesh, and the latter we configured using RIP (ampr-ripd). What apparently happened is that we received RIP broadcasts with only a very small subset of the active routes, and over time most routes got deleted. So we still had full connectivity to internet for net 44.137.0.0/16 and our statically connected subnets, but the tunnel routes inside the country and to the rest of the world mostly vanished. We don't really need those tunnels to everywhere over the world, but we run them to remain compatible with the rest of the system. It would be sufficient for us to have only tunnels to our local users, and have the remainder of the traffic routed over plain internet. However: - there is no way in the portal to specify that you want to use tunnel routes only for your own subnets - there are access lists in use at other stations that would block traffic going outside the tunnel system, because they want to limit traffic to only net-44, so we would get obscure routing problems So for now we will keep running a tunnel mesh system, and I hope that everyone else who prefers functionality over other reasons will do the same. (I fail to see how a single-point-of-failure solution can be a worse choice than a configuration that does not work *at all* even when everything is up and running) In the meantime, I hope some people can find some time to debug what was going on here. I have seen a similar problem in the RIP broadcasts before, a set of routes that appears and disappears at random. They appear in some RIP broadcast sets, then do not appear in some, then re-appear, etc. There must be a problem somewhere, but it is unclear if it is in the RIP server or in the code that delivers info to it. Maybe the problem of this morning is caused by the same bug, as it appears to have affected only a subset of all routes. Rob

10 years

Re: [44net] Tunnel mesh is (mostly) down

by Bryan Fields

On 1/3/15, 11:45 AM, Brian wrote: > On Sat, 2015-01-03 at 08:35 -0800, Eric Fort wrote: > >> > how about eliminating this issue perminantly from ever happening and >> > moving to voluntary peering between gateways. Know thy neighbor and >> > be responsible foryourpeers androutesseems to work really well for >> > everyone else yet amprnet still relies upon route distribution from a >> > single source. > Are you suggesting something such as a possible BGPv2 that all gateways > or designated regional gateways could perhaps tunnel broadcast between > themselves? This would be interesting and may help with other route > issues between those using RIPv2 <-> BGP amprnet sites. Why tunnel at the gateway level?, let the other gateways run BGP. Problem solved. How you get to the gateway could be IPIP, GRE, IPSEC, or you can run BGP yourself. Or even if you have a friendly peering location that lets you put a dish on the roof. Treating this like is some kinda special VPN really holds amprnet back. 73's W9CR -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

10 years

Re: [44net] Should I worry about this crud coming in via the tunnel?

by Rob Janssen

> Subject: > [44net] Should I worry about this crud coming in via the tunnel? > From: > Arno Verhoeven <pe1icq(a)vrhvn.nl> > Date: > 01/02/2015 04:11 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi, > > I have been monitoring traffic coming in via the tunnel and am a bit shocked how much bogus (?) traffic comes in from non-44 addresses. Yes, this is quite normal. Imagine how much comes in to the country gateway and gets dropped... The internet is full of people who only want to destroy it and there is not much that can be done about it. People use spoofed sender addresses (their provider should block that but many providers don't care), and others like to scan for all kinds of situations they can abuse, e.g. for DDOS. You need a good firewall. But maybe not what Tom suggests, because that ends your connectivity with the non-44 part of internet. Rob

10 years

Should I worry about this crud coming in via the tunnel?

by Arno Verhoeven

Hi, I have been monitoring traffic coming in via the tunnel and am a bit shocked how much bogus (?) traffic comes in from non-44 addresses. I have these rules in my firewall script: /usr/sbin/iptables -P INPUT DROP # Drop all traffic coming from Internet addresses via the tunnel to PE1ICQnet, except port 8000:8001 to raspberry pi (Dire Wolf). /usr/sbin/iptables -A INPUT -i ampr0 -s 44.0.0.0/8 -d 44.137.27.123 -p tdp -m multiport --dport 8000:8001 -j ACCEPT /usr/sbin/iptables -A INPUT -i ampr0 ! -s 44.0.0.0/8 -d 44.137.27.112/28 -j DROP When I monitor traffic on the tunnel interface with tcpdump -i ampr0 -vvn then I see a lot of traffic like this: 15:47:54.172385 IP (tos 0x0, ttl 51, id 60643, offset 0, flags [none], proto ICMP (1), length 98) 119.206.12.19 > 44.137.27.125: ICMP 119.206.12.19 udp port 53 unreachable, length 78 IP (tos 0x28, ttl 234, id 31771, offset 0, flags [DF], proto UDP (17), length 70) 44.137.27.125.29327 > 119.206.12.19.53: [udp sum ok] 31771+ A? ocektarhe.www.2015yf.com. (42) Remarkable, because at the moment I do not even have ip address 44.137.27.125 in use on the LAN. How do I need to interpret the above traffic dump? Is it because 44.137.27.125 is spoofed? Is it an attack using bogus domain resolving? (I see a lot of variants in the 2015yf.com domain) Basically, my question is, should I worry? ;-) 73 PE1ICQ // Arno

10 years

Attn. Brian ref IP address.

by trcarswell

I sent an email over a year ago...(it seems) to remove me from being an IP coord. I guess you missed it. I just got a email for a request...that was over a year old....the guy is pissed... as I would be....lol Pls remove me ...I hope someone can take my place... My wife got sick right after I became the the NC coord. Sorry. Trip - KT4WO

10 years

How to make traffic coming in on the tunnel interface get answered from that interface?

by Arno Verhoeven

Hi, I am looking for help setting up a conditional routing table. I have my tunnel up and running. I can reach other 44-net host. amrp-ripd is used to fill the routing table. So far so good, but I would like one of the web-sites (apache httpd vhost) to be reachable from both 44-net and non-44-net. If i check with tcpdump I see traffic coming in when I try to access the web-site (pi8zaa.ampr.org) via the Internet (I used my phone connected to t-mobile network). But it doesn't work because my server routes the replies to my ISP's Gw where they get source filtered. Basically I want/need traffic that comes in via the tunnel to get answered from the tunnel interface. I Googled for a solution. Found lots of variant of this http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.multiple-links.html but if I understand what is described there correctly, then that is not exactly what I need. Maybe I don't understand iproute2 and its routing table concept correctly. They way I understand it, those examples assume destination routing based on provider subnet, while in my case the destination is on the Internet, and in normal cases should be routed via my ISP except if it came in via the tunnel. Thanks for any help you can offer. 73 PE1ICQ // Arno

10 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net