Proxmox + PfSense

nycon

Soo nun funktioniert die sache ;)
Ich werde noch eine ausführliche Anleitung schreiben und sie hier Posten.
Da ich sicher bin das auch ein Paar Leute am verzweifeln sind.

Somit Closed

logo78

Hey nycon,

ja, ich bin am verzweifeln - Hilfe :D

Habe einen RootServer mit Proxmox laufen. Ich bin begeistert.
Habe die letzten Tage verschiedene VMs installiert, per NAT ins Inet gebracht.
Alles Bestens. Port Forwarding in die VMs rein habe ich auch hinbekommen.

Nun möchte ich eine pfSense einrichten, die quasi meine Public-IP als WAN-interface nutzt und
an einem zweiten virtuellen Interface eine LAN Karte bekommt, auf die ich dann auch die anderen VMs dranhänge.
Ich habs nicht hinbekommen. Ich denke, da ist noch irgendwo ein Fehler in meiner /etc/network/interfaces.

Danke..

Edit: ich habe herausgefunden das man für die virtIO LAN Karte 'Disable Hardware Checksum Offloading' deaktivieren muss.
Keine Ahnung wie das über die Shell geht. Habe mal die Karten auf E1000 in Proxmox umgestellt. Jetzt pingt er wenigsten die vmbr0/vmbr1 IP's an.
So sieht man eine Interfaces aus.. Ich habe das noch nicht richtig verstanden. Ja.. muss mehr darüber lesen..
Problem: muss in der Konfig die IP festlegen, da Proxmox eine IP benötigt und ich sonst nicht mehr draufkommen würde.

Mein Hoster erlaubt keine weiteren MACs an seinem Switch, als wie die MAC der ens3. ~~Routing~~ Bridging sieht also schlecht aus.
Darum denke ich, dass ich über eine virtuelle NIC auf die ens3 'natten' muss, oder sehe ich das falsch?


auto lo
iface lo inet loopback

#physikalische netzwerkkarte mit public-ip
auto ens3
iface ens3 inet static
        address  xxx.xxx.143.20
        netmask  255.255.252.0
        gateway  xxx.xxx.140.1
        post-up echo 1 > /proc/sys/net/ipv4/conf/ens3/proxy_arp

#wan karte von pfsense
auto vmbr0
iface vmbr0 inet static
        address  10.10.1.1
        netmask  255.255.255.0
        bridge_ports none
        bridge_stp off
        bridge_fd 0

#natten über die ens NIC
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up iptables -t nat -A POSTROUTING -s '10.10.1.0/24' -o ens3 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '10.10.1.0/24' -o ens3 -j MASQUERADE

        #VM-RDP HTTPS 443:10.10.1.1:443
        post-up iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 443 -j DNAT --to 10.10.1.1:443
        post-down iptables -t nat -D PREROUTING -i ens3 -p tcp --dport 443 -j DNAT --to 10.10.1.1:443

#das wird dann die LAN Karte von pfsense
auto vmbr1
iface vmbr1 inet static
        address  10.10.2.1
        netmask  255.255.255.0
        bridge_ports none
        bridge_stp off
        bridge_fd 0

Edit2: Typo: ~~Routing~~ durch Bridging ersetzt

nycon

HI logo78

Ja da habe ich mir auch die Zähne ausgebissen.
Ich habe das so gelöst das ich ein subnet auf eine öffentlich ip gelegt habe und von dort aus das Subnet geroutet.

Danach kannst du im Proxmox die Schnittstelle definieren für das WAN. Wicht ist hier das du unbedingt die Intel karte nimmst ansonsten geht nix mehr.
Das mit der zusätzlich mac für die IP kannst du auch getrost vergessen wichtig sit nur das du sicher bisst das die IP auch wirklich eine /32 Adresse ist.
Wichtig ist auch das sysctl -w net.ipv4.ip_forward=1 Gesetz ist. dies muss vor der Configuration vorn Proxmox passieren. Ansonsten zeigt er dir den Stinkefinger :-)

Bezüglich virtIO LAN Karte habe ich auch so meine Probleme gehabt es gibt eine Möglichkeit beim Booten das Menü anzupassen resp. die Parameter hinzuzufügen.
Wenn das nicht geht dann installiere die ganze Sache mit Intel LAN Karten danach die Umstellung der Boot conf kann man ganz bequem über das PFSense GUI machen.

auto lo
iface lo inet loopback

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
        address  78.46.86.67
        netmask  255.255.255.255
        gateway  78.46.86.65
        broadcast  78.46.86.95
        bridge_ports none
        bridge_stp off
        bridge_fd 0
        pointopoint 78.46.86.65

        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        up ip route add 78.46.67.19/32 dev vmbr0
        up ip route add 188.40.233.49 via 78.46.67.19 dev vmbr0
        up ip route add 188.40.233.50 via 78.46.67.19 dev vmbr0
        up ip route add 188.40.233.51 via 78.46.67.19 dev vmbr0
        up ip route add 188.40.233.52 via 78.46.67.19 dev vmbr0
        up ip route add 188.40.233.53 via 78.46.67.19 dev vmbr0
        up ip route add 188.40.233.54 via 78.46.67.19 dev vmbr0

