44net June 2015

44net@mailman.ampr.org

41 participants
47 discussions

Re: [44net] Model gateway system
by Steve L 19 Jun '15

19 Jun '15

IPIP gateways should not use amprgw default route. Ex: ip route add default dev tunl0 via 169.228.66.251 onlink .... IPIP gateways and the Wireless LAN's behind them will then be able to reach the BGP'd portions. I think that only leaves this scenario: BPG gateways and the wireless LAN's behind them will not be able to reach IPIP gateways and the LAN's behind them, as UCSD can't get a reply back to them. >From what I gathered Brian is seeking to hand off IPIP gateway destined traffic an intermediary ISP to fix this. Again from what I understand. The problem stems from a routing loop in the architecture at UCSD, when traffic leaves amprgw destine for a BGP'd chunk of the network. Others can correct me if I am wrong. Steve, KB9MWR ---- Quote ---- So is the architectural debate over, or are people just tired of arguing? Frankly, there's been so much back and forth that I don't know what's expected any more. As I understand it, some nodes are on the IPIP mesh, some not. Some are reachable through amprgw, some not. What a mess. If the debate is over and there is consensus on a standard gateway architecture, then someone needs to publish it. I'm thinking the design should include a diagram of how to address the interfaces (which tunnels need AMPR addresses, which don't), where NATing occurs, what the ampr routing table should look like, what the ip rules should look like, etc. Otherwise, I guess it's up to each individual person to parse through the last 100 or so emails to figure out what they're going to do. Maybe I'll find time to do that . Someday. And folks wonder why there's not more participation . Michael N6MEF

1 0

Re: [44net] AMPRNet Interoperability with BGP
by Rob Janssen 19 Jun '15

19 Jun '15

> Subject: > Re: [44net] AMPRNet Interoperability with BGP > From: > "Cory (NQ1E)" <cory(a)nq1e.hm> > Date: > 06/18/2015 11:59 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Bingo!!! There's the use-case I was missing in my head: > YourGWHost(Forcing44SourceIP) -> OtherIPIPLANs That is right! Note that this config was constructed for an all-in-one system that functions as the IPIP tunnel host, as a host for running services on AMPRnet (potentially reachable from all internet addresses), as a host to make outgoing connections to other amprnet systems, and as a general work machine for the owner (to browse, mail etc). The same browser session would automatically use the tunnels to reach other systems on AMPRnet, but it would use the direct path via the ISP for google and youtube. > The correct way to do that is obviously to tell the program you're using > that you want to bind to the specific 44 network interface. Forcing it to > happen for all traffic with a 44/8 destination is an easy workaround to > make that work, but as you can see it can have unintended consequences. Unfortunately this is not really practical. Sure you can set the source address on many common commandline utilities (like ping, telnet, traceroute, ftp) but not on many other networking programs like web browsers. Even an amateur radio oriented program like the Echolink client I use (QTEL) cannot set the source address. I made a request for enhancement for it, but that kind of thing had better be handled in a universal way. > > My recommended solution for those who want to be able to connect to as many > 44 nets as possible is: > Remove the 'to 44/8' rule and if you want to talk to a 44 host from a 44 > IP, use a host behind your gateway, not the gateway host itself. I have more or less done that already, as I now have a separate router between the host and the network, but even that does not solve this problem when that host again has to be on both networks. My main PC now has 2 addresses (each on a VLAN) to talk to the outside world, one is used (via NAT) to talk to internet, the other is 44.137.41.97 and is used when talking amprnet. But of course both can in fact communicate to any address, the decision which one to use is always a bit tricky. So my rule still is that "all traffic from my own subnet to anywhere, and all traffic from my hist to 44.0.0.0/8" is using the amprnet and goes out from 44.137.41.97 and without NAT, all other traffic is using the ISP internet and is NATted by the router. And again I have those "ip rules" in my system to achieve that: 0: from all lookup local 1: from all to 44.137.41.96/28 lookup main 44: from 44.137.41.96/28 lookup amprnet 44: from all to 44.0.0.0/8 lookup amprnet 32766: from all lookup main 32767: from all lookup default I am open to better solutions, as long as they are not "make sure that every program you use can bind an explicit local address". Of course now that I am behind a router the immediate problem of sending tunnel traffic to net-44 endpoints is no longer there, also because I am no longer directly on IPIP but only via our gateway, but still this source address selection issue remains. It may be that a suggestion I received from Jann can fully remedy the problem at least on a dedicated router/gateway. His approach is to make an unconditional rule that first sends the outgoing traffic through a table with only the IPIP tunnels. When that matches, the system will of course set the 44.x.x.x source address. Then, a rule follows that matches on "from 44.137.41.96/28" and refers to a table with only a default route pointing to the gateway (UCSD or another) that will forward the outside-44 traffic back to internet. Then finally everything else is looked up in the main routing table which has the default route going out via the ISP. I have not tested yet how well that works in practice. As mentioned, I no longer have the setup running that this config was originally created for. But it looks good. Rob

1 0

Re: [44net] AMPRNet Interoperability with BGP
by Steve L 19 Jun '15

19 Jun '15

I am in the same boat as Bob. Home connection with limited inbound speed. So the DNS filtering is nice. It also lets my wireless LAN end users easily decide if they want inbound internet connectivity or not (when that portion of the portal gets done) without having to get a hold of me to set a firewall rule for them. I also like the idea of other VPN technologies being an option. One being stateful for those in uncool firewall situations . Sometime back I though maybe one day there would be multiple regional portals (connected with BGP and all running the open portal code/web interface) where end gateways could connect using a couple different vpn technologies. I understand the problem at hand with the fragmentation between the BGP vs IPIP segments. Or I think I do, from my end I know hamwan is BGP connected and have problems reaching it: I use the AMPR RIPv2 daemon 1.11by Marius, YO2LOJ And it appears if the 44 address you are trying to reach isn't in the RIP list, like hamwan is, it defaults to route it to UCSD. That doesn't work for me, as you will see below. But when I override that, and tell it to go out eth0 like all non 44net traffic it then works. Or is there something special I can do in my configs to fix this? root@44.92.21.1:~# ip route show table 44 | grep 44.24 44.24.0.0/20 via 66.114.139.158 dev tunl0 proto 44 onlink window 840 44.24.10.0/24 via 192.231.186.20 dev tunl0 proto 44 onlink window 840 44.24.192.0/24 via 38.104.126.22 dev tunl0 proto 44 onlink window 840 44.24.194.0/24 via 216.161.250.189 dev tunl0 proto 44 onlink window 840 44.24.196.0/24 via 24.113.42.14 dev tunl0 proto 44 onlink window 840 root@44.92.21.35:~# ping hamwan.org PING hamwan.org (44.24.241.98) 56(84) bytes of data. >From ebu-3b-720-vl441-cse-sysnet-gw-222-1.ucsd.edu (137.110.222.1) icmp_seq=2 Time to live exceeded >From ebu-3b-720-vl441-cse-sysnet-gw-222-1.ucsd.edu (137.110.222.1) icmp_seq=3 Time to live exceeded ^C --- hamwan.org ping statistics --- 6 packets transmitted, 0 received, +2 errors, 100% packet loss, time 5002ms root@44.92.21.35:~# ping hambook.de.ampr.org PING hambook.de.ampr.org (44.225.56.138) 56(84) bytes of data. 64 bytes from hambook.db0sda.as64634.de.ampr.org (44.225.56.138): icmp_req=1 ttl=55 time=189 ms 64 bytes from hambook.db0sda.as64634.de.ampr.org (44.225.56.138): icmp_req=2 ttl=55 time=175 ms ^C --- hambook.de.ampr.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 175.383/182.595/189.808/7.225 ms ---- Quote ---- I appreciate especially the filtering out of 44 addresses who are not in the dns by ucsd. I hate to loose that when it goes to another ISP. I remember well the days when that extra garbage was not filtered out and I will hate it when that is lost. My gateway is presently just at a home connection with a static ip. I object when that stuff is moved and no filtering will be in place whatsoever. With other words: UCSD is working fine. So why is it that those BGP subnets have no mandatory IPIP entries in the list also? They don't have to route back over IPIP, only need to receive IPIP. Easy solution, nothing drastic, KISS, and done in no time.. Bob VE3TOK

10 18

(no subject)
by Steve L 19 Jun '15

19 Jun '15

That occurred to me after I sent my last message. Part of my startup script included this default route: ip rule add to 44.0.0.0/8 table 44 priority 44 So I commented that out, and then could reach hamwan.org, but wasn't able to reach hambook.de.ampr.org and other hosts. I also upgraded to ampr-ripd 1.13 If someone can reach both from their IPIP gateway I'd be most grateful if you'd share your startup script with me. Here is my script: http://www.qsl.net/kb9mwr/wapr/tcpip/startampr ---- Quote ---- NO GATEWAY SHOULD EVER HAVE A DEFAULT 44/8 ROUTE TO UCSD BECAUSE IT DOESN'T WORK AND IS POINTLESS. Marius, YO2LOJ

4 10

Re; (no subject)
by Steve L 18 Jun '15

18 Jun '15

Managed to fix this on my own. Had to add a masquerad rule When I removed: ip route add default dev tunl0 via 169.228.66.251 onlink table 44 I had to add this to allow eth1 (my wireless LAN) to get anywhere: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Thanks again ---------- Forwarded message ---------- From: Steve L <kb9mwr(a)gmail.com> Date: Thu, Jun 18, 2015 at 7:36 PM Subject: Re; (no subject) To: "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> Marius, I was to hasty in saying removing this line fixed everything. I forgot to test from a remote host on my wireless LAN, I got a message from one of my LAN users that this broke things. Although I am at a loss as to why. It broke all remote connectivity. Works from the gateway itself, but all remote traceroutes stop when they reach my gateway, Steve ---- Quote ---- The issue in your setup is 'ip route add default dev tunl0 via 169.228.66.251 onlink table 44' which should go away if ypu want to reach BGP announced networks. Marius

1 0

Re; (no subject)
by Steve L 18 Jun '15

18 Jun '15

Marius, I was to hasty in saying removing this line fixed everything. I forgot to test from a remote host on my wireless LAN, I got a message from one of my LAN users that this broke things. Although I am at a loss as to why. It broke all remote connectivity. Works from the gateway itself, but all remote traceroutes stop when they reach my gateway, Steve ---- Quote ---- The issue in your setup is 'ip route add default dev tunl0 via 169.228.66.251 onlink table 44' which should go away if ypu want to reach BGP announced networks. Marius

1 0

Re: [44net] AMPRNet Interoperability with BGP
by Rob Janssen 18 Jun '15

18 Jun '15

> Subject: > Re: [44net] AMPRNet Interoperability with BGP > From: > "Cory (NQ1E)" <cory(a)nq1e.hm> > Date: > 06/17/2015 11:02 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Wed, Jun 17, 2015 at 1:17 PM, Marius Petrescu<marius(a)yo2loj.ro> wrote: > >> > >> >NO GATEWAY SHOULD EVER HAVE A DEFAULT 44/8 ROUTE TO UCSD BECAUSE IT DOESN'T >> >WORK AND IS POINTLESS. >> > > Whoa... no need to yell:) Indeed... I was never talking about a 44/8 route, it is a 0.0.0.0/0 route. > > I'm finally taking a look at the wiki doc he referred to: > http://wiki.ampr.org/index.php/Ubuntu_Linux_Gateway_Example > > It does mention creating a new routing table with the default route (0/0, > not 44/8) pointed at the UCSD gateway. This makes sense as you may want to > generate packets with a 44 source and a non-44 destination on the > internet. The gateway will forward those correctly. That is why it is there! it is required for IPIP gateways on a source address filtered connection. > it would also do it > for non-tunneled 44 nets if we didn't have the upstream routing issue at > UCSD that started this thread. > > The problem seems to be with the traffic that gets flagged to use the > alternate routing table: > > ## Configure Policy Based routing > # Packets to 44/8 network use routing table 44 > ip rule add to 44.0.0.0/8 table 44 priority 44 > > # Packets from our 44 subnet use table 44 (put your AMPRNet Subnet here) > ip rule add from 44.128.10.0/24 table 44 priority 45 > > The second ip rule makes sense to me. You want all packets sourced from > your 44 net to use the alternate routing table so they can egress through > UCSD and keep their source IP without NAT. However, the first ip rule (all > packets with 44 destinations) seems unneeded and troublesome. Packets that > aren't sourced from your own 44 net, but happen to have a 44 destinations > shouldn't be forced to use your tunnel. The reason that it is there: when you make an outgoing connect from a socket that is not bound to a specific address, the kernel will decide on the local address based on the route. When you do nothing, traffic to 44.0.0.0/8 will be routed to your normal default route to your ISP, and the source address will be your public IP. The traffic will be routed "outside" via UCSD or a BGP-announcing gateway. Of course you want to make such connections via a tunnel, so there is the first rule that will match the 44.0.0.0/8 destinations, select table 44, and find the tunnel routes there. Then, your 44.x.x.x source address will be selected. Rob

2 1

Re: [44net] portal purge
by clark edwards 18 Jun '15

18 Jun '15

Kml £ On Jun 18, 2015 1:25 PM, Brian Kantor <Brian(a)ucsd.edu> wrote: (Please trim inclusions from previous messages) _______________________________________________ On Thu, Jun 18, 2015 at 10:14:00AM -0700, Tom Hayward wrote: > Which ICANN requirement is this? I'm only familiar with WDRP, which is > a requirement for registrars to maintain ICANN accreditation. I don't > think AMPR is a registrar or ICANN accredited, so I must be totally > out of context. ARIN requires that I verify my contact info once a year; they say it's a requirement placed on them by ICANN. > Also, how do I connect to the AMPR WHOIS server to read this information? The whois server is under development and not yet deployed. I'm not up on the progress of that project. The intent was to have it run on the portal, where the registration database is operated so that it can have access to the necessary data. - Brian _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] (no subject)
by Steve L 17 Jun '15

17 Jun '15

Marius, Thanks for the explanation, it helped clear up quite a few things I wasn't clear on. And yes after I removed the line: ip route add default dev tunl0 via 169.228.66.251 onlink table 44 I can reach hamwan.org. hambook.de.ampr.org and am able to accept connections from general internet IP's. So this was the secret for me. Thanks Steve

1 0

Re: [44net] (no subject)
by Steve L 17 Jun '15

17 Jun '15

Yes root@ampr-gw:~# ip route show table 44 | grep 44.224 44.224.0.0/15 via 141.75.245.225 dev tunl0 proto 44 onlink window 840

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net June 2015