Öffentliche IP Adresse dem WAN Interface einer Firewall VM zuweisen
Liebe Admins
Ich habe mir vor ein paar Monaten bei Hetzner einen Root Server mit einer inkludierten öffentlichen IP Adresse angemietet. Auf diesem Root Server virtualisiere ich derzeit mehrere VMs auf Basis libvirt. Eine davon ist eine Firewall auf Basis pfSense. Am Root Server wurde als Host Distribution Ubuntu 14.04 LTS installiert.
Mein Vorhaben:
Zukünftig sollen alle VMs über die Firewall VM an das Internet angebunden sein. Dazu muss ich dem WAN Interface der Firewall VM eine öffentliche IP Adresse zuweisen. Der Hauptgrund warum ich mich für eine neue IP entschieden habe ist zum einen ein IPsec Site2Site VPN und zum anderen muss ich sämtliche Netzwerk Regeln nur noch an der Firewall VM konfigurieren. Über die bestehende/inkludierte IP sollen nur noch Wartungsarbeiten (Updates, Start/Stopp der VMs, Konfigurationsänderungen) am Root Server durchgeführt werden.
Bei Hetzner habe ich mir bereits eine zusätzliche IP Adresse angemietet. Für die Firewall VM wurde am Root Server ein isoliertes Netzwerk angelegt und anschließend an das DMZ Interface der Firewall VM angebunden.
Mein Problem:
Ich bekomme es ums verrecken nicht hin, die neue öffentliche IP dem WAN Interface der Firewall zuzuweisen.
Ich scheitere dabei an der Konfiguration des Root Servers. Dieser hat leider nur eine physische Netzwerkkarte. Laut Hetzner Wiki gibt es zwei Möglichkeiten die neue IP zu konfigurieren - Bridged und Routed. Warum ich bei beiden Möglichkeiten die inkludierte IP als "address" konfigurieren soll verstehe ich überhaupt nicht. Logisch wäre für mich die neue IP als "address" zu konfigurieren. Weiters würde micht interessieren ob man das WAN Interface der Firewall an das neue Interface vom Root Server anschließen kann oder man ein zusätzliches in libvirt erstellen muss. Falls ersteres möglich, welche MAC Adresse wird verwendet werden?
Ich bin grundsätzlich auch für andere Lösungsansätze offen.
Grüße
TheOnlyMarkus aka Markus
Ich habe mir vor ein paar Monaten bei Hetzner einen Root Server mit einer inkludierten öffentlichen IP Adresse angemietet. Auf diesem Root Server virtualisiere ich derzeit mehrere VMs auf Basis libvirt. Eine davon ist eine Firewall auf Basis pfSense. Am Root Server wurde als Host Distribution Ubuntu 14.04 LTS installiert.
Mein Vorhaben:
Zukünftig sollen alle VMs über die Firewall VM an das Internet angebunden sein. Dazu muss ich dem WAN Interface der Firewall VM eine öffentliche IP Adresse zuweisen. Der Hauptgrund warum ich mich für eine neue IP entschieden habe ist zum einen ein IPsec Site2Site VPN und zum anderen muss ich sämtliche Netzwerk Regeln nur noch an der Firewall VM konfigurieren. Über die bestehende/inkludierte IP sollen nur noch Wartungsarbeiten (Updates, Start/Stopp der VMs, Konfigurationsänderungen) am Root Server durchgeführt werden.
Bei Hetzner habe ich mir bereits eine zusätzliche IP Adresse angemietet. Für die Firewall VM wurde am Root Server ein isoliertes Netzwerk angelegt und anschließend an das DMZ Interface der Firewall VM angebunden.
Mein Problem:
Ich bekomme es ums verrecken nicht hin, die neue öffentliche IP dem WAN Interface der Firewall zuzuweisen.
Ich scheitere dabei an der Konfiguration des Root Servers. Dieser hat leider nur eine physische Netzwerkkarte. Laut Hetzner Wiki gibt es zwei Möglichkeiten die neue IP zu konfigurieren - Bridged und Routed. Warum ich bei beiden Möglichkeiten die inkludierte IP als "address" konfigurieren soll verstehe ich überhaupt nicht. Logisch wäre für mich die neue IP als "address" zu konfigurieren. Weiters würde micht interessieren ob man das WAN Interface der Firewall an das neue Interface vom Root Server anschließen kann oder man ein zusätzliches in libvirt erstellen muss. Falls ersteres möglich, welche MAC Adresse wird verwendet werden?
Ich bin grundsätzlich auch für andere Lösungsansätze offen.
Grüße
TheOnlyMarkus aka Markus
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 276295
Url: https://administrator.de/forum/oeffentliche-ip-adresse-dem-wan-interface-einer-firewall-vm-zuweisen-276295.html
Ausgedruckt am: 14.05.2025 um 00:05 Uhr
8 Kommentare
Neuester Kommentar
ganz habe ich Deinen Beitrag noch nicht verstanden, gerade auch keine Muße dafür, aber zu Hetzner ein Detail zur Erklärung:
die zugewiesene 1. IP muß dem physischen Interface zugewiesen bleiben, da ihre MAC wiederum in deren "Backbone-Struktur" im nächsten Switch/Router fest hinterlegt ist. Das ist als Sicherheitsfeature gemeint.
So ergibt sich, daß eine Firewall sinnvoll auch auf den Host gelegt wird (trotz Hypervisor), durch Portforwarding ist der Nachteil nicht groß.
HG
Mark
die zugewiesene 1. IP muß dem physischen Interface zugewiesen bleiben, da ihre MAC wiederum in deren "Backbone-Struktur" im nächsten Switch/Router fest hinterlegt ist. Das ist als Sicherheitsfeature gemeint.
So ergibt sich, daß eine Firewall sinnvoll auch auf den Host gelegt wird (trotz Hypervisor), durch Portforwarding ist der Nachteil nicht groß.
HG
Mark
Ist wirklich etwas wirr. Aber Fakt ist das das Hypervisor Interface eine IP hat und im Bridged Mode arbeiten muss bzw. zur pfSense VM Bridging machen muss.
Die pfSense VM hat dann am WAN Port eine weitere IP Adresse: Ergo, du brauchst auf alle Fälle 2 gültige IP Hostadressen. Das die pfSense und dein Hypervisor Host eine Adresse sharen ist nicht möglich.
Die pfSense VM hat dann am WAN Port eine weitere IP Adresse: Ergo, du brauchst auf alle Fälle 2 gültige IP Hostadressen. Das die pfSense und dein Hypervisor Host eine Adresse sharen ist nicht möglich.
Sorry für den etwas wirr verfassten Beitrag.
Danke aqui für den Tipp mit der Bridge. Ich habe auf einem Test PC die selbe Konfiguration wie am Hypervisor nachgebaut.
Bei einem Test PC habe ich jetzt das physische Interface eth0 jetzt als Bridge br0 konfiguriert und anschließend erneut eine pfSense installiert. Dem WAN Port der pfSense habe ich der Bridge br0 zugewiesen. Nach der Installation war die pfSense in der Lage von meinem DHCP Server im LAN eine IP für den WAN Port zu beziehen.
Ist diese Konfiguration so üblich oder sollte br0 an eine virtuelle Bridge des Hypervisors diese dann am WAN Port der pfSense angebunden werden?
Danke aqui für den Tipp mit der Bridge. Ich habe auf einem Test PC die selbe Konfiguration wie am Hypervisor nachgebaut.
Bei einem Test PC habe ich jetzt das physische Interface eth0 jetzt als Bridge br0 konfiguriert und anschließend erneut eine pfSense installiert. Dem WAN Port der pfSense habe ich der Bridge br0 zugewiesen. Nach der Installation war die pfSense in der Lage von meinem DHCP Server im LAN eine IP für den WAN Port zu beziehen.
Ist diese Konfiguration so üblich oder sollte br0 an eine virtuelle Bridge des Hypervisors diese dann am WAN Port der pfSense angebunden werden?
Nicht das du das hier falsch verstehst !
Niemals darf ein Bridging oder Bridge Interface auf der pfSense selber eingerichtet werden, das wäre fatal.
Das Bridging bezieht sich vielmehr auf den Hostadapter des Hypervisors. DIESER muss ein Bridging machen auf den virtuellen WAN Adapter der pfsense VM.
Beim kranken Hyper-V ist das m.W. ein separater Switch der dort definiert werden muss, da man diese Option nicht auf der NIC definiert (geraten, da bekennender Hyper V Hasser)
Bei sinnvolleren Hypervisoren wie VmWare oder Virtual Box konfiguriert man das entsprechend auf der NIC.
Niemals darf ein Bridging oder Bridge Interface auf der pfSense selber eingerichtet werden, das wäre fatal.
Das Bridging bezieht sich vielmehr auf den Hostadapter des Hypervisors. DIESER muss ein Bridging machen auf den virtuellen WAN Adapter der pfsense VM.
Beim kranken Hyper-V ist das m.W. ein separater Switch der dort definiert werden muss, da man diese Option nicht auf der NIC definiert (geraten, da bekennender Hyper V Hasser)
Bei sinnvolleren Hypervisoren wie VmWare oder Virtual Box konfiguriert man das entsprechend auf der NIC.
Aqui ich glaube ich verstehe auf was du hinaus willst. Fällt die pfSense aus, kann ich den Hypervisor nicht mehr erreichen.
Ich poste nochmal ausführlich meine derzeitige Konfiguration:
Auf dem Test PC wurde ein Ubuntu Server 14.04 LTS und folgende Pakete installiert: qemu-kvm libvirt-bin virtinst bridge-utils virt-manager qemu-system hal.
Am Test PC wurde die Datei /etc/network/interfaces so abgeändert:
iface lo inet loopback
iface eth0 inet manual
auto br0
iface br0 inet static
address 192.168.112.136
network 192.168.112.0
netmask 255.255.255.0
broadcast 192.168.112.255
gateway 192.168.112.2
dns-nameservers 192.168.112.2
bridge_ports eth0
bridge_stp off
Danach habe ich der pfSense VM folgende virtuelle Netzwerkadapter hinzugefügt (virsh dumpxml):
<interface type='bridge'>
<mac address='52:54:00:92:8d:f2'/>
<source bridge='br0'/>
<model type='e1000'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<interface type='network'>
<mac address='52:54:00:19:59:4f'/>
<source network='DMZ'/>
<model type='e1000'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</interface>
<source bridge='br0'/> = Test PC Bridge br0
<source network='DMZ'/> = ein isolierte virtuelle Netzwerk Bridge. Wurde durch "virsh net-define dmz.xml" hinzugefügt.
Die pfSense holt sich vom DHCP Server im LAN folgende IP: 192.168.112.137 und ist auch pingbar.
Schalte ich die pfSense aus, dann ist der Test PC (192.168.112.136) noch pingbar.
Der Test PC und die pfSense kommuniziert demnach über die Bridge br0 mit dem Internet.
Kann ich die Konfiguration so lassen?
Ich poste nochmal ausführlich meine derzeitige Konfiguration:
Auf dem Test PC wurde ein Ubuntu Server 14.04 LTS und folgende Pakete installiert: qemu-kvm libvirt-bin virtinst bridge-utils virt-manager qemu-system hal.
Am Test PC wurde die Datei /etc/network/interfaces so abgeändert:
- The loopback network interface
iface lo inet loopback
- The primary network interface
iface eth0 inet manual
auto br0
iface br0 inet static
address 192.168.112.136
network 192.168.112.0
netmask 255.255.255.0
broadcast 192.168.112.255
gateway 192.168.112.2
dns-nameservers 192.168.112.2
bridge_ports eth0
bridge_stp off
Danach habe ich der pfSense VM folgende virtuelle Netzwerkadapter hinzugefügt (virsh dumpxml):
<interface type='bridge'>
<mac address='52:54:00:92:8d:f2'/>
<source bridge='br0'/>
<model type='e1000'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<interface type='network'>
<mac address='52:54:00:19:59:4f'/>
<source network='DMZ'/>
<model type='e1000'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</interface>
<source bridge='br0'/> = Test PC Bridge br0
<source network='DMZ'/> = ein isolierte virtuelle Netzwerk Bridge. Wurde durch "virsh net-define dmz.xml" hinzugefügt.
Die pfSense holt sich vom DHCP Server im LAN folgende IP: 192.168.112.137 und ist auch pingbar.
Schalte ich die pfSense aus, dann ist der Test PC (192.168.112.136) noch pingbar.
Der Test PC und die pfSense kommuniziert demnach über die Bridge br0 mit dem Internet.
Kann ich die Konfiguration so lassen?
ich glaube nicht!
DHCP treibt einem hier die Haare hoch,
das Üben wird praxisgerechter, wenn die richtigen festen IPs zugewiesen werden.
en0 braucht die öffentliche erste IP,
br0 vermutlich eine IP eines kleinen lokalen Netzes (erfunden und Hetznerkompatibel: 192.168.22.1/24
viren0 - ein erster Gast 192.168.22.2 und wenn er nach draußen soll als zweite virtuelle IP auf der gleichen en0 - also
viren0:1 die zweite öffentlich zugekaufte IP.
Die echte en0 hängt dann also mit ihrer MAC und ihrer Hetzner-IP am Hetzner Router.
HG
Mark
DHCP treibt einem hier die Haare hoch,
das Üben wird praxisgerechter, wenn die richtigen festen IPs zugewiesen werden.
en0 braucht die öffentliche erste IP,
br0 vermutlich eine IP eines kleinen lokalen Netzes (erfunden und Hetznerkompatibel: 192.168.22.1/24
viren0 - ein erster Gast 192.168.22.2 und wenn er nach draußen soll als zweite virtuelle IP auf der gleichen en0 - also
viren0:1 die zweite öffentlich zugekaufte IP.
Die echte en0 hängt dann also mit ihrer MAC und ihrer Hetzner-IP am Hetzner Router.
HG
Mark
DHCP verwende ich nur testweise bei mir im LAN. Die richtigen festen IPs werden am produktiv System statisch konfiguriert werden.
Also Kommando retur?
Für mich zum Verständnis, welche gravierenden Nachteile/Security bedenken hat meine derzeitige Konfiguration.
Bitte erkläre mir genauer welche Rollen die von dir genannten Interfaces spielen sollen.
en0 = eth0?
br0 = DMZ Interface der pfSense?
viren0 = virtuelles VM Interface?
viren0:1 = ?
Ich hoffe wir reden hier nicht an einander vorbei.
Ich würde am produktiven Hypervisor aka Hetzner Root Server folgende Netzwerkkonfiguration haben:
Also Kommando retur?
Für mich zum Verständnis, welche gravierenden Nachteile/Security bedenken hat meine derzeitige Konfiguration.
Bitte erkläre mir genauer welche Rollen die von dir genannten Interfaces spielen sollen.
en0 = eth0?
br0 = DMZ Interface der pfSense?
viren0 = virtuelles VM Interface?
viren0:1 = ?
Ich hoffe wir reden hier nicht an einander vorbei.
Ich würde am produktiven Hypervisor aka Hetzner Root Server folgende Netzwerkkonfiguration haben:
immer noch ein Satz: die zweite IP darf bei Hetzner nicht direkt an deren "Internet" (also deren Router) hängen, sondern nur gebridged über eth0, einfach weil sonst die MAC der physischen Maschine bei den Punkt-zu-Punkt-Ethernetverbindungen nicht in Erscheinung tritt.
Also nach außen nur ein Weg über die öffentliche IP, alle anderen nur innerhalb Deines Rechtecks in der Zeichnung. (also "nur ein Strich/Weg in das Rechteck")
Was ich zu erklären versuche, Deine Idee wäre nicht generell falsch, nur funktioniert sie nur, wenn der Router/ein VLAN-nutzender Switch in Deiner Hand ist, das ist aber bei Hetzner nicht der Fall.
HG
Mark
Also nach außen nur ein Weg über die öffentliche IP, alle anderen nur innerhalb Deines Rechtecks in der Zeichnung. (also "nur ein Strich/Weg in das Rechteck")
Was ich zu erklären versuche, Deine Idee wäre nicht generell falsch, nur funktioniert sie nur, wenn der Router/ein VLAN-nutzender Switch in Deiner Hand ist, das ist aber bei Hetzner nicht der Fall.
HG
Mark
