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
On Tue, Jun 16, 2015 at 4:51 PM, Steve L kb9mwr@gmail.com wrote:
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.
BTW, HamWAN used to be "in the RIP list". The entry was deleted by an AMPR administrator because he thought it wasn't working. We were using 44.24.221.1 as the gateway address. This address was advertised via BGP, accessible from the internet at large, and intentionally NOT advertised via RIP so that other gateways would not try to contact it inside an IPIP packet. This setup was spot-checked from a number of other AMPR systems and proven to work.
The only case where it didn't work is when administrators added a static 44/8 route to their gateway. Note that there is no 44/8 route in the RIP/encap list.
We're at a bit of a stalemate now. We'd have to reconfigure things a bit and utilize another IP address from our ISP to get it running on a non-44 gateway IP. The simpler solution (and one that serves all BGP networks) is to work towards solving the underlying BGP/IPIP interoperability problem that started this thread.
Tom KD7LXL
We were using 44.24.221.1 as the gateway address.
[...]
We'd have to reconfigure things a bit and utilize another IP address from our ISP to get it running on a non-44 gateway IP.
HamWAN had to switch to using a 44 ip on the IPIP endpoint when it became an independent autonomous system on the internet. In order to maintain shortest path and high availability, the IP needs to be on one of the prefixes that HamWAN announces directly (which is only 44-based prefixes). If another ISP's address was used instead, the traffic would be forced to travel though (and have a dependency on) that specific ISP's network.
The ideal workaround would be to get a /24 outside of 44/8 that HamWAN could announce from its ASN. That's not only prohibitively expensive, but a waste of resources and a silly thing to do just to route around the misconfigurations of others.
As a result, it was decided that it was better to maintain high availability for those who wanted to actively use the HamWAN network instead of making it less available, but generally reachable to all 44net users.
I can confirm this. HamWAN's setup, advertizing 44.24.241.0/24 via 44.24.221.1 worked flawless under the condition to drop that nonfunctional default 44/8 to ampr-gw route and NAT that traffic as any other internet traffic to the public IP. But since nobody wants to drop that route... Whatever.
Btw, not a single setup tutorial talks about setting that 44/8 via ampr-gw.
Marius
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Tom Hayward Sent: Wednesday, June 17, 2015 04:56 To: AMPRNet working group Subject: Re: [44net] AMPRNet Interoperability with BGP
BTW, HamWAN used to be "in the RIP list". The entry was deleted by an AMPR administrator because he thought it wasn't working. We were using 44.24.221.1 as the gateway address. This address was advertised via BGP, accessible from the internet at large, and intentionally NOT advertised via RIP so that other gateways would not try to contact it inside an IPIP packet. This setup was spot-checked from a number of other AMPR systems and proven to work.
The only case where it didn't work is when administrators added a static 44/8 route to their gateway. Note that there is no 44/8 route in the RIP/encap list.
We're at a bit of a stalemate now. We'd have to reconfigure things a bit and utilize another IP address from our ISP to get it running on a non-44 gateway IP. The simpler solution (and one that serves all BGP networks) is to work towards solving the underlying BGP/IPIP interoperability problem that started this thread.
Tom KD7LXL _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Can't you put that entry back if that worked Tom?
Bob VE3TOK
On 15-06-16 09:55 PM, Tom Hayward wrote:
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jun 16, 2015 at 4:51 PM, Steve L kb9mwr@gmail.com wrote:
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.
BTW, HamWAN used to be "in the RIP list". The entry was deleted by an AMPR administrator because he thought it wasn't working. We were using 44.24.221.1 as the gateway address. This address was advertised via BGP, accessible from the internet at large, and intentionally NOT advertised via RIP so that other gateways would not try to contact it inside an IPIP packet. This setup was spot-checked from a number of other AMPR systems and proven to work.
The only case where it didn't work is when administrators added a static 44/8 route to their gateway. Note that there is no 44/8 route in the RIP/encap list.
We're at a bit of a stalemate now. We'd have to reconfigure things a bit and utilize another IP address from our ISP to get it running on a non-44 gateway IP. The simpler solution (and one that serves all BGP networks) is to work towards solving the underlying BGP/IPIP interoperability problem that started this thread.
Tom KD7LXL _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On Tue, Jun 16, 2015 at 10:42 PM, Boudewijn (Bob) Tenty bobtenty@gmail.com wrote:
(Please trim inclusions from previous messages) _______________________________________________ Can't you put that entry back if that worked Tom?
Good question! No, a change to the portal around the same time prohibits adding 44.xx.xx.xx addresses as gateways. I believe there was some noise on this list about it at the time.
Tom KD7LXL
On Tue, Jun 16, 2015 at 10:47:31PM -0700, Tom Hayward wrote:
Good question! No, a change to the portal around the same time prohibits adding 44.xx.xx.xx addresses as gateways. I believe there was some noise on this list about it at the time.
That change was made because 1) it was reported that 44.x gateway addresses didn't work 2) it was reported that 44.x gateway addresses caused problems 3) people were entering 44.x gateway addresses for their IPIP tunnels instead of the proper commercial IP address of the endpoint.
There were, in fact, several of case (3) which of course did NOT work.
If in fact the HAMWAN entry is needed, I can ask Chris to undo the restriction and then we'll just have to be extra vigilent about checking new gateway entries. Mistakes will happen and have to be corrected. - Brian
On Tue, Jun 16, 2015 at 11:01 PM, Brian Kantor Brian@ucsd.edu wrote:
If in fact the HAMWAN entry is needed, I can ask Chris to undo the restriction and then we'll just have to be extra vigilent about checking new gateway entries. Mistakes will happen and have to be corrected.
A more robust check would be to ping whatever gateway IP is entered. If a reply is received, allow it, if not, report the error to the user ("no route to host", etc.). Also check that the IP is not within its own subnet. I'd be impressed if someone succeeded in passing the first test and not the second, but not surprised.
(If you're one of those who blocks ICMP, you're intentionally breaking things and you can deal with your own mess.)
Tom KD7LXL
For those using ampr-ripd, the latest version (1.13) does NOT set a route if the gateway falls inside its own 44net subnet, actually preventing those situations. The condition for it to work is, of course, NOT to have a default 44/8 route via ampr-gw, so that unknown 44net destination are NAT-ed to the gateway's public IP.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Tom Hayward Sent: Wednesday, June 17, 2015 09:46 To: AMPRNet working group Subject: Re: [44net] AMPRNet Interoperability with BGP
(Please trim inclusions from previous messages) _______________________________________________ On Tue, Jun 16, 2015 at 11:01 PM, Brian Kantor Brian@ucsd.edu wrote:
If in fact the HAMWAN entry is needed, I can ask Chris to undo the restriction and then we'll just have to be extra vigilent about checking new gateway entries. Mistakes will happen and have to be corrected.
A more robust check would be to ping whatever gateway IP is entered. If a reply is received, allow it, if not, report the error to the user ("no route to host", etc.). Also check that the IP is not within its own subnet. I'd be impressed if someone succeeded in passing the first test and not the second, but not surprised.
(If you're one of those who blocks ICMP, you're intentionally breaking things and you can deal with your own mess.)
Tom KD7LXL _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Since this is a recurring question, what NAT has to do with this...
Scenario: unknown 44net destination address, possible BGP announced:
- To operate a tunnel, one needs a public IP as an endpoint (if not BGP routed). - All outgoing 44net traffic will usually originate from the local 44.x.x.x address and go via IPIP tunnels to their partners - Replies will return via the same tunnel - If the destination 44net IP has no known route, it will go the default route, still being originated from a 44.x.x.x address. - If the ISP has source filtering it will end here - If the ISP accepts source 44.x.x.x it will reach the endpoind (let's say a BGP routed IP) via regular internet - The reply will be routed back to ampr-gw (since that is the route for all 44/8 traffic if not specified by a tighter BGP route). - Since ampr-gw does not route data from 44net addresses from the internet to 44net addresses on tunnels, it will die here. So, in these conditions, communications are not possible.
And here comes NAT into play: - unknown 44net destinations will be src-nated from the originating 44.x.x.x to the GW's public IP - it will be routed from this public IP to the destination 44net system - replies will be routed back to the originating system - replies will be dst-nated utomatically and forwarded back to the originator.
And voila, it works flawless.
Marius, YO2LOJ
On 17.06.2015 17:06, Marius Petrescu wrote:
For those using ampr-ripd, the latest version (1.13) does NOT set a route if the gateway falls inside its own 44net subnet, actually preventing those situations. The condition for it to work is, of course, NOT to have a default 44/8 route via ampr-gw, so that unknown 44net destination are NAT-ed to the gateway's public IP.
it would be nice if you can add the following feature (optional) to the ampr-ripd: * Parse the received routing information by RIP for IPIP-Gateways hosted on an IP-address within 44/8 (e.g. 44.24.221.1 for HamWAN). * Load the Defaultgateway of the local system from IP-Table "Main" into Memory (e.g. 141.75.244.1 at my DB0FHN box) * Set a hostroute to each individual parsed IPIP-Gateway using the Defaultgateway in a routing table chosen by the user (e.g. 44.24.221.1 via 141.75.244.1 in table "Main" at DB0FHN)
I did this manually to test the interconnection with the HamWAN-Community. Worked like a charm :)
73, Jann
Hi Jann,
This is a good idea. It will go in the next version, together with default raw sockets (I understood that multicast doesn't work as it should on new kernels) and tweaks to support a pid file.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Jann Traschewski Sent: Wednesday, June 17, 2015 21:20 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] AMPRNet Interoperability with BGP
(Please trim inclusions from previous messages) _______________________________________________ On 17.06.2015 17:06, Marius Petrescu wrote:
For those using ampr-ripd, the latest version (1.13) does NOT set a route
if
the gateway falls inside its own 44net subnet, actually preventing those situations. The condition for it to work is, of course, NOT to have a default 44/8
route
via ampr-gw, so that unknown 44net destination are NAT-ed to the gateway's public IP.
it would be nice if you can add the following feature (optional) to the ampr-ripd: * Parse the received routing information by RIP for IPIP-Gateways hosted on an IP-address within 44/8 (e.g. 44.24.221.1 for HamWAN). * Load the Defaultgateway of the local system from IP-Table "Main" into Memory (e.g. 141.75.244.1 at my DB0FHN box) * Set a hostroute to each individual parsed IPIP-Gateway using the Defaultgateway in a routing table chosen by the user (e.g. 44.24.221.1 via 141.75.244.1 in table "Main" at DB0FHN)
I did this manually to test the interconnection with the HamWAN-Community. Worked like a charm :)
73, Jann
-- Jann Traschewski, Faber-Castell-Str. 9, D-90522 Oberasbach, Germany Tel.: +49-911-99946898, Mobile: +49-170-1045937, E-Mail: jann@gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn _________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
On 17 Jun 2015, at 07:01, Brian Kantor Brian@ucsd.edu wrote:
If in fact the HAMWAN entry is needed, I can ask Chris to undo the restriction and then we'll just have to be extra vigilent about checking new gateway entries.
I could always put a warning up but still allow the configuration, rather than simply not allowing it at all?
Chris
On Tue, Jun 16, 2015 at 11:01 PM, Brian Kantor Brian@ucsd.edu wrote:
There were, in fact, several of case (3) which of course did NOT work.
If in fact the HAMWAN entry is needed, I can ask Chris to undo the restriction and then we'll just have to be extra vigilent about checking new gateway entries. Mistakes will happen and have to be corrected.
The difference is that 44 addresses can be valid gateway destinations as long as that IP doesn't exist in any of the subnets that have IPIP tunnels configured.
There's a good chance that the mistakes others made were specifying a 44-based gateway address that existed within the same subnet they're trying to tunnel. Assuming Chris already has an easy way to do IP math in the portal, then he should still be able to restrict that mistake. If you wanted to be thorough, you could also reject any gateway IP that happens to match the subnet of any tunnel.
Has anyone had any luck with finding an ISP that will host our tunnels? - Brian
Hi,
I have got a message that my account has been de-activated because haven't used for six months. Surprised this happens, once you setup your subnets/gateways don't really need to login that often?
Was just wondering how I re-activate my account now, do I re-register to see my subnet allocation etc?
Regards, Bob, m1duo
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
On 6/18/15 5:31 PM, Brian Kantor wrote:
Has anyone had any luck with finding an ISP that will host our tunnels?
Brian,
I've asked for traffic details amongst others info on the amprgw and to date not seen anything. All I'm looking for is the 95th percentile of traffic into and out of amprgw to the internet. If this is indeed on a 10g connection like it was stated, this may be larger than I though it was.
I'm sure I one company that will do it for us, but I'm not going to formally approach my contacts until I have details. Basically we're just looking for transit for a non-profit org at this point.
This would be for the anycast solution, so we'd need to have a common AS as if not the BGP protocol would use the lower AS in all cases of it being equal. Are we planing to have the prefixes we announce based on our IGP (ampr-ripd/encap), or will they be static with new prefixes manually configured when an IP is assigned out of that block?
From an operational standpoint I can see us needing to use radb/prefix
validation to update our upstream filters unless we LOA the entire /8.\
Will we have this router running on Linux, and if so what sort of box/cpu/memory/IO do we need? Would a VM work? I have rack space for at least a few RU.
It was I who deleted it because I was told it was causing problems. If that was wrong and it was working and not causing problems then I can put it back or Tom can. - Brian
On Wed, Jun 17, 2015 at 01:42:00AM -0400, Boudewijn (Bob) Tenty wrote:
Can't you put that entry back if that worked Tom? Bob VE3TOK
On 15-06-16 09:55 PM, Tom Hayward wrote:
BTW, HamWAN used to be "in the RIP list". The entry was deleted by an AMPR administrator because he thought it wasn't working. We were using 44.24.221.1 as the gateway address. This address was advertised via BGP, accessible from the internet at large, and intentionally NOT advertised via RIP so that other gateways would not try to contact it inside an IPIP packet. This setup was spot-checked from a number of other AMPR systems and proven to work.
The only case where it didn't work is when administrators added a static 44/8 route to their gateway. Note that there is no 44/8 route in the RIP/encap list.
We're at a bit of a stalemate now. We'd have to reconfigure things a bit and utilize another IP address from our ISP to get it running on a non-44 gateway IP. The simpler solution (and one that serves all BGP networks) is to work towards solving the underlying BGP/IPIP interoperability problem that started this thread.
Steve,
Defaulting unknown 44net traffic to UCSD does not work since ampr-gw does not forward traffic betweem 44 endpoints. That default route to UCSD is an ancient "fossil" from the munge script and is wrong. Just drop that route, treat BGP announced networks as an regular internet connection via your public IP and it should work.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Steve L Sent: Wednesday, June 17, 2015 02:51 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] AMPRNet Interoperability with BGP
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?
-
Bob Easthope -
Boudewijn (Bob) Tenty -
Brian Kantor -
Bryan Fields -
Chris -
Cory (NQ1E) -
Jann Traschewski -
Marius Petrescu -
Steve L -
Tom Hayward