aalbang
Goto Top

Portforwarding bei MultiWAN mit Gateway im selben Subnetz

Ich habe einen Dedizierten Root Server mit Virtualisierung und 3 öffentlichen IP-Adressen im selbsen Subnetz und dem selben Gateway. Eine IP-Adresse wird bereits für das Management des Hypervisors benötigt und ist bei dem Problem irrelevant.

Die Firewall VM besitzt 3 Netzwerkschnittstellen: WAN1 = eth0, WAN2 = eth1, LAN1 = eth2 Die verbleibenden 2 IP Adressen sind meiner Firewall zugeteilt (WAN1,WAN2) und sollen beide mit dem selben Default Gateway (MultiWAN) genutzt werden. Durch "ip route" und "ip rule" habe ich es mittlerweile geschafft das ich beide Schnittstellen anpingen kann und direkt auf der FirewallVM verwendet werden kann. Masquerading mit funktioniert für die internen Maschinen soweit auch.

Leider funktioniert in der aktuellen Konfiguration das Portforwarding immer nur bei einem der beiden Interfaces. Beim Starten der Firewall immer die Portforwardings des Interfaces welches als erstes UP ist. Beim einem "ifdown" auf das funktioniernde Interface funktioniert, anschließend das Forwarding das anderen Interfaces.

Leider hab ich nichts gefunden wie ich das Problem lösen kann. Hab nicht wirklich Erfahrung mit iproute2. Virtuelle Interfaces kann ich leider auch nicht Verwenden, da das Gateway die richtige Absender MAC für die IP vorraussetzt.

EDIT:
Aktuell wird auch hier das Thema behandelt:
Ubuntuusers


Hier mein aktuelles Firewallstartscript:
export IFWAN2=eth1
export WAN2IP=x.x.x.102
export WAN2GWIP=x.x.x.97

export IFLAN1=eth2
export LAN1IP=192.168.x.1


###LAN Server IPs
export WIN2008R201=192.168.x.3


#######Grundlegende Konfiguration
#Module für das Connection Tracking laden
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
modprobe ip_conntrack_irc

# default-Policies setzen, Tabellen leeren und loeschen / NAT regeln für Multiwan bleiben erhalten
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

iptables -t nat -P PREROUTING  ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT      ACCEPT

iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -X


#Routing aktivieren
echo 1 > /proc/sys/net/ipv4/ip_forward

#MultiWAN
ip route add default via $WAN1GWIP dev $IFWAN1 tab 1
ip route add default via $WAN2GWIP dev $IFWAN2 tab 2
ip rule add from $WAN1IP/32 tab 1 priority 500
ip rule add from $WAN2IP/32 tab 2 priority 600
ip route flush cache

####### Allow Regeln LAN/WAN between Firewall
#Loopback Verkehr erlauben
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT  -i lo -j ACCEPT

#Erlaube ICMP Echo Requests (eingehend / ausgehend)
iptables -A INPUT -p icmp --icmp-type 8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p icmp --icmp-type 8 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 0 -m state --state ESTABLISHED,RELATED -j ACCEPT

#Erlaube DNS Abfragen (ausgehend)
iptables -A OUTPUT -p udp --dport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p udp --sport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --sport 53 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

##Erlaube jeden Verkehr
#iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
#iptables -A INPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

#Erlaube INPUT und OUTPUT für das interne Netzwerk
iptables -A OUTPUT -o $IFLAN1 -j ACCEPT
iptables -A INPUT  -i $IFLAN1 -j ACCEPT

######## Allow Regeln LAN-to-WAN
#Erlaube LAN > WAN (Masquerading in NAT)
iptables -t nat -A POSTROUTING -o $IFWAN1 -j MASQUERADE
iptables -t nat -A POSTROUTING -o $IFWAN2 -j MASQUERADE

#Erlaube den internen LAN Verkehr (Ansonsten geht kein Masquerading)
iptables -A FORWARD -i $IFLAN1 -j ACCEPT
iptables -A FORWARD -o $IFLAN1 -j ACCEPT


