10 May
2024
10 May
'24
6:43 a.m.
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(a)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(a)ardc.net> wrote:
On 10 May 2024, at 10:36, lleachii--- via 44net
<44net(a)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(a)mailman.ampr.org <mailto:44net@mailman.ampr.org>
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
<mailto:44net-leave@mailman.ampr.org>