zeldor.biz

Linux, programming and more

Copyright © 2023
Log in

Hetzner /28 Subnet with KVM

January 29, 2014 by Igor Drobot 6 Comments

Hetzner

Subnet configuration on a Hetzner dedicated root server (EX40) is a bit tricky than a normal additional single ip addresses that you can buy for 1EUR. So I wrote the configuration down:

You will need bridge-utils:

1
apt-get install bridge-utils

apt-get install bridge-utils

So I ordered a /28 subnet for my VM-landscape:
78.89.34.208/28 (255.255.255.240)
Usable IP-Addresses: 78.89.34.209 – 78.89.34.222

My root server had already: 56.23.67.56/27 (255.255.255.224)

Typology

Host

Host-System
Copy of /etc/network/interfaces

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# Loopback device
auto lo
iface lo inet loopback
 
auto eth0
 
# IPv4
iface eth0 inet static
    address 56.23.67.56
    netmask 255.255.255.224
    gateway 56.23.67.33
    pointopoint 56.23.67.33
 
auto system17
iface system17 inet static
        address 172.30.79.1
        netmask 255.255.255.0
        pre-up brctl addbr $IFACE
        post-up route add -host 78.89.34.209 $IFACE
        post-down brctl delbr $IFACE
 
auto system18
iface system18 inet static
        address 172.30.80.1
        netmask 255.255.255.0
        pre-up brctl addbr $IFACE
        post-up route add -host 78.89.34.210 $IFACE
        post-down brctl delbr $IFACE

# Loopback device auto lo iface lo inet loopback auto eth0 # IPv4 iface eth0 inet static address 56.23.67.56 netmask 255.255.255.224 gateway 56.23.67.33 pointopoint 56.23.67.33 auto system17 iface system17 inet static address 172.30.79.1 netmask 255.255.255.0 pre-up brctl addbr $IFACE post-up route add -host 78.89.34.209 $IFACE post-down brctl delbr $IFACE auto system18 iface system18 inet static address 172.30.80.1 netmask 255.255.255.0 pre-up brctl addbr $IFACE post-up route add -host 78.89.34.210 $IFACE post-down brctl delbr $IFACE

From VM-System
Copy of /etc/network/interfaces

1
2
3
4
5
6
7
8
9
10
11
# The loopback network interface
auto lo
iface lo inet loopback
 
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
        address 78.89.34.209
        netmask 255.255.255.255
        gateway 56.23.67.56
        pointopoint 56.23.67.56

# The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 78.89.34.209 netmask 255.255.255.255 gateway 56.23.67.56 pointopoint 56.23.67.56

So, you need to create for each new VM a new bridge.

Filed Under: Debian, Linux, Networking, Virtualization Tagged With: hetzner, KVM, virtualization

Categories

Archives

Tags

apache2 Apple arduino ARM Automation backup bash Cisco Cluster Corosync Database Debian Debian squeeze DIY DNS Fedora FTP Fun Icinga Ipv6 KVM Linux LVM MAC OS X Monitoring MySQL Nagios Nginx openSUSE OpenVPN PHP Proxy Python python3 qemu RAID rsync Samba security ssh Ubuntu virtualization Windows Windows 7 Wordpress