auto vmbr1
iface vmbr1 inet manual
        bridge_ports none
        bridge_stp off
        bridge_fd 0

auto vmbr2
iface vmbr2 inet manual
        bridge_ports none
        bridge_stp off
        bridge_fd 0

auto vmbr3
iface vmbr3 inet manual
        bridge_ports none
        bridge_stp off
        bridge_fd 0

Hoffe das hilft.

Gruess
Nycon

logo78

Ich habe es hinbekommen. Zwei schlaflose Nächte und vieel mehr gelesen :)
Habe es anders gelöst. Ich sage mal besser ;D 8)
pfSense bekommt als WAN-IP 10.10.1.2 / GW: 10.10.1.1
LAN in pfSense kann frei bestimmt werden.
Wichtig:

Grundsätzlich sollte man für die Erstkonfiguration auf der Browser-Ebene eine VM über LAN einrichten. Sonst wird das alles nur unnötig schwer.
Wenn man das nicht tut war es bei mir so, dass ich die GW selbst festlegen musste mit route add default 10.10.1.1 bzw mit route change default 10.10.1.1
Das kann auch daran gelegen haben, das ich beim ersten mal eine andere/falsche GW in der Shell (Set IP) eingegeben hatte. Später habe ich dann gesehen, dass die drinn blieb als default GW
Disable Hardware Checksum Offloading unbedingt abschalten (WebFrontEnd) oder keine virtIO LAN NIC nehmen
Wenn man ein PortForwarding einrichtet und die Firewall mit pfctl -d abschaltet um über WAN an das WebFront-End zu kommen (bei mir wäre das Port 34980), kriegt
man immer eine 'HTTP_referer" Störmeldung. Das kann man zwar auch abschalten, aber über das WebFrontEnd.

Zusammengefasst - eine VM mit einem Browser auf der LAN-Seite von pfSense sollte vorhanden sein.

Meine funktionierende Konfiguration:

auto lo
iface lo inet loopback

#defining interface card with wan-ip (physical LAN NIC)
auto ens3
iface ens3 inet static
        #Public IP & GW
        address  185.xxx.xxx.20
        netmask  255.255.252.0
        gateway  185.xxx.xxx.1
        #Enable NAT
        post-up echo 1 > /proc/sys/net/ipv4/conf/ens3/proxy_arp

#Virtuell WAN-Iface for pfSense
auto vmbr0
iface vmbr0 inet static
        address  10.10.1.1
        netmask  255.255.255.0
        bridge_ports none
        bridge_stp off
        bridge_fd 0
        #Forward everything to ens3 (physical netword card)
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up iptables -t nat -A POSTROUTING -s '10.10.1.0/24' -o ens3 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s '10.10.1.0/24' -o ens3 -j MASQUERADE
        #Only for Test/temporary - to check if the pfSense is reachable from WAN 
        #firewall in pfSense has to be configured for this
        post-up iptables -t nat -A PREROUTING -i ens3 -p tcp --dport 34980 -j DNAT --to 10.10.1.2:80
        post-down iptables -t nat -D PREROUTING -i ens3 -p tcp --dport 34980 -j DNAT --to 10.10.1.2:80

#Virtual LAN Bridge / here will connect all VMs on pfSense
auto vmbr1
iface vmbr1 inet manual
        bridge_ports none
        bridge_stp off
        bridge_fd 0

Zu deinem Vorschlag hätte ich dennoch ein paar Fragen - will es verstehen.

@nycon:

Dies muss vor der Configuration vorn Proxmox passieren.

a)Vor Proxmox? Du meinst sicherlich in Proxmox, oder nicht?

auto vmbr0
iface vmbr0 inet static
address 78.46.86.67
netmask 255.255.255.255
gateway 78.46.86.65
broadcast 78.46.86.95
bridge_ports none
bridge_stp off
bridge_fd 0
pointopoint 78.46.86.65

b)Wäre hier die '78.46.86.67' die einzige verfügbare public IP?

bridge_ports eth0
bridge_stp off
bridge_fd 0

c)Eine zweite Bridge Anweiseung in demselben iface block - kann das funktionieren?

up ip route add 78.46.67.19/32 dev vmbr0
up ip route add 188.40.233.49 via 78.46.67.19 dev vmbr0
up ip route add 188.40.233.50 via 78.46.67.19 dev vmbr0
up ip route add 188.40.233.51 via 78.46.67.19 dev vmbr0
up ip route add 188.40.233.52 via 78.46.67.19 dev vmbr0
up ip route add 188.40.233.53 via 78.46.67.19 dev vmbr0
up ip route add 188.40.233.54 via 78.46.67.19 dev vmbr0

