We are happy to announce a new addition to our Public Marketplace: the service appliance with several Virtual Network Functions (VNFs), the virtualized network services including the Virtual Router. Based on Alpine Linux, it comes with a number of useful network functions:
- DHCPv4 server
- DNS recursor
- IPv4 Network Address Translator (i.e. NAT, IP Masquerade)
- Virtual Router
A High Availability option is provided by Keepalived. If you are (or were) using the OpenNebula Virtual Routers, it might be interesting for you to know that the new appliance is an improved version built upon the old (and now legacy) VRouter appliance, which implemented only virtual routing functionality.
You’ll find two new virtual appliances available on our Public Marketplace. They are based on the same image, but with different (Virtual Machine) templates and designed for different purposes:
- Service VNF – exposing all features, but runs as regular Virtual Machine,
- Service Virtual Router – runs as OpenNebula Virtual Router.
As of now the list of implemented VNFs is a bit limited, but it’s expected to grow in the future with other VNF services, so let us know your preferences! Some possibilities include load balancing, port forwarding, VPN, and others…
This new appliance is a little bit different from previous ones. It supports recontextualization and can adjust the behavior during run-time. You don’t need to start a brand new instance if your configuration requirements for a particular virtual network function change. Naturally, it will also react and reconfigure itself when network interfaces are dynamically added or removed.
Let’s see how this new functionality works when implementing a typical network router:
As displayed on the picture, we have an instance of VNF/Virtual Router appliance with 3 connected NICs, each into a different virtual network. Interfaces eth1 and eth2 are connected to the distinct private networks and instance provides there DHCP and DNS services and routes between networks. Interface eth0 goes to the Internet and all traffic from private networks (eth1, eth2) goes through the Network Address Translation (NAT) mechanism, which means that clients on private networks can reach the public Internet “hidden” behind the IP address of the VNF/Virtual Router instance.
Here is an example of how to contextualize such VNF/Virtual Router instance in OpenNebula:
We enable DHCPv4, NAT, and DNS VNFs (routing is enabled by default when the appliance is started as OpenNebula Virtual Router) and use a special syntax to define on which network interfaces is a particular function active. For both DHCP and DNS, we requested to run on every attached network interface except the public Internet-facing one (!eth0 – notice the exclamation mark). We usually do not want to provide these services to the public Internet, both are dangerous if not used properly and could disrupt someone else’s infrastructure or become a victim of DDoS. On the contrary, for the NAT VNF, we select that outgoing traffic will be NATed on the eth0 interface, and nowhere else.
Now we can just simply attach (and detach) NICs into particular virtual networks and the VNF/Virtual Router will automatically reconfigure itself to provide the desired services with the requested constraints. It does not matter if it has two, three, or more NICs attached to it. NAT will be enabled only on the first interface (eth0), with the other DHCP and DNS services active on all other interfaces.
Hopefully, this short example clarifies some of the key feature of the new VNF/Virtual Router appliances. As usual, you can find out more about them in our documentation section.
And as always, we would love to hear from you about your experience using this appliance, and please send us your suggestions for future improvements!
Hello, do you plan to implement load-balancing functionality? I proposed it few years ago, but nothing was done about it.
Yes, load balancing and more is planned for this appliance as are other VNFs (next to DHCP, DNS, etc.). Sorry, I frankly was not aware of your contribution which you have linked above. The current appliance is a complete rewrite of the previous version and it was actually worked on since last year but then it was idly sitting for quite time in the queue :/
Nevertheless, load balancing, VPN and other functions are planned and will be added as time will allow.
Thanks again for your contribution – I will reexamine it.
Hello please i have a question in relation to the following: Interface eth0 goes to the Internet and all traffic from private networks (eth1, eth2) goes through the Network Address Translation (NAT) mechanism
Do I need any configuration in the MY Physical ISP ROUTER/GATEWAY?, regards,
if you configured the VNF/Vrouter correctly (https://docs.opennebula.io/appliances/service/vnf.html#function-nat4) and set ONEAPP_VNF_NAT4_ENABLED=yes and ONEAPP_VNF_NAT4_INTERFACES_OUT=eth0 then it should work just fine for you.
You may encounter issue with DNS resolving if your private vnets are not setting up DNS or they point to a wrong place.
In such case try to fix affected vnets by setting correct DNS nameserver in their context or enable DNS on VNF/Vrouter itself (https://docs.opennebula.io/appliances/service/vnf.html#function-dns) – you can either leave it to just forward queries to your router or set it to use root servers (be mindful to not enable DNS on the eth0 interface!).
All this means of course that VNF/Vrouter must itself be able to access internet on the eth0 via your router otherwise you must fix the vnet setup attached to eth0 (correct subnet, gw, dns…).
Please if you still have trouble with the setup then open new topic on the https://forum.opennebula.io/.
I want to access VM (private IP) from public, some function like Elastic IP or SDNAT4.
How can I assign public IP to private VM?