3

We need to set up an OpenBSD host to use a default gateway that's outside of it's subnet. This is all I need to do on Linux (not the actual IPs) to achieve it:

ifconfig eth0 33.33.33.33/31 up
route add 33.33.33.254 dev eth0
route add default gw 33.33.33.254

The problem is that we don't know the proper equivalent of the middle command in OpenBSD. The man page says:

If the destination is directly reachable via an interface requiring no intermediary system to act as a gateway, the -iface modifier should be specified;

Sadly we can't seem to figure out how to make it work with that. This is a virtual host on an OVH server, they have documentation for many other operating systems showing how to do it here: http://help.ovh.co.uk/BridgeClient

  • 1
    That's not how routing works. By definition, the gateway must reside on the same subnet. If it's working on a Linux host, it's either a bug or some other fluke. – EEAA Oct 20 '13 at 12:13
  • 1
    Sounds like OVH's bizarre network again. You might not be able to get help anywhere else. – Michael Hampton Oct 20 '13 at 15:52
  • @cnst Congrats, this was by far the least helpful of the 3 comments. Seriously, shilling another hosting company without even knowing our requirements? Good job. – kshade Nov 25 '13 at 9:17
  • @kshade, online.net is one of the most well known, oldest and biggest ISPs in France; what are your requirements? – cnst Nov 25 '13 at 18:21
  • I agree that saying 'use $this provider instead' is not the answer. But I am absolutely confused. As I understand it you do need to have the DG on one of your local subnets. Even if that means creating an alias for your sole NIC and thus using two local networks. The old one, and one with only your host and the DG. – Hennes Nov 30 '13 at 0:24
8

This is an old thread, but here goes.

As it happens, I run a number of OpenBSD VMs on an ESXi 6.0 running at SoYouStart, a daughter company of OVH. The network setup there is the same as with OVH and I think, although strange, its main purpose is to eliminate ARP traffic as much as possible by artificially limiting the broadcast domains, and without the need for using VLANs for example.

In my case, 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

To configure the routing on the OpenBSD host, this is what I need to do:

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 have all this done during the start, I ignore the /etc/mygate file and put the following in the /etc/hostname.vmx0:

inet 192.0.2.64 255.255.255.255
!sleep 2
!route add -inet 213.0.113.254 -llinfo -link -static -iface vmx0
!route add -inet default 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 to route commands will not be executed and therefore your routing will not be configured correctly.

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

One thing I did come across in the setup above, which I have no solution for yet, is that one of four OpenBSD hosts, configured in the exact same way, running the exact same version of the OS and the exact same kernel build, and even running on the same VMware host, every 24 hours or so, seems to be "losing" that magic route from its routing table...

| improve this answer | |
1

I had the same issue as Mike and found it difficult to get OpenBSD to properly route the assigned IP address. Similar to OVH, dedicated servers on myLoc.de provide IP addresses with 255.255.255.255 netmask which need to be routed point-to-point inside the VM. I had already dealt with this in other guest OSs. In Debian 10 I would set up the external IP in the guest like this:

# nano /etc/network/interfaces

iface eth0 inet static
        address 56.78.91.56/32    ## this is the additional external IP
        pointopoint 99.78.91.101  ## this is the gateway for the additional IP (which in my case is also the main IP of the server)
        gateway 99.78.91.101

... and in Ubuntu 18.04 using netplan it the relevant part would look like this, which works using on-link:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0: #Interface-Name
      addresses:
        - 56.78.91.56/32 ## additional external IP
      routes:
      - to: 0.0.0.0/0
        via: 99.78.91.101 ## gateway for the additional IP
        on-link: true

Configuring this with the ip command using the onlinkoption I would do the following:

ip addr add 56.78.91.56/32 dev eth0
ip route add default via 99.78.91.101 dev eth0 onlink

Somehow the way the route command is documented in OpenBSD and FreeBSD did not make it very clear how I could do a similar thing on BSD and there were almost no examples to be found using a web search. Maybe for those more familiar with networking the answer is obvious. I finally got it to work just before I found Mike's more complete answer in a separate article he posted. Therefore I will update his answer here with the configuration that actually works on OpenBSD 6.6 (eth0 is just a placeholder for the actual interface name):

ifconfig eth0 -inet 56.78.91.56/32
route -v add -inet 99.78.91.101/32 -link -iface eth0
route -v add -inet default 99.78.91.101

These commands create a routing table with the relevant lines like this:

route -n show -inet

Routing tables - Internet:
Destination     Gateway            Flags  Refs    Use   Mtu  Prio Iface
default         99.78.91.101       UGS       5     52     -     8  eth0
99.78.91.101    cc:aa:d2:4f:08:8f  UHLSh     1     30     -     8  eth0 # MAC address on the server
56.78.91.56     7a:33:f7:42:44:7e  UHLl      0     26     -     1  eth0 # MAC address of the VM
56.78.91.56/32  56.78.91.56        UCn       0      0     -     4  eth0

To permanently save the OpenBSD 6.6 configuration in the /etc/hostname.eth0 file use the following. (Apparently the 2 second delay is needed for all commands to be executed.)

inet 56.78.91.56/32
!sleep 2
!route -v add -inet 99.78.91.101/32 -link -iface eth0
!route -v add -inet default 99.78.91.101

This works currently on a Proxmox 6 server with OpenBSD as the guest running in a KVM. The external IP address is attached to the virtual bridge on the server. I do not know if a lot of dedi server companies have their networking set up like this making it harder to configure, but I encountered this on Webtropia, Servdiscount (both connected to myLoc) and seen similar questions on Hetzner.

| improve this answer | |
0

Try setting up an alias on the interface instead:

ifconfig eth0 alias 33.33.33.254

OpenBSD will probably have a different interface name then eth0 depending on the driver used.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.