Seems to be working now.
On 4/6/2024 1:33 PM, Chris via 44net wrote:
Hi Lynwood,
Please try again…?
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 6 Apr 2024, at 17:48, lleachii@aol.com wrote:
Chris,
/"What is the A record hostname for that IP supposed to be? I can check if it’s in the zonefile or not - likely not - was it added only recently?"/That's the issue, it was not added recently- it's been there for years, since I first devised my internal network plan years ago:
kb3vwg-128.ampr.org
user@machine:~$ nslookup 44.60.44.128 44.0.0.1 128.44.60.44.in-addr.arpa name = kb3vwg-128.ampr.org.
It is in the zone file.
- Lynwood
On Saturday, April 6, 2024 at 12:41:29 PM EDT, Chris via 44net 44net@mailman.ampr.org wrote:
So, we are in the process of moving the primary nameserver away from the UCSD gateway server so all it will be left with is acting as the IPIP encap/de-encap gateway function + rip44d, so don’t rely on doing zone transfers from that server for much longer.
As to your egress problem, I checked on the gateway and your 44.60.44.128 IP is not in the filter list but your 44.60.44.1 IP is, that’s why it’s not working for 44.60.44.128. What is the A record hostname for that IP supposed to be? I can check if it’s in the zonefile or not - likely not - was it added only recently?
73, Chris - G1FEF — ARDC Administrator
Web: https://www.ardc.net
On 6 Apr 2024, at 12:02, lleachii--- via 44net 44net@mailman.ampr.org wrote:
Chris,
I suspect some failure in the location that maintains what AMPR IPs have DNS entries - hence allowing FORWARD on AMPRGW.
Rationale:
- My ingress TCP traces are blocked for 44.60.44.128, yet work for
44.60.44.1, 44.60.44.3 and 44.60.44.10
- On a side note, I also observe that on my DNS server (44.60.44.3) -
that the 44.in-addr.arpa Zone seems to be failing (checking logs). I can no longer get authoritative answers, but I can still query 44.0.0.1 and get Zone Transfers (port 53/TCP) for AMPR.ORG. Was the Reverse Zone edited somehow?
- Lynwood
On Saturday, April 6, 2024 at 05:47:53 AM EDT, lleachii@aol.com lleachii@aol.com wrote:
Chris,
Another interesting observation occurred when testing egress from my LAN and router with various SRC IPs. My LAN is configured with a SNAT and IP/Rules to use 44.60.44.128 for traffic from a certain LAN SRC IP is set on the client.
- With my usual SNAT setting of SRC 44.60.44.128 - ping DOESN'T WORK
- When pining from the router with 44.60.44.1 and changing the LAN
SNAT rule to also use SRC 44.60.44.1 - ping WORKS
root@OpenWrt:~# ping -c 5 1.1.1.1 -I 44.60.44.1 PING 1.1.1.1 (1.1.1.1) from 44.60.44.1: 56 data bytes 64 bytes from 1.1.1.1: seq=0 ttl=55 time=67.178 ms 64 bytes from 1.1.1.1: seq=1 ttl=55 time=65.657 ms 64 bytes from 1.1.1.1: seq=2 ttl=55 time=65.435 ms 64 bytes from 1.1.1.1: seq=3 ttl=55 time=65.314 ms 64 bytes from 1.1.1.1: seq=4 ttl=55 time=65.462 ms
--- 1.1.1.1 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 65.314/65.809/67.178 ms
- Lynwood
KB3VWG