The platform does not route between private networks and does no NAT, so if you want a routed private estate you build the router yourself. That is a supported pattern, and there is a plan sized for it.
The plan
no.appliance: 1 vCPU, 512 MB RAM, 10 GB disk, 10 Gbps port, at the
bottom of the price list. Enough for a firewall VM doing NAT and VPN for a
handful of servers. Use a larger plan if you want IDS, heavy VPN throughput or
lots of state.
Keep the public IPv4 on for the appliance. It is the WAN.
pfSense and OPNsense usually need a custom ISO
They are not stock cloud images. Open a ticket and ask for the image you need. VyOS is more cloud-friendly.
Build order
Doing this out of order means redoing it.
- Create the private networks first. One for LAN, one per additional segment. Leave every gateway blank for now, because the addresses do not exist yet.
- Deploy the appliance with a public IPv4. Attach the LAN network, then any others. Attachments land on successive NICs, so the order you attach them is the order the guest sees them.
- Configure the guest. Assign WAN to the public NIC and LAN or OPT to each private NIC. Set MTU 1450 on every private interface. Set up NAT, DHCP, and any VPN inside the guest.
- Set each network's gateway to the appliance's address on that network. Cloud-init then hands other members that gateway automatically.
- Reboot the members so they pick up the new gateway.
Members behind it
For members that should get their address from the appliance's DHCP, turn cloud-init static assignment off on the attachment. For members you want pinned, leave it on and pick the address yourself.
Members can be private-only: with the appliance doing NAT they still reach the internet, and they are unreachable from it.
Traffic between two private networks
Only moves if the appliance forwards it. Both networks must be attached to the appliance, both must point their gateway at it, and it must have a rule permitting the traffic. There is no platform route.
Checklist when it does not work
- MTU 1450 set on private interfaces inside the guest?
- Members rebooted after the gateway was set?
- The appliance's own firewall allowing the traffic?
- WAN interface assigned to the right NIC? The public NIC is the first one.
- Anti-spoofing: the appliance can only source traffic from its own allocated addresses, so NAT has to translate to its public address, not to something invented.