Diesen Bereich verstehe ich eigentlich nicht…
d)Ist die '78.46.67.19/32' die virtuelle WAN-IP für pfSense?
e)Gibt es einen Grund, warum du nicht gleich für den ganzen Bereich eine Route festlegst aka:
post-up route add -net 188.40.233.48 netmask 255.255.255.248 gw 78.46.67.19
f)Wer die IPs 188.40.233.xx von den VMs genutzt?
LAN-IPs könnte doch pfSense vergeben und würde die ne nach Einstellung direkt in pfSense in das WAN geroutet werden…

JeGr

address 185.xxx.xxx.20
netmask 255.255.252.0
gateway 185.xxx.xxx.1

WTF? Wofür definierst du da einen /22er Public IP Space? Du sprachst doch von einem /29er Netz an Public Adressen. Oder ist das dein LAN? Dann wäre es hochgradig unschön da Public Adressen zu nutzen, noch dazu ein /22er aus einem Bereich der garantiert vergeben ist :o

logo78

@JeGr:

WTF?

Ich definiere nichts.
Das ist die fest vorgegebene Public-IP incl SubnetMask+GW von meinem Hoster (steht auch als Zeilenkommentar dabei).
Das 3.Oktett der GW liegt drei Nummern weiter hinten als wie das 3.Oktett die Public-IP.
e.g.
IP: 123.456.203.20
GW:123.456.200.1

Wenn du mir sagst, wie ich das mit einem /29er Netz hinbekomme - zahle ich ein Bier.

Ok,ok.. das konntest du nicht wissen ;D

wtf.png_thumb

JeGr

Naja du schreibst das ist deine funktionierende Konfiguration, also gehe ich davon aus, dass das von dir stammt ;)

Also hast du eine(?) 185er IP als Public bekommen? Dann ist das halbwegs verständlich auch wenn ichs erstaunlich finde, dass du vom Hoster einfach eine einzelne IP aus nem /22er Subnetz bekommst. Sehr ungewöhnlich, solche großen Broadcast Domänen wo sich Kunden gegenseitig stören könnten. Aber hey, ich muss es nicht entstören :D

logo78

Störung?
Ich habe es zwar nicht ausprobiert, aber ich wäre doch sehr überrascht, wenn mein Host/Server auf LAN-Ebene irgendeine andere IP, wie die des GW erreichen würde.

Ansonsten finde ich diese neue Erkenntnis von dieser "nested KVM" in Verbindung mit pfSense genial.
Für Laborversuche, wenn Leistung nicht ausschlaggebend ist das eine Supersache.
Preislich um einiges attraktiver als Amazon EC2, Google Clouding, etc…

btw, meine next Steps:

in Proxmox Firewall aktivieren und alle Ports auf der WAN Seite blockieren - mit der Ausnahme von 443/OpenVpn
die 443 auf die pfSense-VM forwarden - per VPN komme ich auf die pfSense und durch pfSense hindurch komme ich dann auf den Administrationsport von Proxmox.
Muss nur irgendwie den Port in der Proxmox-Firewall auf vmbr0 'binden'
eine Core Win2016 Essentials / FreeIPA als LDAP Server für zentrale Benutzerverwaltung für alle künftigen VMs
und paar VMs zum expirementieren..
falls gar nichts mehr geht, gibt es eine tolle Shell in meinem Serverpanel (Guacamole glaube ich), welches immer funktioniert :)

JeGr

Störung?

Nein du mißverstehst: Nicht deine Konfiguration ist eine Störung oder du hast eine. Ich beneide nur den Techniker beim Provider nicht, wenn der eine so große Domain entstören soll weils irgendwo knallt. Und wenn dann noch irgendwelche dusseligen MAC Filter irgendwo draufliegen, machts das Netzwerk nicht schöner ;) Könnte man auch anders machen, aber deshalb ein PAL :)

logo78

I see. Es werden wohl finanzielle Aspekte sein, wenn man sich die Eine oder Andere GW durch das größere Subnetz/22 einsparen kann (selbst wenn es nur virtuelle Gateways wären).
Hilf mir mal; PAL? Du meinst sicherlich nicht eine Panzerabwehrlenkwaffe? ;D

JeGr

Naja weniger finanziell meist eher gewachsen oder komplett anders aufgebaut. Vielleicht steckt auch mehr dahinter, anyway :)

PAL - Problem anderer Leute :D In dem Fall die Netzwerker beim Anbieter/Provider ;) Wenn die mit v6 ähnlich arbeiten wie hier mit v4 gibt das Spaß :D

Aber back to topic, ich will das hier ja nicht komplett OT bringen :)