I rent a physical server at OVH’s daughter company SoYouStart, and use it to run VMware vSphere/ESXi 6.0 on it, with a number of OpenBSD Virtual Machines (one of which hosts this blog). It took me a while to figure out the correct way of configuring the network settings on my OpenBSD VMs, as their network setup is somewhat unorthodox.
This post is based on an answer I’ve provided on ServerFault OpenBSD: Gateway outside subnet (works in Linux).
The Problem: Network Setup
When ordering a server from OVH (or their daughter companies), or I’m sure many other providers of the kind, the customer will be assigned an IP address to go with that server, with an option for additional IPs. My intention was to install ESXi and then spin up a few VMs, therefore I needed to use those extra IPs.
The additional IPs will most likely belong to a different pool than the main IP address of the server, and in any case all those IPs will need to be configured on a network interface with a 32 bit netmask (255.255.255.255), making them each belong to a different subnet.
What that means is that the default gateway will always be outside of the network configured on the network interface.
If I read correctly into that design, it is intended to eliminate the Layer 2 broadcast traffic, of which there could be quite a significant amount if all the hosts were in a large shared subnet. Also, this design allows them to assign IPs from different pools, each promising to be recognised as located in a different region of the world – a nice bonus, if one wants to provide or access geographically restricted services.
OVH have a documentation providing examples how to configure this on a number of operating systems (currently Debian derivatives, RedHat derivatives, FreeBSD and Windows) but nowhere I could find the necessary information for OpenBSD.
The Solution
As mentioned above, I’ve requested extra IP addresses from OVH and they come from a completely different range. For the discussion here, let’s assume these are my settings:
- my main IP address (which the ESXi Host is using): 213.0.113.78/32
- the extra IP address range for VM guests: 192.0.2.64/30
- the default gateway for ALL of the above: 213.0.113.254
- please note – all hosts need to use a host netmask (255.255.255.255) due to the way the OVH network is configured
The configuration for OpenBSD varies slightly depending on which version you’re running. I’ll provide details for OpenBSD 5.8 and OpenBSD 5.9.
OpenBSD 5.8
To configure the routing on a VM running OpenBSD 5.8, I’ve had to run the following commands:
ifconfig vmx0 inet 192.0.2.64 255.255.255.255
route add -inet 213.0.113.254 -llinfo -link -static -iface vmx0
route add -inet default 213.0.113.254
To make these persistent across the system’s reboot, I ignore the /etc/mygate
file and put the following into the /etc/hostname.vmx0
file instead:
inet 192.0.2.64 255.255.255.255
!route add -inet 213.0.113.254 -llinfo -link -static -iface vmx0
!route add -inet default 213.0.113.254
As I understand it, this works using the following trick:
- we configure the IP address on the interface
- with the first
route
command we translate the IP address of the gateway (213.0.113.254) to a link address (MAC address); this is done by the-llinfo
option; - in the same
route
command, using the-link
option, we install the link address to the routing table and using the-iface vmx0
we tell the kernel which network interface that link address is reachable via; the-static
switch marks it as a manually inserted entry into the routing table - the second
route
command can now succeed, as the route to the default gateway is now known
OpenBSD 5.9
After upgrading my OpenBSD VMs from 5.8 to 5.9, I’ve noticed that the IPv4 connectivity to the VMs would drop after a couple of days (for some VMs it would happen more often than for others, but eventually it happened on each and every one of them). When I investigated, I found out that the route to 213.0.113.254 via vmx0 was dropped, and therefore the default route became invalid. This apparently has been caused by a change in arptfree()
between 5.8 and 5.9, as per this post.
To fix that issue, the configuration for 5.9 has to be slightly different. In your /etc/hostname.vmx0
file put the following lines:
inet 192.0.2.64 255.255.255.255
!sleep 2
!route add -inet -net 213.0.113.254 -netmask 255.255.255.255 -link -cloning -iface vmx0
!route add -inet default -ifa 192.0.2.64 213.0.113.254
You will notice the sleep
command – for some reason this is required on OpenBSD 5.9 but wasn’t before. Without the sleep
, the first of the two route
commands will not be executed and therefore your routing will not be configured correctly.
Also, the above configuration uses -cloning
option for route
, which indicates that the link entry for the route should be generated, as opposed to using the -link
option which creates a manual entry, which will be removed when the ARP timer for that entry expires.
OpenBSD 6.0
The information for this section has been provided by one of the readers, Jean Michel Rizzardi. Thanks Jean Michel!
Once again, the configuration of the /etc/hostname.vmx0
file needs to be changed due to changes in the networking code in the kernel – the good news is that the configuration is now a bit simpler and makes more sense. The working config for 6.0 is as follows:
inet 192.0.2.64 255.255.255.255
!sleep 2
!route add -inet 213.0.113.254/32 -link -iface vmx0
!route add -inet default 213.0.113.254
I love you so much dude, this saved me a lot of trouble
Haha, thanks! This made my day!
Thanks Michal !!
I tried both for 6.0, neither have worked…got a fix? =)
Unfortunately not! I’ve not had an opportunity to try out 6.0 with OVH yet. I’ll update this article when I do and find out the solution. And please do let me know when you manage to get this working before!
Thanks!
Hi,
just for the record, I had success on OpenBSD 6.0 with:
inet xx.xx.xx.xx 255.255.255.255 xx.xx.xx.xx
!route add -inet /32 -link -iface em0
!route add -inet default
in hostname.xxx
Hope this helps ;o)
Sorry previous post was incomplete
inet virtual_ip 255.255.255.255 virtual_ip
!route add -i
net gateway_ip/32 -link -iface em0
!route add -inet default gateway_ip
in hostname.xxx
Hi Jean Michel,
Thanks a lot for that. I’ll test this when I deploy a 6.0 system at OVH and update the article!
Thanks once again,
Best Regards,
mike
Great! I can finally reach my OBSD 6.0.
-iface seems to be a flag though
Have you tried or happen to have a solution for an OVH IPv6 setup? I’ve opened pf for neighbour discovery, router advertisements, etc. basically IPv6 is wide open but I can never get a route setup. Although autoconf isn’t supported it temporarily gets me further the routing solicitation chain. Any ideas would be great 😉
As a matter of fact I do have a working solution for an OVH IPv6 setup (as long as it’s the same as with SoYouStart!). It’s actually much simpler due to the fact that they do assign a larger block as opposed to a number of host routes, however it’s still weird enough. Please note, however, I use static, manual setup.
In my case let’s assume I have been assigned
2001:d88:3:3a5a::/64
. Your default gateway will be2001:d88:3:3aff:ff:ff:ff:ff
(if the IPv6 block was2001:d88:5:5c47::/64
, then the default gateway would be2001:d88:5:5cff:ff:ff:ff:ff
).In SoYouStart’s web interface I have assigned an IPv6 address from that /64 range to my OpenBSD VM, say
2001:d88:3:3a5a::1/128
. Then, in/etc/hostname.vmx0
I have the following, just below the lines for IPv4 configuration:The one thing to make sure of is to assign the IPv6 address to your interface with the /56 netmask (despite the fact that they only give you a /64).
I’m not sure if they do use any form of autoconfiguration, but if you do want to use it, you may also need to use
sysctl
to set some of thenet.inet6
settings. I think in recent releases of OpenBD (certainly from 5.9 onwards) there is no longer a need to enable accepting of the router advertisements, but if you’re using an older release, you may need to. Have a look atsysctl(8)
.Hope that helps, do please let me know!
The 56 prefix length was the key. Thanks!
thank you so much for your help \o/