<div dir="ltr">Hi!<div><br></div><div>From a operator point of view, I think that it would be nice to give to the FWaaS (IPv4 flavor), the ability to manage the tenant's NAT table, not only the "filter table", as it is today.</div>

<div><br></div><div>If fact, I don't know if it is out of the scope of FWaaS or not, it is just an idea I had. Because right now, I need to create the so called "NAT Instance", with a Floating IPv4 attached to it, with a DNAT rule for each "internal" service that I need to open to the Internet... It is terrible BTW but, it is the "IPv4-thinking"... (Can't wait for IPv6 in IceHouse to kiss NAT goodbye!)... Today, each tenant must have at least, two valid IPs (v4), one for the router's gateway and another to the "NAT Instance" (because FWaaS (or something else) doesn't handle the Tenant Router/Namespace NAT table).</div>

<div><br></div><div>So, if the Tenant can manage its own Firewall-IPv4-NAT table, there at its own Namespace Router, then, each will require only 1 valid "Floating IPv4", the one that come when he connects its router, with the External Network (from allocation pool anyway)... Less waste of valid IPv4.</div>

<div><br></div><div>Regards,</div><div>Thiago</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 8 January 2014 13:36, Dong Liu <span dir="ltr"><<a href="mailto:willowd878@gmail.com" target="_blank">willowd878@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>在 2014年1月8日，20:24，Nir Yechiel <<a href="mailto:nyechiel@redhat.com" target="_blank">nyechiel@redhat.com</a>> 写道：</div>

<div><div class="h5"><br><blockquote type="cite"><div style="font-family:verdana,helvetica,sans-serif;font-size:12pt"><div>Hi Dong,<br></div><div><br></div><div>Can you please clarify this blueprint? Currently in Neutron, If an instance has a floating IP, then that will be used for both inbound and outbound traffic. If an instance does not have a floating IP, it can make connections out using the gateway IP (SNAT using PAT/NAT Overload). Does the idea in this blueprint is to implement PAT on both directions using only the gateway IP? Also, did you see this one [1]? <br>

</div><div><br></div><div>Thanks,<br></div><div>Nir<br></div><div><br></div><div>[1] <a href="https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding" target="_blank">https://blueprints.launchpad.net/neutron/+spec/router-port-forwarding</a><br>

</div></div></blockquote></div></div></div><br><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">I think my ide</span><span style="font-size:14px">a is </span><span style="line-height:18px;color:rgb(51,51,51);font-size:14px;font-family:sans-serif">duplicated</span><span style="font-size:14px"> with this one. </span><a href="https://blueprints.launchpad.net/neutron/+spec/access-vms-via-port-mapping" style="font-size:14px" target="_blank">https://blueprints.launchpad.net/neutron/+spec/access-vms-via-port-mapping</a></div>

<div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">Sorry for missing this.</span></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>