Comments

  1. thorleif says

    November 21, 2016 at 22:09

    Razvan Mihaiu: 172.16.0.0 – 172.31.255.255 are private network ip-adresses and will not crash with anything outside. They are on the same level as 10.0.0.1 or 192.168.x.x e.g. :)

  2. Razvan Mihaiu says

    July 12, 2015 at 09:34

    Hi Zeldor,

    In the end I hired a freelancer to do it. I just could not make it work. The truth is that I am a programmer so this is outside of my area of expertise.

    The config for which we opted is based on PFSense. I never heard of this Open Source stack before, but from what I have read the past few days, it is great.

    The config goes as follows:

    1. main IP server
    2. three additioanl IPs
    3. one /27 subnet with 32 IPs, only 30 being usable

    Normally, the subnet is routed to the main IP server. I created a ticket and asked Hetzner to route the subnet to one of the additional IPs. The freelancer told me that this is absolutely necessary as the setup could not be finished without this. I was 99% sure that Hetzner would refuse that because our server is unmanaged. To my surprise they routed the subnet to the new IP without any questions being asked.

    So, there is a VM which we call pfsense that gets all the traffic on one of the additional IPs. The pfsense box handles the routing for all the other VMs behind it.

    There is a small disadvantage with this setup: we’ve lost the IP where pfsense works (lost in the sense that we cannot put it to good use). But, it’s small disadvantage: we can live with that.

    It would be great if you could point me to some resources where I can learn fast all that I need in order to configure this on my own in the future. I mean, please look it from this practical perspective: I don’t give a damn about how networks works as I am not making any money in this area. Time is always a factor, so I rather learn something that makes money for me rather than just learn for the sake of wisdom.

    I did searched on Amazon for somne books on Linux networks. It’s true, I found what I needed but there was a slight problem: all those books were Bible-size :)

    I very much doubt that I need to know it all in order to configure this routing setup.

    Thanks for your help. If it would not be for my limited network skills, most probably I could have pulled this off with the information that you presented here.

  3. zeldor says

    July 12, 2015 at 00:20

    Hi Razvan,

    your config seems to be okay. The Hetzner link you have posted covers your need and describes the same configuration setup. Unfortunately I have no access to the system where this setup was realised. Please verify your bridging setup configuration. Which linux distribution do you use? Otherwise, we could try to figure your problem in a live session out;)

    – risks in publishing the real IPs?
    Many! For security reasons you should hide your real WAN ip addresses.
    If they belong to a corporation where you work, you are not allowed to publish them(of course based on the country where you live and work).

  4. Razvan Mihaiu says

    July 4, 2015 at 06:55

    Fair enough. Thing is, it’s still not working for me. If I manage to pull this off, I need to get drunk.

    My background is in programming, not sys admin / networks.

    I will build below the config files for 3 VPSes with the knowlegde that I have so far. Please analyse this config and tell me if you find anything wrong.

    The first thing that must be done is to choose clear IPs for both the host (metal) and also for the VPSes. What bothers me in your config (or maybe I don’t understand it) is that it appears that the IPs are not consistent. Even if the IPs are chosen randomly, the same IP should be used in all places where it is required.

    What I mean by the above is that the randomly chosen host IP 56.23.67.56 should be used in the “post-up route add” intructions.

    Host IP data (metal):
    IP: 56.23.67.56
    Netmask: 255.255.255.224
    Gateway 56.23.67.33
    Broadcast: 56.23.67.155

    IP range for VPSes:
    78.89.34.209 – 78.89.34.222

    This is the config that I can build using Hetzner instructions and also your sugestions:

    (the resource that I am using from Hetzner is this: http://wiki.hetzner.de/index.php/Netzkonfiguration_Debian/en#Routed_.28brouter.29)

    # Loopback device
    auto lo
    iface lo inet loopback

    auto eth0

    # IPv4 for HOST (METAL)
    # It looks like you are not using the Broadcast value while in my real Hetzner config, this is used;
    iface eth0 inet static
    address 56.23.67.56
    netmask 255.255.255.224
    gateway 56.23.67.33
    pointopoint 56.23.67.33

    auto virt01
    iface virt01 inet static
    address 56.23.67.56 (according to Hetzner, this must be the address of the HOST (METAL))
    netmask 255.255.255.0
    pre-up brctl addbr virt01
    post-up route add -host 78.89.34.209 virt01 # IP no.1 from the range (78.89.34.209 – 78.89.34.222)
    post-down brctl delbr virt01

    auto virt02
    iface virt02 inet static
    address 56.23.67.56 (according to Hetzner, this must be the address of the HOST (METAL))
    netmask 255.255.255.0
    pre-up brctl addbr virt02
    post-up route add -host 78.89.34.210 virt01 # IP no.2 from the range (78.89.34.209 – 78.89.34.222)
    post-down brctl delbr virt02

    auto virt03
    iface virt03 inet static
    address 56.23.67.56 (according to Hetzner, this must be the address of the HOST (METAL))
    netmask 255.255.255.0
    pre-up brctl addbr virt03
    post-up route add -host 78.89.34.211 virt01 # IP no.3 from the range (78.89.34.209 – 78.89.34.222)
    post-down brctl delbr virt03

    The entire config from above resides on the HOST (METAL) in the file /etc/network/interfaces

    Now, let’s head over to the similar files from each VPS:

    VPS 1:
    # The loopback network interface
    auto lo
    iface lo inet loopback

    # The primary network interface
    allow-hotplug eth0
    iface eth0 inet static
    address 78.89.34.209 # IP no.1 from the range (78.89.34.209 – 78.89.34.222)
    netmask 255.255.255.255
    gateway 56.23.67.56 # the IP from the HOST (METAL)
    pointopoint 56.23.67.56 # the IP from the HOST (METAL)

    VPS 2:
    # The loopback network interface
    auto lo
    iface lo inet loopback

    # The primary network interface
    allow-hotplug eth0
    iface eth0 inet static
    address 78.89.34.210 # IP no.2 from the range (78.89.34.209 – 78.89.34.222)
    netmask 255.255.255.255
    gateway 56.23.67.56 # the IP from the HOST (METAL)
    pointopoint 56.23.67.56 # the IP from the HOST (METAL)

    VPS 3:
    # The loopback network interface
    auto lo
    iface lo inet loopback

    # The primary network interface
    allow-hotplug eth0
    iface eth0 inet static
    address 78.89.34.211 # IP no.3 from the range (78.89.34.209 – 78.89.34.222)
    netmask 255.255.255.255
    gateway 56.23.67.56 # the IP from the HOST (METAL)
    pointopoint 56.23.67.56 # the IP from the HOST (METAL)

    Finally, done…

    Do you see anything wrong with the above? My setup is like the above and it is not working.

    Btw, your hiding on IPs got me thinking: are there any risks in publishing the real IPs? What sort of risks should I expect
    to face if I pusblish my real IPs?

    Thank you

  5. zeldor says

    July 1, 2015 at 22:54

    1. pre-up brctl addbr ; post-down brctl delbr, correct without bridging this setup will not work.
    2. this is Debian Linux specific configuration file – is a real example config with fictional ips
    3. are simple dummy IP-Addresses – you can use something else of your choice

  6. Razvan Mihaiu says

    July 1, 2015 at 19:54

    Thank you for this tutorial. I searched all the net for something like this.

    I know how to configure VirtualBox with the first 3 IP addresses from Hetnzer. Now I was forced to order a subnet and I am completely stuck on this.

    Your article helps, but I still have questions:

    1. what is the use of bridge-utils? you have not issues any cmd line with the tools.

    Is it to support variables in the file “/etc/network/interfaces”? I see there variables such as $IFACE. This doesn’t work if the tools are not installed?

    2. /etc/network/interfaces seems incomplete.

    If I got it right, on the host system you need an entry for each VM.

    If this is right, something is not very logic with your numbering. Why the first system is called system17 when it should be called br01 based on the picture and on the assigned IP address (78.89.34.209 is the first from the range).

    There should be there 14 entries, please correct if I am wrong (in case you are using all your IPs).

    3. What is the meaning of IPs 172.30.79.1 and 172.30.80.1 etc?

    Your server (host / metal) is on IP 56.23.67.56. Your VMs are coming from the IP range 78.89.34.209 – 78.89.34.222. So what the heck are the IPs 172.30.79.1 – 172.30.80.1 used for? And what is the algoritm for their creation? How to you get to those IPs based on your server IP and VM IPs?

    Thank you

Leave a Reply

Your email address will not be published. Required fields are marked *