@here While working on fixing the 0.0.0.0/0 gateway issue, I discovered a very simple workaround that should work for most scenarios. This is the list of all public CIDR's, excluding the RFC1918 private address space (private address ranges like 192.168.X.X, 10.X.X.X): 0.0.0.0/5,8.0.0.0/7,11.0.0.0/8,12.0.0.0/6,16.0.0.0/4,32.0.0.0/3,64.0.0.0/2,128.0.0.0/3,160.0.0.0/5,168.0.0.0/6,172.0.0.0/12,172.32.0.0/11,172.64.0.0/10,172.128.0.0/9,173.0.0.0/8,174.0.0.0/7,176.0.0.0/4,192.0.0.0/9,192.128.0.0/11,192.160.0.0/13,192.169.0.0/16,192.170.0.0/15,192.172.0.0/14,192.176.0.0/12,192.192.0.0/10,193.0.0.0/8,194.0.0.0/7,196.0.0.0/6,200.0.0.0/5,208.0.0.0/4 All you have to do is copy/paste this list in the "egress gateway ranges" when creating a gateway and it will function like a regular VPN gateway. I'd like to get your thoughts on if this is a viable solution for those looking to use netmaker as an "internet gateway". Benefits are, you avoid mangling routes locally and having to deal with more complex logic. This is especially important on Kubernetes, where there are a ton of routing rules going on. Cons are, this can potentially leaves out many corner cases when you need to reach special address spaces. It also does not work if you want to route all traffic (including private subnet traffic) through the VPN, though typically this is not the intention anyway. If this is considered a viable solution, we can add it to the docs, and maybe add a button in the UI to fill in these values automatically.