This message was deleted.
# k3s
a
This message was deleted.
g
Are you by any chance using Hetzner "firewall" for robot servers ? It is NOT statefull and could be causing this..
b
I am.... I don't want to allow any ingress to these servers so it seemed prudent. But it sounds like I shot myself in the foot there?
g
That is the main reason why I dropped k3s om robot servers ! They are implemented as simple switch ACL's and you can only have 10 of them. Try disabling the rules to determine if this is the main reason...
Long story short : Normally you would create rules to allow traffic to empheral ports in your hetzner "firewall". To see your empheral ports :
Copy code
sysctl net.ipv4.ip_local_port_range
However - IPTABLES does NOT honor this setting and will assign source ports in any random range. This prevents us from creating effective rule with kubernetes in Hetzner robot country 😞
Ugly workaround : Create rules like this 1 : Allow any traffic from your ip 2: Allow between internal (vswitch) networks - i.e. 10.0.0.0/8 3: Drop traffic to SSH 4: Drop traffic to 6443 5: Drop traffic to 10250 6: Drop traffic to 9100 ( if using node-exporter ) 7: Drop traffic to any other services 8: Allow all
b
Right now my incoming rules are:
(ssh template with an allow all from the private network ips)
And outgoing is simply:
Could that really be stopping outgoing data from the pods?
g
And that works nicely if NOT using iptables. Rule 3 normally allows the return traffic - but iptables are picking ports below 32768
No - it stops the return traffic
You can verify by connecting to a host with tcpdump from any pod
b
Damn, i had forgotten how primitive a non-stateful firewall is.
g
true !
And combining this with iptables not complying to the default settings does not make it any better
Found it 🙂
b
You are a life-saver, thank you very much. Its probably too late in the day for me to mess with firewall routes, but tomorrow I will give it a go. You have saved me so much frustration.
g
You're welcome.