Is your proposal related to a problem?
In the current NAT implementation when using a standard docker bridge, a VM can communicate with any other VM using its docker bridge IP. However, the VM cannot communicate with itself via its own docker bridge IP. This was confusing as a normal docker container can communicate with its own bridge IP, but after some research I learned this was due to lack of a NAT hairpin configuration: https://en.wikipedia.org/wiki/Network_address_translation#NAT_hairpinning
Describe the solution you'd like.
Add NAT hairpinning configuration to the configureNAT function in network.sh. Either for all VMs or to restrict the default behavior, require an environment variable like NAT_HAIRPIN=y for configuration.
I'm not very experienced with iptables myself, so I leveraged AI to create a fix, which I have tested and verified as working. I can provide the solution if requested, but its probably much better for the maintainer @kroese to come up with a solution rather than submit an AI generated PR.
Describe alternatives you've considered.
Split horizon DNS could work, but requires extra configuration within the guest VM. Macvlan is also a solution, but that is not ideal for restricted networks or avoiding IP allocations on the host network if you have a large number of VMs.
Additional context
No response
Is your proposal related to a problem?
In the current NAT implementation when using a standard docker bridge, a VM can communicate with any other VM using its docker bridge IP. However, the VM cannot communicate with itself via its own docker bridge IP. This was confusing as a normal docker container can communicate with its own bridge IP, but after some research I learned this was due to lack of a NAT hairpin configuration: https://en.wikipedia.org/wiki/Network_address_translation#NAT_hairpinning
Describe the solution you'd like.
Add NAT hairpinning configuration to the configureNAT function in network.sh. Either for all VMs or to restrict the default behavior, require an environment variable like
NAT_HAIRPIN=yfor configuration.I'm not very experienced with iptables myself, so I leveraged AI to create a fix, which I have tested and verified as working. I can provide the solution if requested, but its probably much better for the maintainer @kroese to come up with a solution rather than submit an AI generated PR.
Describe alternatives you've considered.
Split horizon DNS could work, but requires extra configuration within the guest VM. Macvlan is also a solution, but that is not ideal for restricted networks or avoiding IP allocations on the host network if you have a large number of VMs.
Additional context
No response