anthropics
Improve firewall to avoid affecting existing iptables rules
This patch enhances the firewall configuration by adopting a more targeted approach with custom chains (CLAUDE_INPUT, CLAUDE_OUTPUT, CLAUDE_FORWARD) rather than flushing all existing IPtables rules. This strategy prevents disruption to other services, such as Docker, that depend on iptables. The patch additionally introduces support for VS Code and Cursor by incorporating necessary domains and Azure IP ranges for the VS Code Marketplace. Further improvements include enhanced error handling, more thorough logging, detection of network interfaces, and support for AWS S3 IP ranges. The script now gracefully manages failures instead of exiting completely, making it more resilient in diverse environments.
This is looking good. Can you clarify what specific functionality is enabled by the vscode / cursor whitelisting? I don't have a don't have a ton of experience with devcontainers.
Can you clarify what specific functionality is enabled by the vscode / cursor whitelisting? I don't have a don't have a ton of experience with devcontainers.
Whitelisting the VSCode and Cursor domains in the devcontainer configuration allows marketplace access from within the containerized development environment. Specifically, when running Claude-code in a remote environment and connecting through VSCode or Cursor, these whitelisted domains (such as marketplace.visualstudio.com and update.code.visualstudio.com) enable the editor to:
- Download and install extensions from the official marketplace
- Verify extension signatures and integrity
Without these whitelisted hosts in your devcontainer.json configuration, the firewall blocks access and prevents the IDE from functioning as intended.
For context, I work at Gitpod, where we develop remote environments https://www.gitpod.io/blog/introducing-gitpod-flex
@aledbf do you think you'll have a chance to address the above feedback? Thanks again for the PR and the discussion!
@ant-kurt, I apologize for the delay. This isn't the right approach. It's too limiting, static, and invasive on the machine. I have another branch using a proxy with a whitelist text file. All HTTPS traffic from the devcontainer is forced to use the proxy, and with that, we can specify FQDNs (which provides redirect support and not just static IPs). Any update to the txt file reloads the proxy (that allow us me to extend the defaults without changing scripts or firewall rules)
@aledbf ACK and thanks for the update, appreciate you bearing with us on the churn on this issue. Out of curiosity, is your branch doing something like running a docker-compose with a proxy container? We have used configurations like this for testing, and may bring that to the devcontainer if there's a desire for it.
I'll go ahead and close this PR. This has been a great discussion - appreciate your time and thoughts, and we hope you'll contribute again!