Gateway NAT & Internet Access

A Gateway node connects your private fabric to the public internet. Tenant workloads sit on a private LAN subnet whose addresses are not routable on the internet, while the Gateway node holds a WAN uplink with a public IP. Gateway NAT rewrites addresses as traffic crosses that boundary, so a whole tenant subnet can reach the internet over one shared public IP and so you can publish internal services on it.

All translation happens in the Gateway's in-kernel data plane — the same place firewall and routing decisions are made — so there is no user-space proxy in the path. It is a software data plane; treat throughput as workload-dependent rather than assuming any fixed line rate.

Gateway NAT is opt-in. With no rules in place, source NAT is off and the data path is unchanged, so you enable internet access one subnet at a time.

Masquerade (shared public IP)

Masquerade (source NAT) lets an entire private LAN subnet reach the internet through a single public IP. When a tenant on the subnet opens an outbound connection, the Gateway rewrites the packet's source address to the WAN interface's IP and tracks the flow; replies arriving at that public IP are translated back to the original tenant. TCP, UDP, and ICMP echo (ping) are all masqueraded.

Add a rule by giving the LAN subnet as a CIDR and the WAN egress interface:

sudo cenvero-str-ctl gateway snat add 10.50.0.0/24 --wan cnv-nic-0

The public IP is taken from the WAN interface itself, so you name the interface rather than an address. The response confirms the stored rule:

{
  "status": "added",
  "id": 1,
  "type": "snat",
  "source_cidr": "10.50.0.0/24",
  "interface": "cnv-nic-0"
}

List the NAT rules in place — this shows both masquerade rules and any published port-forwards:

cenvero-str-ctl gateway snat list

{
  "nat_rules": [
    {
      "id": 1,
      "type": "snat",
      "source_ip": "10.50.0.0/24",
      "interface": "cnv-nic-0"
    }
  ]
}

Remove a rule by its id:

sudo cenvero-str-ctl gateway snat remove 1

With no masquerade rule, outbound tenant traffic is not translated. Add one rule per LAN subnet you want to give internet access.

Hairpin NAT (reaching your own public IP)

Hairpin NAT (also called NAT loopback) handles the case where a tenant on the LAN reaches one of your own published services by its public address. Suppose you publish an internal service on the Gateway's public IP, and a client on the same LAN connects to that public IP instead of the internal address. Without hairpin, the server's reply would return straight to the client without passing back through the Gateway, and the connection would break.

With hairpin, the Gateway rewrites both ends of the forward packet: the destination is translated to the internal host (as with any published service), and the source is translated to the Gateway's own LAN address. The reply then comes back to the Gateway, which reverses both translations, so the client sees a consistent, working conversation.

Hairpin is automatic — there is no separate command. For IPv4 it engages when:

a masquerade rule covers the LAN subnet (this is what tells the Gateway its own address on that subnet), and
the client and the published service's target host are both on that subnet.

If there is no masquerade rule for the subnet, a published service still works normally from outside; only the same-subnet loopback case relies on hairpin. Hairpin NAT is IPv4 only. See the API reference for publishing a service with a port-forward rule.

NAT64 (IPv6-only clients)

NAT64 lets an IPv6-only tenant reach an IPv4-only service on the internet. The client sends traffic to an IPv4 destination embedded in the well-known NAT64 prefix 64:ff9b::/96; the Gateway translates the IPv6 packet to IPv4 (sourced from a shared IPv4 pool address) and translates the reply back to IPv6. This covers TCP and UDP.

NAT64 is off by default. Turn it on by first configuring an IPv4 pool address, then enabling it:

sudo cenvero-str-ctl nat64 configure 203.0.113.10
sudo cenvero-str-ctl nat64 enable

The pool address is the public IPv4 address that translated flows are sourced from. To use a prefix other than the well-known one, pass it as a second argument:

sudo cenvero-str-ctl nat64 configure 203.0.113.10 64:ff9b::/96

Check the current state and the number of active flows:

cenvero-str-ctl nat64 status

{
  "enabled": true,
  "prefix": "64:ff9b::/96",
  "v4_pool": "203.0.113.10",
  "active_bindings": 0,
  "scope": "TCP/UDP (ICMP + fragmentation not translated)"
}

Disable it to return the Gateway to its previous behavior:

sudo cenvero-str-ctl nat64 disable

NAT64 translates TCP and UDP. ICMP and fragmented datagrams are passed through untranslated rather than dropped. IPv6-only clients typically rely on a DNS64 resolver to synthesize 64:ff9b:: addresses for IPv4-only names; DNS64 is a resolver function and is configured separately from the Gateway.

ICMP / ping

Tenants behind a masquerade rule can ping IPv4 hosts on the internet. ICMP echo requests are source-NATed to the WAN IP alongside TCP and UDP, and the matching echo replies are translated back to the originating tenant, so ordinary ping connectivity checks work through the Gateway.

This covers ICMP echo (ping) only. It rides on the same masquerade rule — there is no separate command to enable it — so as soon as a subnet has a masquerade rule, its tenants can ping out. ICMP error messages are not translated.

Command reference

Mutating commands require root, so prefix them with sudo; the read-only list and status commands do not.