[Openstack] [neutron] Port Forwarding
Martinx - ジェームズ
thiagocmartinsc at gmail.com
Thu Dec 19 22:17:41 UTC 2013
Cool! You're welcome! =)
My topology is "Per-Tenant Router with Private Networks", it does looks
like your first example but, a bit different, like this:
---
Yours:
Internet ---- public-network ---- OpenStack-Router ----
Private-OpenStack-Network ---- NAT-Instance
|
--
Other-Instances
-
Mine:
Internet ---- public-network ---- OpenStack-Router ----
Private-OpenStack-Network ---- NAT-Instance
|
-- Other-Instances
---
The "NAT Instance" is just a regular Instance (plus its Floating IP), there
is nothing "connected behind it" (i.e. no eth0 public / eth1 private), it
is "parallel / side-by-side" to the others Instances, the network traffic
comes in and out the "NAT Instance" trough the same ethernet interface
(another creepy point of this IPv4 topology).
Best,
Thiago
On 19 December 2013 15:31, Abbass MAROUNI <abbass.marouni at virtualscale.fr>wrote:
> Dear Thiago,
>
> Thanks a lot for your answer.
>
> One more thing, do your configuration look something like this :
>
>
> Internet ---- public-network ---- OpenStack-Router ----
> Private-OpenStack-Network ---- NAT-Instance
>
> |
>
> --
> Other-Instances
>
> I tried setting up a dedicated router/firewall but couldn't make to work,
> it looks something like :
>
> Internet ---- public-network ---- OpenStack-Router ----
> Private-OpenStack-Network ---- Dedicated-Router (A VM) ----
> Private-OpenStack-Network-2 ---- Other-Instances
>
>
> For some reason the above configuration fails to deliver the packets to
> the 'Other-Instances', the 'Other-instances' use the Dedicated-Router as
> their gateway. Another drawback is the cloud-init of the 'Other-Instances'.
>
> So I decided to try my luck with the first configuration, but it didn't
> work also. Maybe my iptables for the NAT-Instance were wrong. I'll try
> yours tomorrow !
>
> Thanks a lot,
>
> Best Regards,
>
>
>
> 2013/12/19 Martinx - ジェームズ <thiagocmartinsc at gmail.com>
>
>> Abbass,
>>
>> The only way I figured out to do this, is by creating a "NAT Instance",
>> with a Floating IP attached to it and, the "magic" happens here:
>>
>> Contents of my /etc/network/nat-rules.save
>>
>> ---
>> # Generated by iptables-save v1.4.12 on Fri Oct 18 02:41:35 2013
>> *filter
>> :INPUT ACCEPT [0:0]
>> :FORWARD ACCEPT [0:0]
>> :OUTPUT ACCEPT [0:0]
>> COMMIT
>> # Completed on Fri Oct 18 02:41:35 2013
>> # Generated by iptables-save v1.4.12 on Fri Oct 18 02:41:35 2013
>> *nat
>> :PREROUTING ACCEPT [0:0]
>> :INPUT ACCEPT [0:0]
>> :OUTPUT ACCEPT [0:0]
>> :POSTROUTING ACCEPT [0:0]
>> -A PREROUTING -d 192.168.50.2/32 -p tcp -m tcp --dport 80 -j DNAT
>> --to-destination 192.168.50.11
>> -A PREROUTING -d 192.168.50.2/32 -p tcp -m tcp --dport 443 -j DNAT
>> --to-destination 192.168.50.11
>> -A PREROUTING -d 192.168.50.2/32 -p tcp -m tcp --dport 25 -j DNAT
>> --to-destination 192.168.50.20
>> -A POSTROUTING ! -d 192.168.50.2/32 -j SNAT --to-source 192.168.50.2
>> COMMIT
>> # Completed on Fri Oct 18 02:41:35 2013
>> ---
>>
>> Where:
>>
>> 1- The IP 192.168.50.2 is the "Nat Instance" itself, with a "public and
>> valid Floating IP" attached to it;
>>
>> 2- The IP 192.168.50.11 is a Web Server, that the Internet needs to
>> access;
>>
>> 3- The IP 192.168.50.20 is a Mail MX Server, so, the tenant can receive
>> e-mails;
>>
>> 4- The latest line is the creepiest, it is required because the NAT
>> Instance, is not the default gateway of the tenant network, so, you'll
>> require to "MASQ" both source and destination address.
>>
>>
>> This topology is "famous" even when using Amazon EC2 with private VPC,
>> for example. But, honestly, I think it is terrible, mostly because of IPv4.
>> This brings lots of problems, for example:
>>
>> * web server logs will register only the "NAT" Instance internal IP;
>>
>> * if you have a e-mail server instance, you'll need to figure out by
>> yourself, the qrouter- public IP, to register it as an allowed IP (SPF) to
>> send e-mails as your domain + plus register the "Reverse DNS" of the router
>> Floating IP, as your e-mail (horrible)....
>>
>> * And problems go on...
>>
>>
>> BTW, with IPv6 all those things will be left in the past, since NAT is a
>> workaround of IPv4 networks and there is no NAT for IPv6 (when with Ubuntu
>> 12.04). So, when with IPv6, there will be no "NAT Instance" or NAT rules to
>> mange at the router (far much simpler and beauty) and your network will
>> ALWAYS work as expected, we just need to wait a few months to join the
>> future without any NAT!
>>
>> Regards,
>> Thiago
>>
>>
>>
>> On 19 December 2013 14:35, Abbass MAROUNI <abbass.marouni at virtualscale.fr
>> > wrote:
>>
>>> Could you please elaborate about your temporary solution ?
>>> I couldn't get a VM to act as a router that will do the port forwarding
>>> for other VMs in a private network. For some reason the VM cannot act as a
>>> router.
>>> Is it due to neutron networking ?
>>>
>>> Best regards,
>>>
>>>
>>>
>>> 2013/12/19 Martinx - ジェームズ <thiagocmartinsc at gmail.com>
>>>
>>>> I'm wondering about this too... I think that would be very nice to give
>>>> the FWaaS, the ability to manage the NAT table of tenant router.
>>>>
>>>> This way, there is no need for a "NAT Instance" with a second Floating
>>>> IP attached to it plus creepy NAT rules there (far away from the tenant
>>>> router).
>>>>
>>>> Also, the IPv4 tenant router already have "by nature", 1 Floating IP
>>>> for it, so, because there is no way to configure the NAT rules of the
>>>> qrouter, we need to give at least 2 public IPs (one for the router itself,
>>>> another for the "NAT Instance") for each tenant, with in IPv4 world, is a
>>>> waste.
>>>>
>>>> Please Stackers! FWaaS needs to be able to handle NAT rules (I
>>>> think)... ;-)
>>>>
>>>> Cheers!
>>>> Thiago
>>>>
>>>>
>>>> On 19 December 2013 12:23, Abbass MAROUNI <
>>>> abbass.marouni at virtualscale.fr> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Why is it not possible to do port forwarding with neutron L3 ?
>>>>> Any alternative to manually adding to iptables of each virtual router ?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list:
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>> Post to : openstack at lists.openstack.org
>>>>> Unsubscribe :
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131219/ecbac1bd/attachment.html>
More information about the Openstack
mailing list