[vbox-dev] Static route or default gateway for NAT

Tue Oct 4 09:29:03 GMT 2016

Dear Malcolm,

I don't believe there is any demand for this because the NAT Network 
mode was never intended to be used this way.
It really is just an easy way to put a bunch of VMs on a host within 
their own network and hide them from the external world.

While what you want to do is normal and standard, it's definitely not 
the use case for NAT Network mode.
A typical setup would be a dedicated VM acting as a router/NAT Engine 
instead of the NAT Network process, VM that you can configure and that 
will do all the work.
That dedicated VM would have a bridged interface on the physical NIC of 
the host. Another typical setup would be to replace the dedicated router 
VM by the host itself - you would then configure NAT and IP Routing on 
the host using iptables and your router VM for the hidden network would 
have a host-only interface.

I'll let the devs confirmed I'm not saying anything stupid here :)

Max

On 04/10/16 11:01, Malcolm Clarke wrote:
>
> Dear Maxine
>
> The topology would be as follows
>
> Public |--------| VBox NAT Network process |Private Network 1 10.0.2.0| Router VM |Private Network 2 10.0.3.
> 0
>
> With a routable private network behind the NAT router. This is 
> industry standard.
>
> However the NAT router needs sufficient information to deliver 
> incoming packets other than for its own subnet to another router, 
> either because it has static routes, default router or understand RIP. 
> This is normal.
>
> I understand that the NAT network process is intended to be simple and 
> support basic functionality, however my topology is industry standard, 
> and others may wish to do training, etc on this type of configuration.
>
> I would be content with the most basic support, eg default router. 
> However I do not know the demand for this.
>
> Regards
>
> Malcolm
>
>
>
> On 04/10/2016 09:34, Maxime Dor wrote:
>> Malcolm,
>>
>> Just to be clear, is this your topology?
>>
>>     Public |--------| VBox NAT Network process |---------| Router VM |---------| Hidden network
>>
>> If so, I'm not aware of options to include static routes into the NAT 
>> engine of VirtualBox, but I also don't see why you would need to.
>> it's the job of the router VM to also do NAT to hide that final 
>> network, else you need the "public" routers to know about that hidden 
>> network but that defeats the point of using NAT in the first place.
>> If this is your topology, I feel you're just using the wrong tool for 
>> the job.
>>
>> If your topology is different, let us know and we'll help further!
>>
>> On 03/10/16 22:34, Malcolm Clarke wrote:
>>>
>>> Dear Maxine
>>>
>>> The problem is that a packet can eminate from a VM on the hidden 
>>> subnet and is correctly routed by the internal router to the NAT 
>>> router (the internal server contains the NAT as its default router), 
>>> and so the packet is sent to the public network. The NAT router will 
>>> correctly create an entry in the mapping table with the return IP 
>>> address. However when a packet returns from the public network, even 
>>> though the NAT router can substitute the correct destination IP 
>>> address for the hidden subnet, it does not have the routing 
>>> information to deliver the packet to the internal router for it to 
>>> be returned to the VM on the hidden network.
>>>
>>> It would therefore require some simple mechanism to add static 
>>> routes (or private side default gateway) to the NAT router.
>>>
>>> Using a bridge will not work as that would require configuring 
>>> "public" routers to deliver packets to the internal router. NAT is 
>>> the best solution.
>>>
>>> Regards
>>>
>>> Malcolm
>>>
>>>
>>> On 03/10/2016 13:58, Maxime Dor wrote:
>>>> Hi Malcom,
>>>>
>>>> That is on purpose - being behind a NAT network means you want to 
>>>> hide any subnet connect to that network from the outside world.
>>>> Any outgoing connection will look like it came from the NAT Router 
>>>> "public" IP.
>>>> If you want to allow specific connections to be allowed in, you 
>>>> need to configure port forward - so far, I don't think I tell you 
>>>> anything new.
>>>>
>>>> But if you need the "outside" world to know about "inside" 
>>>> networks, then NAT is not the right choice. You need to switch to a 
>>>> non-NAT solution like Bridged mode (or Host-Only with routing 
>>>> enabled on the host) and the "outside" world needs to know about 
>>>> those "inside" network with two possibilities:
>>>> - Static routes on all routers that need to deal with those subnets
>>>> - Internal routing protocol like RIP, EIGRP or OSPF that will 
>>>> auto-detect routes and populate routing tables of routers.
>>>>
>>>> On 03/10/16 13:30, Malcolm Clarke wrote:
>>>>> Dear Development Group
>>>>>
>>>>> I am trying to demonstrate routing in a virtualised network 
>>>>> created using VirtualBox with a FreeBSD server acting as router 
>>>>> between 2 virtual networks. One network is set as NAT Network to 
>>>>> allow access to outside world. However, although packets can be 
>>>>> directed from the router to the NAT router for outward delivery, 
>>>>> the NAT router does not know how to deliver the incoming packets 
>>>>> for the "hidden" subnet.
>>>>>
>>>>> I wonder if anyone has modified the NAT network to allow simple 
>>>>> static routes or default gateway to support this cnfiguration.
>>>>>
>>>>> I do not know the interest for this functionality and whether the 
>>>>> work is justified for the use that would be made.
>>>>>
>>>>> Regards
>>>>>
>>>>> Malcolm
>>>>>
>>>>>
>>>>> -- 
>>>>>
>>>>> *Malcolm Clarke *BSc (Hons), PhD
>>>>>
>>>>> Reader in Telemedicine and Data Communication Systems
>>>>>
>>>>> T+44 (0) 1895 265053
>>>>>
>>>>> *Brunel University London*
>>>>>
>>>>> College of Engineering, Design and Physical Sciences
>>>>>
>>>>> Department of Computer Science
>>>>>
>>>>> HNZW011, Heinz Wolff Building, Kingston Lane, Uxbridge, Middlesex, 
>>>>> UB8 3PH
>>>>>
>>>>> *www.brunel.ac.uk <http://www.brunel.ac.uk/>*
>>>>>
>>>>> Connect with the university on*Linkedin, Twitter, Facebook*
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> vbox-dev mailing list
>>>>> vbox-dev at virtualbox.org
>>>>> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> vbox-dev mailing list
>>>> vbox-dev at virtualbox.org
>>>> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>>>
>>> -- 
>>>
>>> *Malcolm Clarke *BSc (Hons), PhD
>>>
>>> Reader in Telemedicine and Data Communication Systems
>>>
>>> T+44 (0) 1895 265053
>>>
>>> *Brunel University London*
>>>
>>> College of Engineering, Design and Physical Sciences
>>>
>>> Department of Computer Science
>>>
>>> HNZW011, Heinz Wolff Building, Kingston Lane, Uxbridge, Middlesex, 
>>> UB8 3PH
>>>
>>> *www.brunel.ac.uk <http://www.brunel.ac.uk/>*
>>>
>>> Connect with the university on*Linkedin, Twitter, Facebook*
>>>
>>
>>
>>
>> _______________________________________________
>> vbox-dev mailing list
>> vbox-dev at virtualbox.org
>> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>
> -- 
>
> *Malcolm Clarke *BSc (Hons), PhD
>
> Reader in Telemedicine and Data Communication Systems
>
> T+44 (0) 1895 265053
>
> *Brunel University London*
>
> College of Engineering, Design and Physical Sciences
>
> Department of Computer Science
>
> HNZW011, Heinz Wolff Building, Kingston Lane, Uxbridge, Middlesex, UB8 3PH
>
> *www.brunel.ac.uk <http://www.brunel.ac.uk/>*
>
> Connect with the university on*Linkedin, Twitter, Facebook*
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20161004/620d5178/attachment.html>