This message was deleted.

This may be of interest to @ambitious-plastic-3551 and @creamy-pencil-82913 (both tried to help figure it out). It may also be a very illusive because I've found multiple people who had the same symptoms I had on the issue tracker and they folded (unable to find the problem). I believe now that one area of investigation on those problems is the default routes.

k3os had this issue when I had 2 interfaces one public and one private, and then quit altogether, because default route was put on the wrong interface eth1 instead of eth0

Right, but if there are two default routes, wouldn't it be a bug to have Linux choose one and k3s choose a different one?

This is not really a k3s bug, but rather the network manager (which is some exotic)

so where would a file a bug such that the network manager for k3s is picking a different default route then the one Linux picks?

This is k3os I used, this is not really tied to k3s directly

Right, but I am seeing it on k3s right now, and I've never used k3os. I'm not very aware of the tech that's going on in k3s.

Otherwise default routes are overriden, you could potentially make more "default" routes, if you have multiple IP addresses with different subnets

I don't follow =(

I don't know the specifics of the problem 😄 sorry

It's all on the devops.se link above. Basically, I have three default routes. One gets chosen by Linux and works fine. The other gets chosen by k3s. It's not the same one. It doesn't work. I don't believe k3s should be using a different default route from the host.

iptables -t nat -nvL for masquerade