Support NAT network out of the box

[lae]

Should remain optional, but for single node installations this could be very useful.

NAT network should be definable (in case user wants to route VMs on two separate NAT-style hosts to one other)

References: https://pve.proxmox.com/wiki/Network_Model#Masquerading_.28NAT.29_with_iptables

[trickert76]

The reference is out-of-date. I think you mean https://pve.proxmox.com/wiki/Network_Configuration#_masquerading_nat_with_tt_span_class_monospaced_iptables_span_tt

I didn't yet get it to work, but maybe because of some restriction from the hosting datacenter. But I've a template for creating the interface for routing. That could be a good idea for a starting point for using MASQ. But I thing I need some "logic" to define the additional internal (or in case of routing) external IPs. The ansible facts cannot identify this details, because it needs to be "defined".

## {{ ansible_managed }}

auto lo
iface lo inet loopback
iface lo inet6 loopback

auto {{ ansible_default_ipv4.interface }}
iface {{ ansible_default_ipv4.interface }} inet static
  address {{ ansible_default_ipv4.address }}
  netmask {{ ansible_default_ipv4.netmask }}
  gateway {{ ansible_default_ipv4.gateway }}
  up route add -net {{ ansible_default_ipv4.network }} netmask {{ ansible_default_ipv4.netmask }} gw {{ ansible_default_ipv4.gateway }} dev {{ ansible_default_ipv4.interface }}

iface {{ ansible_default_ipv6.interface }} inet6 static
  address {{ ansible_default_ipv6.address }}
  netmask {{ ansible_default_ipv6.prefix }}
  gateway {{ ansible_default_ipv6.gateway }}


auto vmbr0
iface vmbr0 inet static
  address {{ ansible_default_ipv4.address }}
  netmask {{ ansible_default_ipv4.netmask }}
  bridge_ports none
  bridge_stp off
  bridge_fd 0
#  up route add <ip1>/32 dev vmbr0
#  up route add <ip2>/32 dev vmbr0

My current idea is to read that additional addresses from the provider API (Hetzner). In case of MASQ this are internal IPs which would be easier, because you can define them in an array in the host or group vars and print them out in the template.

[lae]

They should be defined. The role isn't meant to be specific to any provider, so definition should be taken care of by the user (and they could very well automate definition of the appropriate variables in a playbook, for example).

Thanks for pointing out the broken link (it has been a few years, after all) - there is actually a PVE admin guide separate from the wiki now as well: https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#_masquerading_nat_with_span_class_monospaced_iptables_span