Hello to those the list,
I have a VPN server running on a VPS (OpenVPN Access Server). I also have
the packet software XRouter (a.k.a. XRLin) running on the VPS. Normally it
can get the routes from the amprnet RIP broadcasts.
The VPN server uses a tunnel to send packets to my client. In the server to
client direction it takes packets from the internet addressed to the static
WAN address and changes the destination address to the client's VPN address
- pretty standard stuff. The dnat results in the traffic being routed to
the VPN tunnel. The OpenVPN Access Server writes rules to NFTables in order
to handle the forwarding, dnat, etc.
XRouter is set up with its own tunnel - somewhat similar to JNOS. I have
added rules in NFTables to forward all transport protocol 4/encap packets
to the XRouter tunnel. Included is a rule to dnat to Xrouter's address
which is on the Xrouter side of the P2P tunnel. This setup is working for
all encap packets EXCEPT the RIP packets.
Checking things with TCPdump, the RIP packets are being dnat'd to the VPN
tunnel address instead of the XRouter tunnel. I can't find any rules added
by the OpenVPN server that are matching any encap traffic, so I'm baffled
as to why they are not matched by my rules and also how they are matched by
the VPN rules. That said, the VPN Access server creates a very confusing
set of NTFable rules jumping all over the place though different chains, so
it's possible that they lost me. However I asked a question on their forum
a while back about support for protocol 4, and their answer was they don't
support it.
Is there anything about the RIP "IPIP" packets that is different from other
"IPIP" traffic so that they would be handled differently by NFTables?
Thanks,
Lee K5DAT
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Hello!
I've been working on getting my IPIP mesh gateway set up on Debian & feel like I'm almost there. One thing I’ve noticed is every time I reboot the router, it takes around 45-60 minutes before I can start passing traffic to the public internet again via the ucsd gateway. For example, after rebooting the router, once rip44d has retrieved the routes I can:
(a) Ping and curl across tunl0 to n2nov.ampr.org
(b) Use yo2tm’s nettools to successfully ping my ampr ip and see that traffic locally via tcpdump
But cannot:
(c) Ping 8.8.8.8 across tunl0 (via 169.228.34.84) or
(d) Curl to ifconfig.me across tunl0 (via 169.228.34.84)
However, if I just leave everything running and come back 45-60 minutes later, (c) and (d) work fine with no additional configuration changes and (d) returns the assigned 44net ip address.
Just curious if the above is an expected behavior or a sign that I’ve got something misconfigured.
-Steve
kc8qba
Happy New Year, Everyone!
ARDC will be at the Gwinnett Amateur Radio Society TechFest on January
13, 2024 in Lawrenceville, GA. If you're at the event, stop by our table
and say hello!
73,
Rebecca
KO4KVG
--
Rebecca Key - KO4KVG
Communicaions Manager
Amateur Radio Digital Communications (ARDC)
ardc.net
Hello everyone,
I’ve stumbled on a problem with my 44net connection and I’m hoping someone can shed light on what’s going on.
I’m connected using IPIP, and I can exchange traffic with other hosts that are also using IPIP (and hence appear in the RIP broadcasts).
Where I’m struggling is with a couple of subnets which perform their own BGP advertisements. I can reach them over the internet, but can’t from my 44net-connected system.
I can see traffic leaving my network for the hosts in question, encapsulated with a destination address of 169.228.34.84 (amprgw.ucsd.edu <http://amprgw.ucsd.edu/>), but my packets never reach the remote systems.
Any clues?
Mike Quin
Hey Everyone,
The December 2023 Newsletter is live: check it out for our latest
updates: https://ardc.net/?na=view&id=63
To receive regular updates about ARDC, please subscribe to our
newsletter: https://www.ardc.net/about/newsletter/
Thanks and 73,
Rebecca
KO4KVG
--
Rebecca Key - KO4KVG
Communicaions Manager
Amateur Radio Digital Communications (ARDC)
ardc.net
Hey Everyone,
ARDC will be closing for the year beginning on*Saturday, December 16,
2023*, and we’ll return to the office on*Tuesday, January 2, 2024*.
From the ARDC team, we hope that you and yours have a fantastic holiday
season. Thank you all for a great 2023, and we’ll see you in 2024!
73,
Rebecca
KO4KVG
--
Rebecca Key - KO4KVG
Communicaions Manager
Amateur Radio Digital Communications (ARDC)
ardc.net
Hey Everyone,
The November 2023 Newsletter is live: check it out for our latest
updates, including how to contribute to the AMPRNet Wiki:
https://www.ardc.net/?na=view&id=61
To receive regular updates about ARDC, please subscribe to our
newsletter: https://www.ardc.net/about/newsletter/
Thanks and 73,
Rebecca
KO4KVG
--
Rebecca Key - KO4KVG
Communicaions Manager
Amateur Radio Digital Communications (ARDC)
ardc.net
Hey Everyone,
If you're interested in what some of our grantees have been up to, check out our latest blog post that highlights the work from the folks at SIGNALS: Museum of Information Explosion and VBAS, both located in Huntsville, AL. Link: https://www.ardc.net/grantee-update-visiting-the-signals-museum-and-the-vba…
Have a great weekend and 73!
Rebecca
KO4KVG
Hello, I made an Allocation Request /24(BGP) on 7 Oct. and received a normal response via email.
I sent the ISP information for the announcement and my identity verification documents on Oct. 9th,
but did not receive a response, so I sent the information again on Nov. 1st, and still haven't received a reply from ardc.
I'm not sure if the information was sent to the authorities or not. How can I track the status?
73
E25RJL