Webtropia - zusätzliche IP - Hostroute für pfSense WAN
-
Hallo nochmals,
ich wollte nur noch festhalten, dass folgende Konfig eines Debian direkt am Switch, der auf der phys. Nic meines ESXI angeschlossen ist funktioniert (incoming und outgoing):iface eth0 inet static
address 89.163.249.233
subnet 255.255.255.255
pointtopoint 89.163.146.1
gateway 89.163.146.1Kann man das WAN Port des pfSense in der Art konfigurieren?
Funktioniert das über eine statische Route?Wäre wirklich sehr dankbar für einen Tip, da ich ich jetzt schon 14 Tage damit plage, sehr viel gelesen habe und noch immer auf keine Lösung gekommen bin.
LG
-
Was spricht dagegen die zusätzliche IP als virtual IP auf dem WAN der pfSense zu konfigurieren?
-
Hallo,
ich muss leider ganz blöd fragen: Was erreiche ich durch Definition der zusätzlichen IP als VIP ?Vielleicht hast du mich falsch verstanden. Ich habe nur diese eine IP für den pfsense WAN-Port: 89.163.249.233 und den Gateway 89.163.146.1
Falls du mich nicht falsch verstanden hast Wie müsste da dann die Konfig aussehen, dass man per zusätzlicher IP auf den PfSense kommt (von extern) bzw. vor allem mal raus kommt?
Ich verstehe nicht, welche Route ich da setzen muss.
Der Gateway is ja in einem ganz andren Subnet wie der Wan-Port des pfSense.
Wie "findet" pfsense dorthin?
LG
-
Seit 2.2 ist es möglich, dass eine VIP (u.a. CARP VIP) auch in einem Netz definiert sein darf, die NICHT dem Netz entspricht, die das WAN ansonsten hätte (bzw. wenn ich es richtig in Erinnerung habe, muss das WAN theoretisch gar nicht definiert sein). Das ist insofern von Relevanz, da es bei Clusternmit mehreren Knoten somit unmöglich war, in einem /30er Segment zu arbeiten, in dem technisch nur 2 nutzbare Adressen existieren. Eine davon hat meist der Provider, die andere man selbst. Bis 2.1 war jedoch eine VIP nur dann zu konfigurieren, wenn bereits das WAN IF selbst im gleichen Netz ist, womit man gezwungen war, mind. ein /29er Netz zu nutzen und dann bspw. .1 als VIP, .2/.3 für die einzelnen Devices zu definieren.
https://doc.pfsense.org/index.php/2.2_New_Features_and_Changes#CARP
-> Allow CARP IP address to be outside interface and alias subnetsDa somit die Restriktion aufgehoben ist, dass WAN und VIP im gleichen Netz sein müssen, könnte genau das eine Lösung für dich darstellen.
Ansonsten gibt es aber auch noch IP Alias, die ebenfalls nicht im gleichen Netz sein müssen wie das Interface auf dem sie laufen.https://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses
Kann es BTW sein, dass deine Haupt IP aus dem gleichen Netz kommt, wie das Gateway, welches du bei der zweiten IP bekommen hast? Also 89.163.146.x? Und dass deine Haupt IP auch dieses Gateway .1 hat?
-
Hey, danke für die Infos.
ich hab folgend IPs:
IP-Adressen:
89.163.146.235 (Hauptadresse - hier hängt nur der ESXI dran (Management – nicht änderbar)
dann noch eine auf der der ILO hängt. (nicht verwendbar)Zusätzlich:
89.163.249.233
89.163.249.243Netzadresse: 89.163.146.0
Gateway: 89.163.146.1
Subnetmask: 255.255.255.0 (/24)Ich erwähne nur nochmals: ich habe für den pfSense nur die IP 89.163.249.233 (hier liegen keine weiteren IPs an) vergeben mit GW: 89.163.146.1.
Und die Kernfrage ist: Wie komme ich so vom pfSense raus.
Das eigentliche Ziel war es ja, die zweite zusätzliche IP auch über den Pfsense laufen zu lassen und per 1:1 NAT auf einen weiteren Server in der DMZ zu leiten. Ich scheitere aber schon am Outgoing…
Kann es BTW sein, dass deine Haupt IP aus dem gleichen Netz kommt, wie das Gateway, welches du bei der zweiten IP bekommen hast? Also 89.163.146.x? Und dass deine Haupt IP auch dieses Gateway .1 hat?
Ja genau…
LG
-
Ich erwähne nur nochmals: ich habe für den pfSense nur die IP 89.163.249.233 (hier liegen keine weiteren IPs an) vergeben mit GW: 89.163.146.1.
OK dann ist es tatsächlich knifflig. Die Szenarios die mir bekannt sind haben beide IPs, die erste mit normalem Netz sowie die zusätzlichen auf der pfSense. Somit hat diese ein valides Gateway und die anderen IPs müssen hier nur mit aufgeschaltet sein und werden ggf. auf das GW der OriginalIP gehängt. Wenn die Sense aber NUR die PointoPoint Adresse hat, bin ich mir momentan unschlüssig wie das sinnvoll abbildbar ist.
-
Mir sind mittlerweile schon alle meine restlichen Haare ausgegangen :-).
D.h. im Endeffekt kann es ganz einfach sein, dass eine Konfiguration, wie ich sie mir hier vorstelle gar nicht möglich ist.
Das wäre schade.
Ich will die VMs eigentlich nicht direkt ins WAN setzen.
Gott sei Dank hab ich das mit 1 Monat prepaid abgeschlossen. ;)
Kurze Zusatzinfo, sofern relevant:
Es gibt bei Webtropia 2 Modi, wie die Zusatz-IPs verwendet werden. Entweder für Virtualisierung (bridge), oder Servermode - (routing)Muster bei Routingmode:
auto eth0:1
iface eth0:1 inet static
address aaa.bbb.ccc.ddd
netmask 255.255.255.255Muster bei Bridging:
auto eth0
iface eth0 inet static
address 10.0.2.100
netmask 255.255.255.255
pointopoint 10.0.1.1
gateway 10.0.1.1 -
Dann verstehe ich aber nicht, warum jemand freiwillig bridging macht, wenn er es einfacher routen kann? Wenn ich das Routing Muster verstehe - und da es dort kein explizites Gateway gibt - müssten die Zusatz-IPs ja aus dem gleichen Netz der ursprünglichen IP kommen. Und damit könnten diese ggf. auch dessen normales Gateway benutzen. Kein Grund also für wildes P2P setzen.
Allerdings frage ich mich auch, warum du die pfSense nicht vor alles stellen willst und damit als Gateway für alle Komponenten nutzt - mal vom Hardware ILO abgesehen.
-
Hi,
ann verstehe ich aber nicht, warum jemand freiwillig bridging macht, wenn er es einfacher routen kann? Wenn ich das Routing Muster verstehe - und da es dort kein explizites Gateway gibt - müssten die Zusatz-IPs ja aus dem gleichen Netz der ursprünglichen IP kommen. Und damit könnten diese ggf. auch dessen normales Gateway benutzen. Kein Grund also für wildes P2P setzen.
bei der Bridge muss man lt. deren Wiki point-to-point setzen.
Bei Routing hab ich das Muster so verstanden, dass es ja eine Alias-Schnittstelle ist, oder? Dazu müsste es dann also auch noch eine Hauptadresse auf der jeweiligen VM (pfSense) geben?
Muster bei Routingmode:
auto eth0:1
iface eth0:1 inet static
address aaa.bbb.ccc.ddd
netmask 255.255.255.255Update 06.11.2015: Der Support teilt mit:
ip route add 193.111.140.1 dev eth0 <–---- Hier wird gesagt das das GW über eth0 erreichbar ist
ip route add default via 193.111.140.1 <----- Dieses ist die default route also das alles was nicht direkt erreichbar ist dort hin geschickt wird.Lässt sich sowas mit pfSense einstellen?
…wenn er es einfacher routen kann?
Hm… ist das wirklich einfacher? Egal in welchem Modus: ich komme von den Zusatz-IPs nicht auf den Gateway....
Allerdings frage ich mich auch, warum du die pfSense nicht vor alles stellen willst und damit als Gateway für alle Komponenten nutzt - mal vom Hardware ILO abgesehen.
Dieser Gedanke ist mir auch schon durch den Kopf gegangen. Aber, wie soll ich das anstellen?
Ich müsste die Haupt-IP vom ESXI wegnehmen, damit ich sie auf pfSense (WAN) vergeben kann. (ab hier verliere ich die connection zu ESXI per vSphere Client und kann von extern nicht mehr drauf zugreifen).
Dann müsste ich irgendwie noch auf pfSense kommen, damit ich die entsprechende Konfig aktivieren kann (die Haupt-IP) – geht aber nicht mehr da der vSphere Client nicht mehr erreichbar ist.
Entweder seh ich es zu kompliziert mit dem Nutzen der Hauptip auf pfsense, oder es gibt wirkich keine Möglichkeit die Haupt-IP auf den PfSense (vm) zu bekommen, ohne mich vom vSphere Client abzuschneiden.
LG
-
Kein Grund also für wildes P2P setzen.
Hier ist von Point-To-Point (PTP) die Rede.
P2P = Peer To Peer. Ist was anderes.
;)Derartigen Fragen wie diese gab es hier schon mehrmalig, doch Lösungen wurden nicht genannt. Stichworte: auch "Hetzner".
Soweit ich das mitbekommen habe, ist diese pointopoint (iface) Interface-Konfiguration in pfSense gar nicht machbar. Mglw. gibt es einen Workaround, der auch funktioniert. Bekannt ist mir aber leider auch nichts. -
@virago da hast du recht - es war früh ;)
-
Hallo ihr zwei,
danke für die Informationen. Dann könnte man sagen, dass das Projekt (meines) somit gescheitert ist und man die Maschinen dann nur direkt mit dieser Point2Point Konfiguration in das Netz stellen kann…LG
-
Nein, sehe ich so nicht. Es ist ja wie von Virago genannt auch durchaus bei Hetzner mitunter so gelöst. Allerdings machen die wenigsten den Aufriss mit den 1-2 zusätzlichen IPs, sondern lassen sich hier lieber ein /29er Netz auf die IP routen, was alles wesentlich vereinfacht. Da du ansürichst, dass es bei Webtropia ggf. auch eine Routing Lösung gibt, frage ich mich immer noch, warum diese nicht genutzt wird und alle Maschinen (sinnvollerweise) dann durch die Router VM (pfSense) geschützt werden. Warum möchte ich eine pfSense betreiben und dann trotzdem noch parallel ungeschützt Kisten aufbauen? Vom ILO abgesehen (und selbst da wärs sinnvoll das zu schützen - HP ILOs sind nicht gerade ein Leuchtfeuer der Sicherheit) sehe ich da keinen sinnvollen Nutzen?
Vielleicht musst du einfach deine Anforderungen überdenken, ob diese so Sinn machen oder es nicht einfacher ist, das Konstrukt minimal anders zu bauen als du vorhattest? Bitte als Ideenanstoß verstehen :)
-
Warum möchte ich eine pfSense betreiben und dann trotzdem noch parallel ungeschützt Kisten aufbauen?
Da hast du mich falsch verstanden. Ich würde ja gerne die Routinglösung nehmen, nur verstehe ich nicht, wie ich da dann das Netzwerk konfigurieren muss?
im Wiki von Webtropia wird von eth0:1 gesprochen?
Das ist doch eine Aliasschnittstelle.
Liegen dann hier 2 IPs auf einer VM (respektive am pfSense WAN) 1 x die "normale Schnittstelle" und die Alias? Und vor allem welche IPs vergebe ich dann hier?
Vor allem habe ich ja das Problem noch immer das mir das Gateway in einem anderen Subnet ist, oder sehe ich das nicht richtig? (das Problem bleibt bestehen)…
LG
-
Vor allem habe ich ja das Problem noch immer das mir das Gateway in einem anderen Subnet ist, oder sehe ich das nicht richtig? (das Problem bleibt bestehen)…
Nein hast du laut deiner Aussage oben nicht, denn laut deiner Info war bei Routed kein Gateway im anderen Subnetz? Das Binden von Routen auf das Interface sollte zumindest via Console möglich sein und dementsprechend sich im Notfall via eines rc.local Skriptes lösen lassen.
-
Hi,
Nein hast du laut deiner Aussage oben nicht, denn laut deiner Info war bei Routed kein Gateway im anderen Subnetz?
Der Gateway ist immer im andren Subnetz. Egal ob routed oder bridged.
Der Gateway bleibt im andren Subnetz.
Kann ich das dennoch lösen?
Das Binden von Routen auf das Interface sollte zumindest via Console möglich sein
Hab das Ganze mal mit IP-Fire getestet.
EDIT:
ip route add 89.163.146.1/32 dev red0 (für die WAN NIC)Dennoch bleiben externe IPs zb 8.8.8.8 unreachable.
Wenn ich auf das entsprechende Interface eine Route binde ist es egal, ob das Gateway in einem andren Subnetz ist? Der nächste "Hop" sollte ja dann eigentlich zumindest zu einem Router gehen, der mit einem Interface im gleichen Subnetz ist?
LG und danke für deine Geduld.
-
Kleines Update zur Situation:
Bei Webtropia wird im "Routingmodus" der dort "Server-IP" genannt wird, alles auf die Haupt-IP geroutet. Die Haupt-IP liegt jedoch für den ESXI Host an.Sprich - auf diese IP greift man zu, wenn man mit dem Vsphere Client auf den Host zugreifen will.
Da es keine zweite IP gibt, die den Gateway im gleichen Netz hat bzw. die Zusatz-IPs nicht im gleichen Subnet wie der Gateway sind, sehe ich hier keine Lösung den pfSense (eigentlich egal welche Routing VM) sinnvoll einzusetzen.
Wenn auf die Haupt IP geroutet wird, der pfSense aber dort nicht "lauscht" (WAN), hat es sich wohl mit NAT, Forwarding etc.
Ich denke hier wird man dann wohl eine routingfähige Virtualisierunsplattform einsetzen müssten (zb Xenserver).
LG
-
Da es keine zweite IP gibt, die den Gateway im gleichen Netz hat bzw. die Zusatz-IPs nicht im gleichen Subnet wie der Gateway sind, sehe ich hier keine Lösung den pfSense (eigentlich egal welche Routing VM) sinnvoll einzusetzen.
OK dann ist das wohl wirklich gestorben. Bei Hetzner gibt es hier bei einzelnen Zusatz-IPs immer ein ordentliches Gateway und die Möglichkeit, sich ein kleines Netz (/29 bspw.) dann auf diese IP leiten zu lassen. Damit ist eine vernüftigte Strukturierung gar kein Problem. Aber so macht Virtualisierung bei Webtropia wirklich keinen Spaß :/ -
Hi,
ja scheint so – das wars dann wohl.Bei Hetzner verstehe ich halt noch immer nicht, weshalb ich dieses instabile Verhalten habe. (siehe anderer Post). Liegt nicht an pfSense. Und ich glaube auch den richtig konfiguriert zu haben.
No fun, trotz toller Routing-VM ;-)
-
Bei Hetzner war ich einige Jahre lang mit solch einem Konstrukt (original IP des Servers auf ESXi für Notfälle, zusätzliche IP mit /29er Netz für pfSense und Server dahinter). Hatte problemlos funktioniert.