Redox supports thousands of VPN connections and even more IP addresses within those sets of connections. Typically, VPNs communicate over private IPs to not clash with public IPs. Learn the difference between public and private IPs.
Specifically, Redox uses Network Address Translation (NAT) IPs to ensure that a connection’s IP address doesn’t clash with another. We do this since traffic sometimes passes through the same private IP. Learn about NAT.
Using NAT IPs helps avoid conflicts, but it also results in Redox sending traffic to IPs that might look different from the IP you originally set up to receive traffic. For example, you or your connection might receive data at 10.1.0.0/32, which is a private IP. But we might have two VPN connections that each want to receive traffic at 10.1.0.0/32. As a result, we use NAT IPs to a reserved Redox NAT IP range:
AWS region | NAT IPs |
---|---|
AWS_USA_EAST_1 | 10.153.0.0/16 10.157.0.0/16 10.162.0.0/16 10.155.0.0/16 |
AWS_CAN_CENTRAL | 10.160.0.0/16 |
For example, Destination 1 might send to 10.162.0.0/32 to route to you or your connection at 10.1.0.0/32. Destination 2 might send to 10.162.0.1/32 to route to another customer who also wants to receive traffic at 10.1.0.0/32. This ensures both have a unique destination IP within Redox walls(10.162.0.0/32 for you and 10.162.0.1/32 for them).
The use of NAT IPs is all typically hidden under the hood of our networking infrastructure. However, there are a few instances when you might see them:
- When looking at VPN statuses on the Connections page, you might see NAT IPs in the status. Learn how to check a VPN status.
- When receiving VPN statuses or traffic alert rules, you might see the NAT IP for the affected IP. Learn how to manage alert rules.
- When looking at a failed log error, you might see ECONNREFUSED <NAT IP> or similar. This implies that there was an issue hitting the destination IP (like 10.1.0.0/32 from our example), but from Redox’s viewpoint, it’s a unique NAT IP. Learn about troubleshooting log errors.