feature request: implement 1:1 NAT support

knoflook commented

2022-04-07 15:55:53 +00:00

while setting up a test instance of capsul we had to set up 1:1 NAT because our provider didn't give us a subnet, only a couple of discrete IP addresses. It would be great if capsul could figure this situation out and give the right IP address in the web interface.

forest commented

2022-04-11 19:59:57 +00:00

Owner

Thanks for raising this issue, to be honest I don't know what a 1:1 NAT is or what this feature would entail. Could you please post a more in-depth explanation of what this is or what it would look like? Even just links to documents that explain what a 1:1 NAT is would help.

knoflook commented

2022-04-19 11:17:12 +00:00

Author

Ah yes, sorry for being so cryptic about it, i put this text with the intent to edit it later :) I don't have a deep understanding of this topic either, so what I say might be simplified or not 100% correct, but with that said, a 1:1 NAT is used in this context to map x public IP addresses to x local IP addresses with all ports passed trough.

Normally this doesn't need to be done, because your ISP will typically give you a subnet which you then put into libvirtd so it can give these addresses to VMs. So when you go to look at your capsuls you'll be able to see the public IP address that you can SSH to.

In our case however, we (servers.coop) went for an extremely cheap dedicated server provider for our test instance which didn't give us a subnet, but a bunch of discrete IP addresses with the last octet 124-129 and a /24 netmask. If I understand correctly it's impossible to configure libvirt to use discrete IP addresses, so we had to map each of these to a local subnet 10.0.0.{4,9}. This is done in the PREROUTING chain in nat table in iptables. Unfortunately this means that the VM doesn't know its public IP address, and capsul also shows 10.0.0.x.

So in this case it would be great to have an option to replace these addresses in the web interface with the public ones by either putting the mapping range in manually or allowing capsul to read iptables. It's possible that we'll either find a better way to deal with these IP addresses (and then document it properly), or write this feature ourselves and open a PR here.

Ah yes, sorry for being so cryptic about it, i put this text with the intent to edit it later :) I don't have a deep understanding of this topic either, so what I say might be simplified or not 100% correct, but with that said, a 1:1 NAT is used in this context to map `x` public IP addresses to `x` local IP addresses with all ports passed trough. Normally this doesn't need to be done, because your ISP will typically give you a subnet which you then put into libvirtd so it can give these addresses to VMs. So when you go to look at your capsuls you'll be able to see the public IP address that you can SSH to. In our case however, we (servers.coop) went for an extremely cheap dedicated server provider for our test instance which didn't give us a subnet, but a bunch of discrete IP addresses with the last octet 124-129 and a /24 netmask. If I understand correctly it's impossible to configure libvirt to use discrete IP addresses, so we had to map each of these to a local subnet `10.0.0.{4,9}`. This is done in the `PREROUTING` chain in `nat` table in iptables. Unfortunately this means that the VM doesn't know its public IP address, and capsul also shows `10.0.0.x`. So in this case it would be great to have an option to replace these addresses in the web interface with the public ones by either putting the mapping range in manually or allowing capsul to read iptables. It's possible that we'll either find a better way to deal with these IP addresses (and then document it properly), or write this feature ourselves and open a PR here.

forest commented

2022-05-01 00:47:12 +00:00

Owner

Gotcha. This might fit in with a refactor i had planned for the future, moving towards manually managing all of the IP address allocations instead of letting the DHCP server allocate them

feature request: implement 1:1 NAT support #35