####### Port Forwarding WAN-to-LAN  (!!!!!!!!!!! Aktuell funktioniert immer nur das Portfowarding von einem der beiden Interfaces)
###Forward $IFWAN1
iptables -t nat -A PREROUTING  -p tcp -m tcp -d $WAN1IP --dport 80 -j DNAT --to-destination $WIN2008R201:80
iptables -A FORWARD -m state -p tcp -d $WIN2008R201 --dport 80 --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -p tcp -m tcp -s $WIN2008R201 --sport 80 -j SNAT --to-source $WAN1IP

###Forward $IFWAN2  ###
iptables -t nat -A PREROUTING  -p tcp -m tcp -d $WAN2IP --dport 3389 -j DNAT --to-destination $WIN2008R201:3389
iptables -A FORWARD -m state -p tcp -d $WIN2008R201 --dport 3389 --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -p tcp -m tcp -s $WIN2008R201 --sport 3389 -j SNAT --to-source $WAN2IP

Content-ID: 243507

Url: https://administrator.de/contentid/243507

Ausgedruckt am: 05.11.2024 um 12:11 Uhr

aqui
aqui 12.07.2014 um 18:04:00 Uhr
Goto Top
2 IP Adressen sind meiner Firewall zugeteilt (WAN1,WAN2) und sollen beide mit dem selben Default Gateway (MultiWAN) genutzt werden.
Was soll da der tiefere Sinn sein ??
Load Balancing wäre ja sinnfrei bei Verwendeung ein und desselben Gateways ?!

Die Kardinalsfrage die sich hier stellt ist die warum du dir das Leben so schwer machst und nicht eine fertige Firewall VM mit einem GUI benutzt wie z.B. die pfSense ??
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
(Das ist jetzt die Hardware Variante aber von der pfSense Seite kannst du ein fertiges VM Image laden !)
Da ist deine Einrichtung ein Kinderspiel und 3 Mausklicks im GUI.
Aber warum einfach machen wenn kompliziert auch geht...
aalbang
aalbang 12.07.2014 aktualisiert um 18:28:17 Uhr
Goto Top
pfSense und sonstige BSD basierte Firewall funktioniert nicht da die Firewall mit HyperV virtualisiert ist und diese hier leider noch nicht funktionieren.
Ich habs nämlich schon probiert.
(Bitte keine Diskusion über den HyperVisor)

Warum ich 2 Gateways brauche. Weil die beiden öffentlichen IP Adressen die ich habe, leider den selben Gateway nutzen.
Virtuelle IP auf gleichem Interface geht leider auch nicht, da der Anbieter nur die IPs zulässt zu dem die zugwiesene MAC passt.

Es handelt sich hier um einen Dedizierten Server in einem Rechenzentrum. Hier sind alle Maschinenen und Netzwerke bis auf den HyperVisor virtualisiert.
aqui
aqui 12.07.2014 aktualisiert um 21:01:55 Uhr
Goto Top
mit HyperV virtualisiert ist
Igitt...wer macht denn sowas ?! Aber richtig, keine Diskussion du weisst was du tust und bekommst dann auch die FW die du verdienst.
Weil die beiden öffentlichen IP Adressen die ich habe, leider den selben Gateway nutzen.
Und was ist denn der tiefere Sinn 2 WAN Interfaces zu haben...ist ja dann irgendwie sinnfrei und könnte mal lieber mit einem LACP LAG verwenden. Da hat man dann wenigstens Redundanz und Bandbreitenerhöhung und spart eine IP !
da der Anbieter nur die IPs zulässt zu dem die zugwiesene MAC passt.
Na ja die Mac lässt sich, wie jeder weiss, in jedem OS kreativ "anpassen" face-wink ifconfig <port> hw ether <MAC_ADRESSE> und schon kannst du das für alleInterfaces pass machen.
Hier sind alle Maschinenen und Netzwerke
Netzwerke wohl kaum ! Wie sollte das auch gehen... aber keine Diskussion !
Klingt aber irgendwie nach Murks was du da machen willst...
aalbang
aalbang 13.07.2014 aktualisiert um 00:41:44 Uhr
Goto Top
OK. Sry falls ich ein bisschen Harsch rübergekommen bin.
Hab mich nur schon zu viel geärgert.

