Does ns.ardc.org have an access policy restricting traffic to only IPs with a DNS entry (i.e. Intra-AMPRNet only)? That differs from what I've been told, so I wish ask. I'm having a difficult time with one of my valid AMPRNet IPs and have been struggling for days. I only have success with IPS having DNS entries.
73,
LynwoodKB3VWG
On 10 May 2024, at 10:36, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Does ns.ardc.org have an access policy restricting traffic to only IPs with a DNS entry (i.e. Intra-AMPRNet only)?
That differs from what I've been told, so I wish ask.
I'm having a difficult time with one of my valid AMPRNet IPs and have been struggling for days. I only have success with IPS having DNS entries.
ns.ardc.net will provide authoritative DNS answers from any IPv4 or IPv6 address for ampr.org and the reverse zones it is authoritative for.
From what you’ve said it may be that you are trying to query it from a host inside the IPIP Tunnel Mesh? In which case your query will need to traverse the gateway router at UCSD in order to reach ns.ardc.net which, although is on a 44Net IP address, is not connected to the IPIP Tunnel Mesh - it is on directly announced (BGP) 44Net address space.
As you can only traverse the gateway router at UCSD if your host’s IP has an A record in ampr.org that is the most likely reason for what you are seeing.
73, Chris - G1FEF
73,
Lynwood KB3VWG
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Chris,
I'm not sure you understand how profound your statement was or should be to all. Per our discussions on this thread, I understood the use case to be that access to ns.ardc.net be via 44net SRC IPs. Perhaps I misconceive that the IPENCAP users were being considered when the statement was made? So OK cool - this server sits on the Public Internet, without a [voluntary] tunnel. I previously inquired about it's location, etc. for these reasons (keeping in mind UDP delays discussed for NTP, DNS, etc.):
config nat option src 'amprwan' option src_ip '44.60.44.254' option dest_ip '44.1.1.44/32' option target 'SNAT' option snat_ip '44.60.44.1' option name 'test' list proto 'all' Reasoning to explain the complexity - In addition to needing an IP rule to for the route to use AMPRNet, I then need to SNAT to use a Public IP 44net IP - because the server is not on AMPRNet. --- root@OpenWrt:~# tcpdump -vvvn -i tunl0 udp and port 123 and host 44.1.1.44tcpdump: listening on tunl0, link-type RAW (Raw IP), snapshot length 262144 bytes10:09:07.781705 IP (tos 0x48, ttl 64, id 11385, offset 0, flags [DF], proto UDP (17), length 76) 44.60.44.1.46695 > 44.1.1.44.123: [bad udp cksum 0x85b3 -> 0x9279!] NTPv4, Client, length 48 Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z)10:09:07.981557 IP (tos 0x0, ttl 50, id 38178, offset 0, flags [DF], proto UDP (17), length 76) 44.1.1.44.123 > 44.60.44.1.46695: [udp sum ok] NTPv4, Server, length 48 Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -22 Root Delay: 0.004333, Root dispersion: 0.039169, Reference-ID: 0x55c7d666 Reference Timestamp: 3924323032.642092258 (2024-05-10T09:43:52Z) Originator Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z) Receive Timestamp: 3924324547.884376446 (2024-05-10T10:09:07Z) Transmit Timestamp: 3924324547.884487523 (2024-05-10T10:09:07Z) Originator - Receive Timestamp: +2575241305.104811271 Originator - Transmit Timestamp: +2575241305.104922349
---
It now works. Transparency is key and I appreciate the response.
So now the question truly begs. Since you know our IPs, why not make a firewall/access rule allowing them also (that's what I do, because it seems to have been done on the old gw.ampr.org)? It seems that we took an extremely circuitous route for me to determine the same information I inquired upon originally and had to learn through days of seeing connectivity errors relying on the statement. I'm glad it's clarified now.
Many thanks and 73,
- KB3VWG
On Friday, May 10, 2024 at 05:47:41 AM EDT, Chris chris@ardc.net wrote:
On 10 May 2024, at 10:36, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Does ns.ardc.org have an access policy restricting traffic to only IPs with a DNS entry (i.e. Intra-AMPRNet only)?
That differs from what I've been told, so I wish ask.
I'm having a difficult time with one of my valid AMPRNet IPs and have been struggling for days. I only have success with IPS having DNS entries.
ns.ardc.net will provide authoritative DNS answers from any IPv4 or IPv6 address for ampr.org and the reverse zones it is authoritative for.
From what you’ve said it may be that you are trying to query it from a host inside the IPIP Tunnel Mesh? In which case your query will need to traverse the gateway router at UCSD in order to reach ns.ardc.net which, although is on a 44Net IP address, is not connected to the IPIP Tunnel Mesh - it is on directly announced (BGP) 44Net address space.
As you can only traverse the gateway router at UCSD if your host’s IP has an A record in ampr.org that is the most likely reason for what you are seeing.
73, Chris - G1FEF
73,
Lynwood KB3VWG
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Hi Lynwood,
I can look into the feasibility of adding a tunnel endpoint to at least one of the authoritative DNS servers if you think that would be useful.
Just FYI though, the IPIP Tunnel Mesh network is on the decline, it has been for many years now, at some point in the not too distant future I imagine it will be deprecated in favour of the far more feature rich and reliable POPs the TAC are developing and which are currently in beta.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 10 May 2024, at 11:32, lleachii@aol.com wrote:
Chris,
I'm not sure you understand how profound your statement was or should be to all. Per our discussions on this thread, I understood the use case to be that access to ns.ardc.net be via 44net SRC IPs. Perhaps I misconceive that the IPENCAP users were being considered when the statement was made?
So OK cool - this server sits on the Public Internet, without a [voluntary] tunnel. I previously inquired about it's location, etc. for these reasons (keeping in mind UDP delays discussed for NTP, DNS, etc.):
config nat option src 'amprwan' option src_ip '44.60.44.254' option dest_ip '44.1.1.44/32' option target 'SNAT' option snat_ip '44.60.44.1' option name 'test' list proto 'all'
Reasoning to explain the complexity -
In addition to needing an IP rule to for the route to use AMPRNet, I then need to SNAT to use a Public IP 44net IP - because the server is not on AMPRNet.
root@OpenWrt:~# tcpdump -vvvn -i tunl0 udp and port 123 and host 44.1.1.44 tcpdump: listening on tunl0, link-type RAW (Raw IP), snapshot length 262144 bytes 10:09:07.781705 IP (tos 0x48, ttl 64, id 11385, offset 0, flags [DF], proto UDP (17), length 76) 44.60.44.1.46695 > 44.1.1.44.123: [bad udp cksum 0x85b3 -> 0x9279!] NTPv4, Client, length 48 Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z) 10:09:07.981557 IP (tos 0x0, ttl 50, id 38178, offset 0, flags [DF], proto UDP (17), length 76) 44.1.1.44.123 > 44.60.44.1.46695: [udp sum ok] NTPv4, Server, length 48 Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -22 Root Delay: 0.004333, Root dispersion: 0.039169, Reference-ID: 0x55c7d666 Reference Timestamp: 3924323032.642092258 (2024-05-10T09:43:52Z) Originator Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z) Receive Timestamp: 3924324547.884376446 (2024-05-10T10:09:07Z) Transmit Timestamp: 3924324547.884487523 (2024-05-10T10:09:07Z) Originator - Receive Timestamp: +2575241305.104811271 Originator - Transmit Timestamp: +2575241305.104922349
It now works. Transparency is key and I appreciate the response.
So now the question truly begs. Since you know our IPs, why not make a firewall/access rule allowing them also (that's what I do, because it seems to have been done on the old gw.ampr.org)?
It seems that we took an extremely circuitous route for me to determine the same information I inquired upon originally and had to learn through days of seeing connectivity errors relying on the statement. I'm glad it's clarified now.
Many thanks and 73,
- KB3VWG
On Friday, May 10, 2024 at 05:47:41 AM EDT, Chris chris@ardc.net wrote:
On 10 May 2024, at 10:36, lleachii--- via 44net <44net@mailman.ampr.org mailto:44net@mailman.ampr.org> wrote:
Does ns.ardc.org have an access policy restricting traffic to only IPs with a DNS entry (i.e. Intra-AMPRNet only)?
That differs from what I've been told, so I wish ask.
I'm having a difficult time with one of my valid AMPRNet IPs and have been struggling for days. I only have success with IPS having DNS entries.
ns.ardc.net will provide authoritative DNS answers from any IPv4 or IPv6 address for ampr.org and the reverse zones it is authoritative for.
From what you’ve said it may be that you are trying to query it from a host inside the IPIP Tunnel Mesh? In which case your query will need to traverse the gateway router at UCSD in order to reach ns.ardc.net which, although is on a 44Net IP address, is not connected to the IPIP Tunnel Mesh - it is on directly announced (BGP) 44Net address space.
As you can only traverse the gateway router at UCSD if your host’s IP has an A record in ampr.org that is the most likely reason for what you are seeing.
73, Chris - G1FEF
73,
Lynwood KB3VWG
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org
ARDC as their own ISP? What about those who have no interest in doing that?
On 5/10/2024 6:43 AM, Chris via 44net wrote:
Just FYI though, the IPIP Tunnel Mesh network is on the decline, it has been for many years now, at some point in the not too distant future I imagine it will be deprecated in favour of the far more feature rich and reliable POPs the TAC are developing and which are currently in beta.
Hi Charles,
As I said, the IPIP Tunnel Mesh network is on the decline, it has been for a while, it is old technology. Folks new to 44Net find it difficult to setup and maintain, this is one the biggest complaints we receive and was the incentive for the TAC to develop the POPs, giving the next generation of 44Net users an “easy on-ramp” so they are not discouraged into joining us. Although the POPs will initially be rolled out by ARDC, the software will be open sourced and therefore we fully expect others to use the software to create their own POPs - no ARDC monopoly!
Of course, you are free to continue using the IPIP Tunnel Mesh for as long as you wish, I am just noting that it will become less and less utilised as folks naturally migrate to a more user friendly, more reliable, feature rich platform. Technology moves on, you are welcome to join us on the journey if you so choose.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 10 May 2024, at 11:57, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
ARDC as their own ISP? What about those who have no interest in doing that?
On 5/10/2024 6:43 AM, Chris via 44net wrote:
Just FYI though, the IPIP Tunnel Mesh network is on the decline, it has been for many years now, at some point in the not too distant future I imagine it will be deprecated in favour of the far more feature rich and reliable POPs the TAC are developing and which are currently in beta.
-- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.
NYC-ARECS/RACES Nets 441.100/136.5 PL ARnewsline Broadcast Mon. @ 8:00PM NYC-ARECS Weekly Net Mon. @ 8:30PM http://www.nyc-arecs.org
NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32
"Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan
"The more corrupt the state, the more it legislates." - Tacitus
"Molann an obair an fear" - Irish Saying (The work praises the man.)
"No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Chris,
On a few OS'es IPENCAP is plug-and-play. OpenWrt I believe has an ampr-ripd package. Someone created the makefile. It is extremely viable - but again, I don't know what technology the TAC is Beta Testing. How did selection of technology and Alpha Phase go? When I was in the mailing group I recall discussing Wireguard.
- KB3VWG
On Friday, May 10, 2024 at 07:16:18 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Charles, As I said, the IPIP Tunnel Mesh network is on the decline, it has been for a while, it is old technology. Folks new to 44Net find it difficult to setup and maintain, this is one the biggest complaints we receive and was the incentive for the TAC to develop the POPs, giving the next generation of 44Net users an “easy on-ramp” so they are not discouraged into joining us. Although the POPs will initially be rolled out by ARDC, the software will be open sourced and therefore we fully expect others to use the software to create their own POPs - no ARDC monopoly! Of course, you are free to continue using the IPIP Tunnel Mesh for as long as you wish, I am just noting that it will become less and less utilised as folks naturally migrate to a more user friendly, more reliable, feature rich platform. Technology moves on, you are welcome to join us on the journey if you so choose. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 10 May 2024, at 11:57, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote: ARDC as their own ISP? What about those who have no interest in doing that?
On 5/10/2024 6:43 AM, Chris via 44net wrote:
Just FYI though, the IPIP Tunnel Mesh network is on the decline, it has been for many years now, at some point in the not too distant future I imagine it will be deprecated in favour of the far more feature rich and reliable POPs the TAC are developing and which are currently in beta.
The POPs utilise WireGuard, yes.
Chris - G1EF
On 10 May 2024, at 12:30, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Chris,
On a few OS'es IPENCAP is plug-and-play. OpenWrt I believe has an ampr-ripd package. Someone created the makefile.
It is extremely viable - but again, I don't know what technology the TAC is Beta Testing. How did selection of technology and Alpha Phase go?
When I was in the mailing group I recall discussing Wireguard.
- KB3VWG
On Friday, May 10, 2024 at 07:16:18 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Charles,
As I said, the IPIP Tunnel Mesh network is on the decline, it has been for a while, it is old technology. Folks new to 44Net find it difficult to setup and maintain, this is one the biggest complaints we receive and was the incentive for the TAC to develop the POPs, giving the next generation of 44Net users an “easy on-ramp” so they are not discouraged into joining us. Although the POPs will initially be rolled out by ARDC, the software will be open sourced and therefore we fully expect others to use the software to create their own POPs - no ARDC monopoly!
Of course, you are free to continue using the IPIP Tunnel Mesh for as long as you wish, I am just noting that it will become less and less utilised as folks naturally migrate to a more user friendly, more reliable, feature rich platform. Technology moves on, you are welcome to join us on the journey if you so choose.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 10 May 2024, at 11:57, Charles J. Hargrove via 44net 44net@mailman.ampr.org wrote:
ARDC as their own ISP? What about those who have no interest in doing that?
On 5/10/2024 6:43 AM, Chris via 44net wrote:
Just FYI though, the IPIP Tunnel Mesh network is on the decline, it has been for many years now, at some point in the not too distant future I imagine it will be deprecated in favour of the far more feature rich and reliable POPs the TAC are developing and which are currently in beta.
-- Charles J. Hargrove - N2NOV NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.
NYC-ARECS/RACES Nets 441.100/136.5 PL ARnewsline Broadcast Mon. @ 8:00PM NYC-ARECS Weekly Net Mon. @ 8:30PM http://www.nyc-arecs.org
NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32
"Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan
"The more corrupt the state, the more it legislates." - Tacitus
"Molann an obair an fear" - Irish Saying (The work praises the man.)
"No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Chris,
I want to not the VALUE of that idea I presented, if you result in testing a solution that manages the Wireguard keys.
I want to clearly note I discussed that in the defunct TAC group.
- Lynwood
On Friday, May 10, 2024 at 07:39:21 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
The POPs utilise WireGuard, yes. Chris - G1EF
Chris, So to be clear, 44.1.1.44 resides at AS64435 The Communication GATEWAY LTD in the United Kingdom. You seem to control 44.1.1.0/24 for the purpose? So instead of me leaving MDC and my packet hopping a trans-Atlantic fiber cable to you, it makes a round trip to California first before doing so. TBH, let me review the current Wiki wording, etc. As I understand it now - IPENCAP users have to make complex routes/rules (and possibly SNATs if they firewall and respect AMPRGW's bandwidth) on their GW to use services with ns.ardc,org -from within AMPRNet. That's not considering now we're discussing NTP. I mentioned privately to you there was a TAC mailing list that went defunct, I'd like to beta test as well. This is a lot of information to consume. Sharing is key as well.
- KB3VWG On Friday, May 10, 2024 at 06:43:15 AM EDT, Chris chris@ardc.net wrote:
Hi Lynwood, I can look into the feasibility of adding a tunnel endpoint to at least one of the authoritative DNS servers if you think that would be useful. Just FYI though, the IPIP Tunnel Mesh network is on the decline, it has been for many years now, at some point in the not too distant future I imagine it will be deprecated in favour of the far more feature rich and reliable POPs the TAC are developing and which are currently in beta. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 10 May 2024, at 11:32, lleachii@aol.com wrote: Chris,
I'm not sure you understand how profound your statement was or should be to all. Per our discussions on this thread, I understood the use case to be that access to ns.ardc.net be via 44net SRC IPs. Perhaps I misconceive that the IPENCAP users were being considered when the statement was made? So OK cool - this server sits on the Public Internet, without a [voluntary] tunnel. I previously inquired about it's location, etc. for these reasons (keeping in mind UDP delays discussed for NTP, DNS, etc.):
config nat option src 'amprwan' option src_ip '44.60.44.254' option dest_ip '44.1.1.44/32' option target 'SNAT' option snat_ip '44.60.44.1' option name 'test' list proto 'all' Reasoning to explain the complexity - In addition to needing an IP rule to for the route to use AMPRNet, I then need to SNAT to use a Public IP 44net IP - because the server is not on AMPRNet. --- root@OpenWrt:~# tcpdump -vvvn -i tunl0 udp and port 123 and host 44.1.1.44tcpdump: listening on tunl0, link-type RAW (Raw IP), snapshot length 262144 bytes10:09:07.781705 IP (tos 0x48, ttl 64, id 11385, offset 0, flags [DF], proto UDP (17), length 76) 44.60.44.1.46695 > 44.1.1.44.123: [bad udp cksum 0x85b3 -> 0x9279!] NTPv4, Client, length 48 Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z)10:09:07.981557 IP (tos 0x0, ttl 50, id 38178, offset 0, flags [DF], proto UDP (17), length 76) 44.1.1.44.123 > 44.60.44.1.46695: [udp sum ok] NTPv4, Server, length 48 Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -22 Root Delay: 0.004333, Root dispersion: 0.039169, Reference-ID: 0x55c7d666 Reference Timestamp: 3924323032.642092258 (2024-05-10T09:43:52Z) Originator Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z) Receive Timestamp: 3924324547.884376446 (2024-05-10T10:09:07Z) Transmit Timestamp: 3924324547.884487523 (2024-05-10T10:09:07Z) Originator - Receive Timestamp: +2575241305.104811271 Originator - Transmit Timestamp: +2575241305.104922349
---
It now works. Transparency is key and I appreciate the response.
So now the question truly begs. Since you know our IPs, why not make a firewall/access rule allowing them also (that's what I do, because it seems to have been done on the old gw.ampr.org)? It seems that we took an extremely circuitous route for me to determine the same information I inquired upon originally and had to learn through days of seeing connectivity errors relying on the statement. I'm glad it's clarified now.
Many thanks and 73,
- KB3VWG
On Friday, May 10, 2024 at 05:47:41 AM EDT, Chris chris@ardc.net wrote:
On 10 May 2024, at 10:36, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Does ns.ardc.org have an access policy restricting traffic to only IPs with a DNS entry (i.e. Intra-AMPRNet only)?
That differs from what I've been told, so I wish ask.
I'm having a difficult time with one of my valid AMPRNet IPs and have been struggling for days. I only have success with IPS having DNS entries.
ns.ardc.net will provide authoritative DNS answers from any IPv4 or IPv6 address for ampr.org and the reverse zones it is authoritative for.
From what you’ve said it may be that you are trying to query it from a host inside the IPIP Tunnel Mesh? In which case your query will need to traverse the gateway router at UCSD in order to reach ns.ardc.net which, although is on a 44Net IP address, is not connected to the IPIP Tunnel Mesh - it is on directly announced (BGP) 44Net address space.
As you can only traverse the gateway router at UCSD if your host’s IP has an A record in ampr.org that is the most likely reason for what you are seeing.
73, Chris - G1FEF
73,
Lynwood KB3VWG
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Hi Lynwood,
So to be clear, 44.1.1.44 resides at AS64435 The Communication GATEWAY LTD in the United Kingdom. You seem to control 44.1.1.0/24 for the purpose?
The company you mention is contracted by ARDC to provide some hosting services, mostly internal to ARDC but there are some services such as ns.ardc.net http://ns.ardc.net/ hosted there as well. ARDC staff control the VMs. It’s a fairly standard arrangement as ARDC don’t have their own rackspace yet - although that may be changing in the future.
So instead of me leaving MDC and my packet hopping a trans-Atlantic fiber cable to you, it makes a round trip to California first before doing so.
I don't understand why this is a problem - a few more ms delay on a reliable fibre network will not adversely affect DNS lookups.
TBH, let me review the current Wiki wording, etc.
As I understand it now - IPENCAP users have to make complex routes/rules (and possibly SNATs if they firewall and respect AMPRGW's bandwidth) on their GW to use services with ns.ardc,org -from within AMPRNet. That's not considering now we're discussing NTP.
Not really, so long as you have an A record for your encap’d host it will traverse the gateway router without any issue.
I mentioned privately to you there was a TAC mailing list that went defunct, I'd like to beta test as well.
This is a lot of information to consume. Sharing is key as well.
You can find all our discussion groups here: https://ardc.groups.io/g/main you are welcome to join in.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net https://www.ardc.net/
- KB3VWG
On Friday, May 10, 2024 at 06:43:15 AM EDT, Chris chris@ardc.net wrote:
Hi Lynwood,
I can look into the feasibility of adding a tunnel endpoint to at least one of the authoritative DNS servers if you think that would be useful.
Just FYI though, the IPIP Tunnel Mesh network is on the decline, it has been for many years now, at some point in the not too distant future I imagine it will be deprecated in favour of the far more feature rich and reliable POPs the TAC are developing and which are currently in beta.
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 10 May 2024, at 11:32, lleachii@aol.com wrote:
Chris,
I'm not sure you understand how profound your statement was or should be to all. Per our discussions on this thread, I understood the use case to be that access to ns.ardc.net be via 44net SRC IPs. Perhaps I misconceive that the IPENCAP users were being considered when the statement was made?
So OK cool - this server sits on the Public Internet, without a [voluntary] tunnel. I previously inquired about it's location, etc. for these reasons (keeping in mind UDP delays discussed for NTP, DNS, etc.):
config nat option src 'amprwan' option src_ip '44.60.44.254' option dest_ip '44.1.1.44/32' option target 'SNAT' option snat_ip '44.60.44.1' option name 'test' list proto 'all'
Reasoning to explain the complexity -
In addition to needing an IP rule to for the route to use AMPRNet, I then need to SNAT to use a Public IP 44net IP - because the server is not on AMPRNet.
root@OpenWrt:~# tcpdump -vvvn -i tunl0 udp and port 123 and host 44.1.1.44 tcpdump: listening on tunl0, link-type RAW (Raw IP), snapshot length 262144 bytes 10:09:07.781705 IP (tos 0x48, ttl 64, id 11385, offset 0, flags [DF], proto UDP (17), length 76) 44.60.44.1.46695 > 44.1.1.44.123: [bad udp cksum 0x85b3 -> 0x9279!] NTPv4, Client, length 48 Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z) 10:09:07.981557 IP (tos 0x0, ttl 50, id 38178, offset 0, flags [DF], proto UDP (17), length 76) 44.1.1.44.123 > 44.60.44.1.46695: [udp sum ok] NTPv4, Server, length 48 Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -22 Root Delay: 0.004333, Root dispersion: 0.039169, Reference-ID: 0x55c7d666 Reference Timestamp: 3924323032.642092258 (2024-05-10T09:43:52Z) Originator Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z) Receive Timestamp: 3924324547.884376446 (2024-05-10T10:09:07Z) Transmit Timestamp: 3924324547.884487523 (2024-05-10T10:09:07Z) Originator - Receive Timestamp: +2575241305.104811271 Originator - Transmit Timestamp: +2575241305.104922349
It now works. Transparency is key and I appreciate the response.
So now the question truly begs. Since you know our IPs, why not make a firewall/access rule allowing them also (that's what I do, because it seems to have been done on the old gw.ampr.org)?
It seems that we took an extremely circuitous route for me to determine the same information I inquired upon originally and had to learn through days of seeing connectivity errors relying on the statement. I'm glad it's clarified now.
Many thanks and 73,
- KB3VWG
On Friday, May 10, 2024 at 05:47:41 AM EDT, Chris chris@ardc.net wrote:
On 10 May 2024, at 10:36, lleachii--- via 44net <44net@mailman.ampr.org mailto:44net@mailman.ampr.org> wrote:
Does ns.ardc.org have an access policy restricting traffic to only IPs with a DNS entry (i.e. Intra-AMPRNet only)?
That differs from what I've been told, so I wish ask.
I'm having a difficult time with one of my valid AMPRNet IPs and have been struggling for days. I only have success with IPS having DNS entries.
ns.ardc.net will provide authoritative DNS answers from any IPv4 or IPv6 address for ampr.org and the reverse zones it is authoritative for.
From what you’ve said it may be that you are trying to query it from a host inside the IPIP Tunnel Mesh? In which case your query will need to traverse the gateway router at UCSD in order to reach ns.ardc.net which, although is on a 44Net IP address, is not connected to the IPIP Tunnel Mesh - it is on directly announced (BGP) 44Net address space.
As you can only traverse the gateway router at UCSD if your host’s IP has an A record in ampr.org that is the most likely reason for what you are seeing.
73, Chris - G1FEF
73,
Lynwood KB3VWG
44net mailing list -- 44net@mailman.ampr.org mailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org mailto:44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
Chris,
I specifically noted NTP here (there is a reason). You now mentioned the same groups I inquired about before to inquire, but received private emails instead to speak to you alone. I'll do more research to find those as well now. This really does seem circular.
Thanks and 73,
- KB3VWG
On Friday, May 10, 2024 at 07:27:16 AM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
Hi Lynwood,
So to be clear, 44.1.1.44 resides at AS64435 The Communication GATEWAY LTD in the United Kingdom. You seem to control 44.1.1.0/24 for the purpose?
The company you mention is contracted by ARDC to provide some hosting services, mostly internal to ARDC but there are some services such as ns.ardc.net hosted there as well. ARDC staff control the VMs. It’s a fairly standard arrangement as ARDC don’t have their own rackspace yet - although that may be changing in the future.
So instead of me leaving MDC and my packet hopping a trans-Atlantic fiber cable to you, it makes a round trip to California first before doing so.
I don't understand why this is a problem - a few more ms delay on a reliable fibre network will not adversely affect DNS lookups.
TBH, let me review the current Wiki wording, etc. As I understand it now - IPENCAP users have to make complex routes/rules (and possibly SNATs if they firewall and respect AMPRGW's bandwidth) on their GW to use services with ns.ardc,org -from within AMPRNet. That's not considering now we're discussing NTP.
Not really, so long as you have an A record for your encap’d host it will traverse the gateway router without any issue.
I mentioned privately to you there was a TAC mailing list that went defunct, I'd like to beta test as well. This is a lot of information to consume. Sharing is key as well.
You can find all our discussion groups here: https://ardc.groups.io/g/main%C2%A0you are welcome to join in. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
- KB3VWG On Friday, May 10, 2024 at 06:43:15 AM EDT, Chris chris@ardc.net wrote:
Hi Lynwood, I can look into the feasibility of adding a tunnel endpoint to at least one of the authoritative DNS servers if you think that would be useful. Just FYI though, the IPIP Tunnel Mesh network is on the decline, it has been for many years now, at some point in the not too distant future I imagine it will be deprecated in favour of the far more feature rich and reliable POPs the TAC are developing and which are currently in beta. 73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 10 May 2024, at 11:32, lleachii@aol.com wrote: Chris,
I'm not sure you understand how profound your statement was or should be to all. Per our discussions on this thread, I understood the use case to be that access to ns.ardc.net be via 44net SRC IPs. Perhaps I misconceive that the IPENCAP users were being considered when the statement was made? So OK cool - this server sits on the Public Internet, without a [voluntary] tunnel. I previously inquired about it's location, etc. for these reasons (keeping in mind UDP delays discussed for NTP, DNS, etc.):
config nat option src 'amprwan' option src_ip '44.60.44.254' option dest_ip '44.1.1.44/32' option target 'SNAT' option snat_ip '44.60.44.1' option name 'test' list proto 'all' Reasoning to explain the complexity - In addition to needing an IP rule to for the route to use AMPRNet, I then need to SNAT to use a Public IP 44net IP - because the server is not on AMPRNet. --- root@OpenWrt:~# tcpdump -vvvn -i tunl0 udp and port 123 and host 44.1.1.44tcpdump: listening on tunl0, link-type RAW (Raw IP), snapshot length 262144 bytes10:09:07.781705 IP (tos 0x48, ttl 64, id 11385, offset 0, flags [DF], proto UDP (17), length 76) 44.60.44.1.46695 > 44.1.1.44.123: [bad udp cksum 0x85b3 -> 0x9279!] NTPv4, Client, length 48 Leap indicator: (0), Stratum 0 (unspecified), poll 0 (1s), precision 0 Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec) Reference Timestamp: 0.000000000 Originator Timestamp: 0.000000000 Receive Timestamp: 0.000000000 Transmit Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z) Originator - Receive Timestamp: 0.000000000 Originator - Transmit Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z)10:09:07.981557 IP (tos 0x0, ttl 50, id 38178, offset 0, flags [DF], proto UDP (17), length 76) 44.1.1.44.123 > 44.60.44.1.46695: [udp sum ok] NTPv4, Server, length 48 Leap indicator: (0), Stratum 2 (secondary reference), poll 0 (1s), precision -22 Root Delay: 0.004333, Root dispersion: 0.039169, Reference-ID: 0x55c7d666 Reference Timestamp: 3924323032.642092258 (2024-05-10T09:43:52Z) Originator Timestamp: 1349083242.779565174 (1942-10-02T09:20:42Z) Receive Timestamp: 3924324547.884376446 (2024-05-10T10:09:07Z) Transmit Timestamp: 3924324547.884487523 (2024-05-10T10:09:07Z) Originator - Receive Timestamp: +2575241305.104811271 Originator - Transmit Timestamp: +2575241305.104922349
---
It now works. Transparency is key and I appreciate the response.
So now the question truly begs. Since you know our IPs, why not make a firewall/access rule allowing them also (that's what I do, because it seems to have been done on the old gw.ampr.org)? It seems that we took an extremely circuitous route for me to determine the same information I inquired upon originally and had to learn through days of seeing connectivity errors relying on the statement. I'm glad it's clarified now.
Many thanks and 73,
- KB3VWG
On Friday, May 10, 2024 at 05:47:41 AM EDT, Chris chris@ardc.net wrote:
On 10 May 2024, at 10:36, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Does ns.ardc.org have an access policy restricting traffic to only IPs with a DNS entry (i.e. Intra-AMPRNet only)?
That differs from what I've been told, so I wish ask.
I'm having a difficult time with one of my valid AMPRNet IPs and have been struggling for days. I only have success with IPS having DNS entries.
ns.ardc.net will provide authoritative DNS answers from any IPv4 or IPv6 address for ampr.org and the reverse zones it is authoritative for.
From what you’ve said it may be that you are trying to query it from a host inside the IPIP Tunnel Mesh? In which case your query will need to traverse the gateway router at UCSD in order to reach ns.ardc.net which, although is on a 44Net IP address, is not connected to the IPIP Tunnel Mesh - it is on directly announced (BGP) 44Net address space.
As you can only traverse the gateway router at UCSD if your host’s IP has an A record in ampr.org that is the most likely reason for what you are seeing.
73, Chris - G1FEF
73,
Lynwood KB3VWG
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
On 5/10/24 07:26, Chris via 44net wrote:
So instead of me leaving MDC and my packet hopping a trans-Atlantic fiber cable to you, it makes a round trip to California first before doing so.
I don't understand why this is a problem - a few more ms delay on a reliable fibre network will not adversely affect DNS lookups.
This may not be entirely true for streaming services, especially voip telephony. While a phone or its server is looking up a host name in DNS, there will likely be no audio heard on the connection. The connection will appear to have gone dead or have a momentary dropout until the DNS responds. And, the longer the delay in getting that DNS response, the longer will be that dropout period of time.
For streaming video, you will get no dropout, but you will see a frame freeze.
For typical tcp services, such as web, there will be a slightly longer response time when changing pages. Of course, smtp will not show anything.
73, Mark, N2MH
I just wanted to add, the "few more ms delay" - is actually more like the following:
---
root@OpenWrt:~# ping 44.1.1.44 -I wan -c 4PING 44.1.1.44 (44.1.1.44): 56 data bytes64 bytes from 44.1.1.44: seq=0 ttl=54 time=80.774 ms64 bytes from 44.1.1.44: seq=1 ttl=54 time=80.527 ms64 bytes from 44.1.1.44: seq=2 ttl=54 time=80.781 ms64 bytes from 44.1.1.44: seq=3 ttl=54 time=80.752 ms --- 44.1.1.44 ping statistics ---4 packets transmitted, 4 packets received, 0% packet lossround-trip min/avg/max = 80.527/80.708/80.781 ms root@OpenWrt:~# ping 44.1.1.44 -I tunl0 -c 4PING 44.1.1.44 (44.1.1.44): 56 data bytes64 bytes from 44.1.1.44: seq=0 ttl=50 time=200.975 ms64 bytes from 44.1.1.44: seq=1 ttl=50 time=200.664 ms64 bytes from 44.1.1.44: seq=2 ttl=50 time=200.784 ms64 bytes from 44.1.1.44: seq=3 ttl=50 time=200.830 ms --- 44.1.1.44 ping statistics ---4 packets transmitted, 4 packets received, 0% packet lossround-trip min/avg/max = 200.664/200.813/200.975 ms
---
I wouldn't consider that just "a few more". This is just Ping and doesn't consider time in protocols where there's also the additional trip from the server to the user.
- KB3VWG
On Friday, May 10, 2024 at 09:43:33 PM EDT, Mark Herson, N2MH via 44net 44net@mailman.ampr.org wrote:
On 5/10/24 07:26, Chris via 44net wrote:
So instead of me leaving MDC and my packet hopping a trans-Atlantic fiber cable to you, it makes a round trip to California first before doing so.
I don't understand why this is a problem - a few more ms delay on a reliable fibre network will not adversely affect DNS lookups.
This may not be entirely true for streaming services, especially voip telephony. While a phone or its server is looking up a host name in DNS, there will likely be no audio heard on the connection. The connection will appear to have gone dead or have a momentary dropout until the DNS responds. And, the longer the delay in getting that DNS response, the longer will be that dropout period of time.
For streaming video, you will get no dropout, but you will see a frame freeze.
For typical tcp services, such as web, there will be a slightly longer response time when changing pages. Of course, smtp will not show anything.
73, Mark, N2MH
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
-
Charles J. Hargrove -
Chris -
lleachii＠aol.com -
Mark Herson, N2MH