Modified NAT setup to work reliably with libvirtd

[ghost]

Ted,
Thanks for this very useful piece of code. I'm using it to punch holes from a guest VM out to the 'public' network. Libvirtd sets up a private RFC1918 network for these VM's then creates iptables rules to restrict direct access in to the VM's, and NAT so the guests can get out. Currently the rules in natpmd.action don't work in this setup. This is partly because the rules are appended and are never reached, and partly due to problems with the FORWARD chain rule not matching. This change not only inserts them but changes the FORWARD chain rule to use the DNAT connection tracking state. It works well and I think would work in more diverse setups than the original.
Regards
Nick
PS. I also wrote a Ruby Gem (natpmp) to control this feature. It's up on github and rubygems too.

[tedjp]

I'm using it to punch holes from a guest VM out to the 'public' network.

I never even thought of using it for that! Glad it's still useful 😄

Currently the rules in natpmd.action don't work in this setup. This is partly because the rules are appended and are never reached,

This was originally a design decision to avoid pre-empting any rules created by the sysadmin. I see that libvirtd is putting its own ACCEPT rule at the top of the FORWARD table. I'll have to think about it, because I still don't want Stallone overriding any manually-entered forwarding rules, but it should also work with libvirtd by default.

and partly due to problems with the FORWARD chain rule not matching.

Do you know what wasn't matching with the existing rule, even when it's first?

PS. I also wrote a Ruby Gem (natpmp) to control this feature. It's up on github and rubygems too.

Cool! The testclient in Stallone is usable for adding and removing mappings. I never got around to tidying up its interface and installing it. I like the way your Ruby Gem can set up the mapping for the lifetime of the process.