Es handelt sich hier übringends nur um einen einzelnen privaten dedicated Server mit 1ner Netzwerkkarte dem 3 öffentliche IPAdressen zugeteilt sind.
Jeder dieser IP-Adressen ist vom Provider ein zu verwendende MAC-Adresse zugeteilt.

Zum Thema HyperV / VMware. Ja. ich würde auch lieber VMware verwenden, allerdings unterstützt der kein Softwareraid und deswegen HyperV.
HW-Raidcontroller nur damit ich nen ESXi ausfallsicher betreiben kann wären wieder 20€ mehr im Monat gewesen.

Für LACP LAG müssten das beide Seiten unterstützten.
Außerdem geht es hier auch nicht um Bandbreite oder Redundanz, da eh nur eine wirkliche physikalische Schnittstelle zur Verfügung steht.
Es geht hier um die optimale Ausnutzung der TCP/UDP Ports die mir zur Verfügung stehen. Das Loadbalancing von Intern nach Extern ergibt
sich einfach aus der Tatsache das ich 2 Standardgateways habe.

Das ich MAC Adressen über das OS ändern kann ist mir schon klar. Die MAC Adressen passen ja auch, da ich die über den Hypervisor eh eintragen kann.
Hier ist es um den Punkt gegangen das ich nicht einfach 2 IPs an ein Interface binden kann, da ich ansonsten 2 IPs auf einer MAC Adresse hätte, was
wiederrum von meinem Provider ja leider nicht erlaubt ist (wird blockiert). Dadurch hat sich das Problem ja auch erst ergeben.

Ist aber auch egal. Ich hab mittlerweile eine Lösung für mein Problem gefunden:
forum.ubuntuusers.de/topic/portforwarding-bei-multiwan-mit-gateway-im-sel
Webkamer
Webkamer 13.07.2014 um 10:25:38 Uhr
Goto Top
Hallo aalbang,

ich kann dir zu deinem eigentlichen Problem zwar nicht weiterhelfen, aber ich möchte darauf hinweisen, dass pfSense schon unter Hyper-V lauffähig ist.
Ich setzte pfSense schon seit einem halben Jahr virtuallisiert auf einem Hyper-V ein und das funktioniert einwandfrei. Das fertig Hyper-V Image
findest du hier: https://forum.pfsense.org/index.php/topic,56565.msg364122.html#msg364122 und ist mit wenigen klicks installiert.

Besten Gruß
webkamer
brammer
brammer 14.07.2014 um 14:22:21 Uhr
Goto Top
Hallo,

dass pfSense schon unter Hyper-V lauffähig ist. Ich setzte pfSense schon seit einem halben Jahr virtuallisiert auf einem Hyper-V ein

Ich gehe mal davon aus das sich @aqui seine Aussage auf die Virtualisierung einer Firewall bezieht und nicht auf Hyper-V

Es stellt sich die Frage ob ich mit einer Virtualisierten Firewall nicht ein viel zu hohes Risiko eingehe.
Damit hast du auf einmal 3 angreifbare Systeme.
Die Firewall, repsektive das OS.
Den Hyper-V
und das Betriebssystem unter dem der Hyper-V läuft.

Und eine an sich sichere Firewall auf eine Microsft Betriebssystem zu virtualisieren ist, nun sagen wir mal Semi Optimal.

brammer
aqui
aqui 15.07.2014 um 10:12:30 Uhr
Goto Top
Ich gehe mal davon aus das sich @aqui seine Aussage auf die Virtualisierung einer Firewall bezieht
Ja, richtig !
Es stellt sich die Frage ob ich mit einer Virtualisierten Firewall nicht ein viel zu hohes Risiko eingehe.
Richtig, das sieht jeder so der sich seriös mit Security beschäftigt !