Yggdrasil opens a computer causing other Yggdrasil users to become kind of LAN peers

[slrslr]

Services running on a home computer behind NAT are not usually exposed to internet users/peers, but only to LAN peers. Enabling Yggdrasil in its default configuration exposes the services to all Yggdrasil peers like if they are in same LAN.

Can this behavior be changed so by default this does not happen and user needs to manually expose ports to Yggdrasil?

How to fix this inside the /etc/yggdrasil/yggdrasil.conf ? My current Linux iptables (sudo iptables -S INPUT) contains:

-P INPUT ACCEPT
...
-A INPUT -i tun+ -j ACCEPT
...
-A INPUT -j DROP

i wanted to have these rules, because OpenVPN also is using tun interface, if I am not mistaken.

To me (a layman) i would expect some clear warning on a prominent place of a Yggdrasil site, wiki/docs, that mine mentioned "issue" will happen upon starting Yggdrasil and examples on how to prevent that.

[majestrate]

for your specific firewall configuration, changing yggdrasil to use interface ygg0 would solve this issue since both openvpn and yggdrasil are racing to make a tun interface with the default naming scheme (tun+).

when setting up network level services this is a well defined issue, documenting it for the lay man would help sure but there is a lot of prerequisite knowledge you are expected to either know or pick up along the way and we're not a networking/sysadmin course. we can't cover it all for the layman.

[slrslr]

On a different, not modified Debian 13:

cat /etc/*vers*
13.2

sudo sysctl -a|grep forw|grep -E "= 1|=1"
net.ipv4.ip_forward_update_priority = 1

and i always seen default policy ACCEPT in iptables.

On a fresh Debian install the default policy for all native Netfilter chains (INPUT, OUTPUT, FORWARD) is ACCEPT. That means traffic on tun0 (or any other interface) will be allowed (enabling issue mentioned in this topic.

When you install Openvpn/Wireguard to become client of a VPN server, i do not think that it exposes your services by default, but Yggdrasil does without warning.

---

Changing "IfName: auto" to "IfName: ygg0" in /etc/yggdrasil/yggdrasil.conf and "sudo systemctl restart yggdrasil" changed the interface, but what is next?

sudo ip6tables -I INPUT 1 -d "MyYggPublicAddress" -m conntrack --ctstate NEW -j REJECT
sudo ip6tables -I INPUT 2 -d "MyYggPublicAddress" -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Started refusing connection to ports as i wanted. Rejecting just ygg0 interface not worked, possibly because "sudo ip -6 route get MyYggPublicAddress" contained no ygg0, but lo: "from :: dev lo table local"
which i had accepted in INPUT and OUTPUT chains.

Setting the protection from this "insecure by default" behavior is difficult if not impossible for a layman, and it should not be IMO @neilalexander .

[slrslr]

@majestrate

[majestrate]

When you install Openvpn/Wireguard to become client of a VPN server, i do not think that it exposes your services by default, but Yggdrasil does without warning.

This is because most openvpn/wireguard configurations utilize NAT on a private range whereas with yggdrasil you get a "publicly routable" address. yggdrasil shouldn't be sending traffic with spoofed source on your box either as that's like, the entire point of it.

People choose yggdrasil for this as it's a feature, not a bug. Any firewall rules depend on the end user's threat model, there is no one size fits all solution here and shipping an extra zealous firewall to appease some vocal minority is a major turnoff for existing use cases.

Please note: This is not a production network, it's a research project, please understand what you are asking before asking. We're NOT going to ship you a firewall policy, that's YOUR job.

A production network would have yggdrasil on a network appliance with sane defaults, the project is not at that phase.

Patches welcome.

[slrslr]

Thanks @majestrate , your post was not helpful to avoid the described insecurity and since no one bothered to provide iptables rule/s (possibly not helpful just for me, but future visitors) to address/avoid this insecurity, i have disabled Yggdrasil on my home computer and warned others not to use it (describing the reason).

[neilalexander]

FYI we have had example rules on https://yggdrasil-network.github.io/faq.html#will-my-machine-be-exposed-to-other-users-of-the-network for a very long time now.

[neilalexander]

It's not as simple as just "changing the behaviour", the only two options for fixing this problem are:

1. Embedding an entire IP stack which acts as a gateway in front of your host, which is effectively what Yggstack does (we do not want this level of complexity in the mainline Yggdrasil distribution though);
2. Hooking the firewall ourselves, which isn't portable across platforms, may surprise users and could conflict with other software that manages the firewall.