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
At my request, we're cleaning out obsolete entries from the portal.
A reminder is sent after 3 and 6 months with no login.
A warning is sent after 9 months with no login.
A notice is sent after 12 months with no login.
After 15 months, the user, their network allocations, and any
gateways belonging to them are deleted.
At the current time, there are 3 gateways and 70 allocations to
be so deleted.
- Brian
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
> 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
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
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
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
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
> 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
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
