I am attempting to get connected from VyOS, and I seem to have several
pieces in place, but I am not able to ping any hosts across any IPIP
tunnels.
I can ping amprgw.ucsd.edu across the public Internet. I have configured a
`tun44` interface. I have ampr-ripd running, and it receives updates every
five minutes. The resulting routes appear in my routing table, and if I do
`ip route get` on 44-net hosts, it shows them routing through my `tun44`
interface. But if I try to ping 44-net hosts or access them at all, I get
timeouts.
What might I be missing?
My gateway public IP is 155.138.247.113. My allocated subnet is
44.31.64.1/27.
I created a firewall group named ALLOW-ALL with a default rule set to
'accept' just to rule that out for troubleshooting.
Tunnel interface configuration:
tunnel tun44 {
> address 44.31.64.1/32
> description AMPRNET
> disable-link-detect
> encapsulation ipip
> firewall {
> in {
> name ALLOW-ALL
> }
> local {
> name ALLOW-ALL
> }
> out {
> name ALLOW-ALL
> }
> }
> mtu 1450
> multicast enable
> remote 0.0.0.0
> source-address 155.138.247.113
> }
ampr-ripd startup output:
root@vyos:/home/vyos# ampr-ripd -svd -i tun44
> Using metric 0 for routes.
> Using TCP window 840 for routes.
> Using routing table 'main' (254).
> Loaded 738 entries from /var/lib/ampr-ripd/encap.txt
> Max list size: 1000 entries
> Detected tunnel interface address: 44.31.64.1
> Interface detected: lo, IP: 127.0.0.1
> Interface detected: eth0, IP: 155.138.247.113
> Interface detected: tunl0, IP: 0.0.0.0
> Interface detected: tun44, IP: 44.31.64.1
> Assigned tunnel interface index: 5
> Local IPs:
> 127.0.0.1
> 155.138.247.113
> 44.31.64.1
> Using gateway 155.138.246.1 for direct 44net endpoints via interface eth0.
> Setting routes (738).
> Creating multicast RIP UDP listening socket.
> Setting up multicast interface.
> Waiting for RIPv2 broadcasts...
>
Broadcasts eventually start appearing.
Before I run ampr-ripd, here's the route I get for 44.0.0.1 — over the
public Internet:
44.0.0.1 via 155.138.246.1 dev eth0 src 155.138.247.113 uid 0
And I can ping 44.0.0.1 in this state.
After I run ampr-ripd, here's the route to 44.0.0.1 — over the tunnel:
44.0.0.1 via 169.228.34.84 dev tun44 src 44.31.64.1 uid 1003
And I can no longer ping 44.0.0.1 — it just times out:
vyos@vyos:~$ ping 44.0.0.1 interface tun44
> PING 44.0.0.1 (44.0.0.1) from 44.31.64.1 tun44: 56(84) bytes of data.
> ^C
> --- 44.0.0.1 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 88ms
This is all on VyOS 1.3 equuleus (Debian buster), hosted at Vultr.
Any ideas, or other troubleshooting suggestions?
Thanks very much!
It would be most helpful if the amprnet BOD could post in writing an
official statement regarding using common secure communications (https. TLS
etc.) over the 44. IP network.
This email list is used for communications regarding the use of the IP
address space. I'm not asking about the use of encryption over part 97 RF
radio, just the 44 network IP address space. I am not aware of any portion
of the Part 97 rules that apply to the wired internet at large.
Everyone has an opinion, but it's time for the amprnet Board to clarify the
muddy waters around the use of the amprnet IP space and publish those rules.
Please!
73,
Kevin Walsh
W8KHW
>
> Thanks for sharing. I see this has been around a while, but I hadn’t run
into it myself yet.
Apple is currently doing something like this with IPSEC and IPv6 for iCloud
users; pretty much any iCloud user is always on a private VPN with all
their other iCloud devices. And there are commercial enterprise SD-WAN
products and cloud providers that offer a similar approach for SMBs and
branch offices. Azure and AWS offer almost exactly this between virtual
networks, data centers, and regions, down to the private ASNs.
It’s nice to see a project built on open standards for the express purpose
of playing with it and learning about it. Seems very much like something
44net could benefit from studying carefully.
From: KUN LIN <dnwk(a)linkun.info>
> To: "44net(a)mailman.ampr.org" <44net(a)mailman.ampr.org>
> Cc:
> Bcc:
> Date: Thu, 2 Dec 2021 18:48:49 +0000
> Subject: [44net] DN42 for 44net?
>
>
> https://dn42.dev/Home
>
> Just discover this new thing where it will create mesh networks and even
> BGP via VPN tunnels. This maybe an interesting way for 44net to considering
> implement.
>
> dn42 is a big dynamic VPN<
> https://en.wikipedia.org/wiki/Virtual_private_network>, which employs
> Internet technologies (BGP<https://en.wikipedia.org/wiki/Bgp>, whois
> database, DNS<https://en.wikipedia.org/wiki/Domain_Name_System>, etc).
> Participants connect to each other using network tunnels (GRE<
> https://dn42.dev/howto/GRE-on-FreeBSD>, OpenVPN<
> https://dn42.dev/howto/openvpn>, WireGuard<
> https://dn42.dev/howto/wireguard>, Tinc<https://dn42.dev/howto/tinc>,
> IPsec<https://dn42.dev/howto/IPsec-with-PublicKeys>) and exchange routes
> thanks to the Border Gateway Protocol. Network addresses are assigned in
> the 172.20.0.0/14 range and private AS numbers are used (see registry<
> https://dn42.dev/services/Whois>) as well as IPv6 addresses from the
> ULA-Range (fd00::/8) –
>
>
>
