All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
PSA: RackNerd ctrl Firewall is stateless and may block outbound UDP replies
A quick PSA for anyone using RackNerd's new ctrl Network Firewall.
I found that it can block replies to UDP connections initiated by the VPS.
My test was simple:
- UFW enabled and unchanged throughout.
- ctrl firewall enabled.
- Outbound DNS had packets going out and replies coming back.
- Another outbound UDP flow using a dynamic local source port had packets going out, but no replies reached the VPS.
- Explicitly allowing that temporary local port in ctrl, or disabling ctrl entirely, immediately restored the replies.
RackNerd escalated the ticket and checked with the ctrl developers. Their final explanation was:
- ctrl is intentionally a stateless inbound port filter.
- It does not generally track outbound-initiated UDP sessions.
- Replies to dynamic local UDP ports are dropped unless that port is explicitly allowed.
- DNS replies from TCP/UDP source port 53 are hardcoded exceptions.
- NTP replies from UDP source port 123 are also exceptions.
- For general stateful UDP, users should disable ctrl and use UFW/nftables/iptables instead.
So this is not a bug. It is an intentional limitation.
Stateless ACLs are perfectly valid, but I find the current naming and documentation misleading. "Network Firewall" sounds like the stateful cloud firewalls offered by most major providers, where matching replies to outbound connections are automatically allowed.
At minimum, the ctrl panel should clearly state:
"Stateless inbound port filter. General UDP return traffic is not automatically tracked. DNS and NTP replies are special exceptions."
Ideally, RackNerd could add an optional stateful mode. Otherwise, calling it a "Stateless Network ACL" would set much clearer expectations.
For now, if your VPS uses outbound UDP with dynamic local source ports:
- Disable the ctrl Network Firewall.
- Keep UFW/nftables/iptables enabled.
- Use default-deny inbound and allow established/related return traffic.
To RackNerd's credit, support checked with the developers, clearly confirmed the behavior, and agreed that the documentation should be improved.
@dustinc, any chance ctrl could eventually support optional stateful connection tracking, or at least show a prominent stateless warning before users enable the firewall?
- Add optional stateful TCP/UDP connection tracking12 votes
- Keep it stateless, but rename it to “Network ACL”16.67%
- Keep the current name, but clearly document the limitation and DNS/NTP exceptions0.00%
- Offer both stateless and stateful modes16.67%
- No change needed, just use the OS firewall16.67%
- I don't use the ctrl firewall / just here for the popcorn 🍿50.00%
Comments
Jeez the title read like deepseek infused MJJ drama, the wall of text looked like MJJ drama, but this was actually informative and interesting. Refreshing!
Hi @VGL, Thank You for the feedback! Glad our support team was able to clarify this for you. As mentioned, the ctrl Network Firewall is optional and disabled by default. Feedback has been quite positive, with customers appreciating the additional layer of protection, and we’ll continue improving it and adding additional capabilities.
Since launching last month, ctrl has been very well received by our customers and the community, which we’re happy to see. We appreciate feedback like this by the way! Because ctrl is our own proprietary software and we are no longer tied to the decisions or roadmap of a third party software vendor, we’re continuing to build on ctrl, and making sure the existing features are clearly understood is part of that effort too 👊
Hi @fredo1664 -- Yep! @VGL has been around LET long enough, and has contributed some great feedback/activity on the AdminBolt thread too: https://lowendtalk.com/discussion/221872/giveaway-by-adminbolt-racknerd-100x-free-vps-for-a-year-20x-lifetime-licenses-lets-talk/
We appreciate him taking the time to share his experience here as well. I'd say he's part of the #RackNerdGang -- let's goooo!
Isn't the dynamic local ports irrelevant and it's outgoing UDP besides NTP/DNS being prevented the actual point? If you have intentional inbound traffic, make a rule. Otherwise, UDP besides DNS/NTP isn't going to work without a rule and that's for inbound service.
Why don't you just configure the firewall from the OS?
Thanks @dustinc, appreciate the response and the support team checking this with the developers.
I agree the feature can still be useful as an additional inbound ACL. My main suggestion is simply to label its stateless behavior and the DNS/NTP exceptions clearly in ctrl, so users know what to expect before enabling it.
Looking forward to seeing how ctrl develops 👊
The dynamic local port is actually the key detail here.
The outbound UDP packet is not blocked. Packet capture shows it leaving the VPS normally. The matching reply is sent back to the same ephemeral local port, where ctrl treats it as ordinary inbound traffic and drops it because that port is not on the allow list.
So the issue is not outgoing UDP being blocked. It is the matching inbound reply being dropped because the firewall does not track the outbound UDP flow.
I agree that an intentional inbound UDP service should have a fixed inbound rule. This case is different: the VPS is acting as the UDP client, and the operating system dynamically selects an ephemeral local source port. The remote endpoint sends its reply back to that same port.
DNS and NTP work only because RackNerd confirmed that replies from source ports 53 and 123 are explicit exceptions.
I do use UFW, but that is not quite the same thing.
The ctrl firewall is supposed to filter traffic before it reaches the VPS, while UFW runs inside the guest after the traffic has already arrived. They should ideally provide two separate security layers.
Using UFW solves the connectivity problem, but disabling ctrl also means giving up the provider-side filtering layer. That trade-off is exactly why I raised the issue.