Anyone know the status of G4APL's node? I haven't seen it on for a
couple weeks now.
--
A computer once beat me at chess, but it was no match against
me in kick-boxing - Emo Phillips
73 de Brian Rogers - N1URO
email: (see above)
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
http://uronode.sourceforge.nethttp://axmail.sourceforge.net
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
Howdy all,
I’ve got a question about DNS and rDNS - I submitted a request to the portal to have DNS addresses added for my subnet a couple of months back and have not received any feedback regarding the status and was just wondering if there was something else I needed to do to move things along.
I’ve also noticed recently that there appears to be an incorrect rDNS record associated with the subnet and was wondering if that was just old info or if some DNS records had been added incorrectly. The subnet in question is 44.135.193.0/24 and the DNS record I found is ve8jl.ampr.org <http://ve8jl.ampr.org/>
Cheers,
Chris
VE7ALB & VA7OL
> Subject:
> [44net] Scripts
> From:
> Steve L <kb9mwr(a)gmail.com>
> Date:
> 08/05/2015 03:57 AM
>
> To:
> "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu>
>
> So that got me thinking maybe this same concept could be applied to
> the BGP'd subnets, forcing them to use masquerading. But rather a
> rule on the source address, we set it for destinations.
>
> Here is what I came up with. (Untested)
>
> http://www.qsl.net/kb9mwr/wapr/tcpip/startampr-bgp
>
> Basically I download a list of all the BGP'd subnets, and set a flag
> like before and force them out as masqueraded.
>
I think it is preferable to IPIP encapsulate the traffic to a place where it can be sent with its
original source address, over masquerading it to the public IP. When you have a default
route in table 44 pointing to AMPRGW it will work OK without requiring exceptions for BGP
routed subnets and it will also work to public internet. When you want to route only to AMPRnet
you can use a 44.0.0.0/8 route to AMPRGW instead.
(instead of AMPRGW, you can also use a more specific gateway that is on a not source-address
filtered host and is closer to you, when they want to provide that service. e.g. for 44.137.0.0/16
hosts our gateway can be used for that)
Unfortunately this still breaks in case an IPIP gateway is using an endpoint address within
44.0.0.0/8
Rob
> Subject:
> Re: [44net] New Linux Boot Scripts for Testing
> From:
> lleachii(a)aol.com
> Date:
> 08/04/2015 11:17 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> Nigel,
>
> - I should be a properly configure IPIP gateway.
>
> Can you reach me?
>
> 44.60.44.0/24
> 44.60.44.1 - router
> 44.60.44.3 - DNS
> 44.60.44.10 - HTTP
At the time you wrote that it was not yet working, but now I can reach you from here!
So it appears you have fixed it. Good!
Rob
> Subject:
> Re: [44net] New Linux Boot Scripts for Testing
> From:
> Tom Hayward <esarfl(a)gmail.com>
> Date:
> 08/04/2015 09:34 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On Tue, Aug 4, 2015 at 12:19 PM, Rob Janssen<pe1chl(a)amsat.org> wrote:
>>> >>The hamwan.org remain unreachable
>> >
>> >It goes via radio to our 44.137.0.0/16 gateway and from there over plain
>> >internet (it is BGP routed).
>> >You may have trouble trying to access this with some of the typical tunnel
>> >setups because they provide no tunnel endpoint.
> Indeed, this is what you should be seeing for hamwan.org at the
> moment. Since our gateway was deleted from the portal we have not gone
> in and rebuilt things.
>
> We are properly BGP routed, so any machine on the internet (and not
> behind amprgw) should be able to access it.
The system where I tested this (our gateway system) can send internet traffic from 44.137.0.0/16
without source address filtering issues. However, the typical ISP line here is source address filtered,
so I cannot send traffic from a 44.137.x.x address directly from my home line to you on your BGP routed
network.
Traffic to other IPIP gateways is encapsulated in an outer header with my public IP and the public IP
of the tunnel endpoint I route to, so my ISP does not filter such traffic. However, when I want to send
from my 44.137.x.x address to any other system, either outside 44.x.x.x or in the 44.x.x.x network but
not routed via IPIP, I need to encapsulate it and send it to some system that can send that traffic
without source address filter.
Before we had our own gateway, it was usual to send this traffic to AMPRGW. But that did not work
for this case. That appears to have been resolved now. Our own gateway could already do this.
However, there is still the issue of "what to do with traffic" (encapsulate it or not, what source address
to use) sent to 44.x.x.x.
It was difficult to do it right when the tunnel endpoint falls within the 44.x.x.x network.
This was the actual reason why your tunnel endpoint was removed after discussion here.
I think when you bring back the tunnel endpoint (which of course is preferable), you should try to
get an IP outside 44.x.x.x for the tunnel endpoint, as most users have done. That reduces the risk
of problems. I do not believe in setting up exception lists for ranges that are BGP routed or are
used as tunnel endpoints but are within 44.x.x.x, that is just making everything complicated and makes
it break down when people are not always on the watch for changes in the network. The automatic
handling provided by (ampr-)ripd is much preferred over such manually maintained configuration.
Rob
> Subject:
> Re: [44net] New Linux Boot Scripts for Testing
> From:
> Gustavo Ponza <g.ponza(a)tin.it>
> Date:
> 08/05/2015 01:52 AM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
>
> The following is the routing situation seen from here; the 44.137 IPIP routes
> result correctly addressed toward the commercial GW IP addresses according
> to the above statements.
> The routes are collected from the gw.ampr.org and so only that setup there.
> Now, as per my understanding, all the whole 44.137 GWs should be setup
> on the same way of that (above) pingable GWs to be reached via tunl0.
>
> root@ir0rm-7:/# route -n|grep 44.137
> 44.137.2.138 84.106.127.22 255.255.255.255 UGH 0 0 0 tunl0
> 44.137.24.1 88.159.160.228 255.255.255.255 UGH 0 0 0 tunl0
> 44.137.24.5 89.18.172.156 255.255.255.255 UGH 0 0 0 tunl0
> 44.137.25.62 88.159.83.58 255.255.255.255 UGH 0 0 0 tunl0
> 44.137.32.50 84.83.147.249 255.255.255.255 UGH 0 0 0 tunl0
> 44.137.0.49 77.175.246.216 255.255.255.255 UGH 0 0 0 tunl0
> 44.137.40.2 89.18.172.156 255.255.255.255 UGH 0 0 0 tunl0
> 44.137.40.1 89.18.172.156 255.255.255.255 UGH 0 0 0 tunl0
> 44.137.40.10 89.18.172.155 255.255.255.255 UGH 0 0 0 tunl0
> 44.137.40.20 89.18.172.155 255.255.255.255 UGH 0 0 0 tunl0
> 44.137.1.160 46.21.164.170 255.255.255.240 UG 0 0 0 tunl0
> 44.137.1.208 195.240.133.194 255.255.255.240 UG 0 0 0 tunl0
> 44.137.33.16 84.83.147.249 255.255.255.240 UG 0 0 0 tunl0
> 44.137.33.32 62.45.244.128 255.255.255.240 UG 0 0 0 tunl0
> 44.137.51.64 130.255.72.61 255.255.255.240 UG 0 0 0 tunl0
> 44.137.37.160 82.161.55.187 255.255.255.240 UG 0 0 0 tunl0
> 44.137.37.176 82.139.110.195 255.255.255.240 UG 0 0 0 tunl0
> 44.137.37.192 31.151.69.80 255.255.255.240 UG 0 0 0 tunl0
> 44.137.41.128 83.160.55.17 255.255.255.240 UG 0 0 0 tunl0
> 44.137.27.112 88.159.160.228 255.255.255.240 UG 0 0 0 tunl0
> 44.137.31.32 82.176.45.37 255.255.255.240 UG 0 0 0 tunl0
> 44.137.0.0 213.222.29.194 255.255.0.0 UG 0 0 0 tunl0
>
>> For example, 44.137.41.97 should be pingable via that endpoint. When doing a traceroute,
>> you should see a couple more hops after the tunnel that are radio hops.
>
> That IP address doesn't appear on the above list but it is positively
> pingable
That is correct, Gus. The above list except the last line are routes to individuals that are directly on
the IPIP tunnel mesh. The last line is a route for everyone in NL that is not on the IPIP mesh, via a
gateway system that is both on IPIP and BGP and also routes to radio networks inside the country.
The address 44.137.41.97 is on such a radio network, so you get the route to 44.137.0.0 (because
it does not appear in the list of more specific entries) and from there via 2 more hops to my station.
I think there is no problem with this routing, but the fact that I cannot reach some stations even though
all routing is correct is caused by problems with home routers. Some people are behind NAT routers
providerd by their ISP, and they have difficulty forwarding the IPIP packets we are using. Some of
those routers incorrectly apply stateful firewall rules to (part of) the IPIP incoming traffic. When such
a user sends traffic outward, the router puts the temporary rule in place that allows incoming traffic
from the tunnel endpoint they route to, and the link works both ways. But when the first traffic is
from outside, the IPIP packet never makes it through the router and there is no reply.
I have been trying to help a local user who has this problem, and it looks like IPIP is just not possible
with them. At least not when the user wants to accept incoming connections.
The strange thing is that it appears to work from some systems, and not from others. I have not yet
found a clue why this is. Others?
Rob
Well I think maybe Brian Kantor has simplified the IPIP <-> BGP
connectivity dilemma for everyone.
I was able to ping hamwan.org earlier. It's not working right now, so
I'll assume there are some bugs still being worked out.
So really what I am about to share may no longer be needed, but I'll
share it for informational purposes.
Recap:
Last month I shared an idea for someone where I had cooked up a way
for some hosts on his RF LAN to be reachable via UCSD, and the rest
masq'd.
http://www.qsl.net/kb9mwr/wapr/tcpip/startampr-n3fe
To which PE1CHL replied he does something similar, but he use the mark
to enable the masquerading
So that got me thinking maybe this same concept could be applied to
the BGP'd subnets, forcing them to use masquerading. But rather a
rule on the source address, we set it for destinations.
Here is what I came up with. (Untested)
http://www.qsl.net/kb9mwr/wapr/tcpip/startampr-bgp
Basically I download a list of all the BGP'd subnets, and set a flag
like before and force them out as masqueraded.
> Subject:
> Re: [44net] New Linux Boot Scripts for Testing
> From:
> Gustavo Ponza <g.ponza(a)tin.it>
> Date:
> 08/04/2015 02:10 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> As per the 44.88.0.9:
>
> As per my tests since this morning (local time) for the first time
> I can ping and connect the http and ftp facilities at 44.88.0.9 and
> downloaded some files... never happened since years to now!!!
> Hope that Brian will share his actual GW setup, TNX.
>
> As per the 44.137.0.1 and subnets:
>
> Report is that the 44.137.0.1 GW is promptly pingable, but regarding
> their subnet only the following are *correctly* pingable, namely:
>
> 44.137.24.5
> 44.137.40.1
> 44.137.40.10
> 44.137.40.2
> 44.137.40.20
>
> all the other not.
Those addresses are not on the 44.137.0.1 gateway but on two different private
gateway systems that advertise only those addresses.
I hope everyone correctly implements a "most specific route first" policy that means that
traffic to such addresses goes to the indicated tunnel endpoint (89.18.172.155 and 89.18.172.156)
while other addresses in the 44.137.0.0/16 network are routed to tunnel endpoint
213.222.29.194. That should be no problem on e.g. a Linux system.
For example, 44.137.41.97 should be pingable via that endpoint. When doing a traceroute,
you should see a couple more hops after the tunnel that are radio hops.
>
> As per the 44.60.44.10:
>
> Remain not pingable
>
Same for me!
> The hamwan.org remain unreachable
That one is reachable for me:
traceroute hamwan.org
traceroute to hamwan.org (44.24.241.98), 30 hops max, 60 byte packets
1 gw.pe1chl.ampr.org (44.137.41.110) 0.248 ms 0.337 ms 0.428 ms
2 cisco1.pi1utr.ampr.org (44.137.41.254) 2.254 ms 20.621 ms 21.124 ms
3 pi1utr.pi9noz.ampr.org (44.137.60.1) 22.615 ms 34.658 ms 34.694 ms
4 213.222.29.193 (213.222.29.193) 68.524 ms 68.560 ms 68.582 ms
5 0.xe-7-0-1.xr4.1d12.xs4all.net (194.109.12.5) 68.636 ms 70.600 ms 71.415 ms
6 0.ge-0-2-0.xr1.sara.xs4all.net (194.109.5.2) 73.308 ms 77.651 ms 77.645 ms
7 er1.ams1.nl.above.net (80.249.208.122) 79.347 ms 64.952 ms 11.503 ms
8 ae14.cr1.ams10.nl.zip.zayo.com (64.125.21.77) 13.982 ms 14.622 ms 15.123 ms
9 v142.ae29.cr2.ord2.us.zip.zayo.com (64.125.30.170) 112.583 ms 112.614 ms 113.365 ms
10 ae11.cr1.ord2.us.zip.zayo.com (64.125.20.245) 118.816 ms 119.403 ms 120.093 ms
11 v11.ae29.mpr1.sea1.us.zip.zayo.com (64.125.31.50) 158.630 ms 159.681 ms 160.046 ms
12 216.200.88.129.z00003.above.net (216.200.88.129) 159.559 ms 159.593 ms 159.922 ms
13 ge0-0-0-0-sea4.threshinc.net (209.189.201.214) 150.858 ms ge0-0-0-0-sea3.threshinc.net (209.189.201.213) 151.354 ms ge0-0-0-1-sea3.threshinc.net (209.189.202.213) 151.977 ms
14 seattle-er1.hamwan.net (209.189.196.68) 152.033 ms 150.810 ms 151.959 ms
15 eth0.seattle-srv1.hamwan.net (44.24.241.98) 149.933 ms 150.508 ms 151.199 ms
It goes via radio to our 44.137.0.0/16 gateway and from there over plain internet (it is BGP routed).
You may have trouble trying to access this with some of the typical tunnel setups because they provide no tunnel endpoint.
Rob
