117
Routing zwischen 2 IPCops im lokalen Netzwerk
Hallo zusammen,
ich weiss nicht ob der Titel aussagekräftig genug ist, aber ich versuche mal mein Problem ausführlich zu beschreiben.
Und zwar habe ich eine Telekom Internetleitung, die leider nur 2 Mbit liefert.
Irgendwann hat sich ein lokaler Anbieter dazugesellt und bot mir 50Mbit.
Da der neue Anbieter zuerst nicht so stabil lief, da keine Glasfaser sondern Richtfunk in das Dorf eingesetzt wurde, habe ich beide Anschlüsse jetzt parallel laufen.
Dementsprechen habe ich jetzt 2 IPCops. An PFSense traue ich mich nicht und so bin ich auch zufrieden, wenn ich nicht ein problem hätte.
Der Cop-1 nutzt den lokalen Anbieter und hat IP 192.168.1.2 dieser macht auch DHCP
Der Cop-2 nutzt die Telekom und hat die IP 192.168.1.3
Es gibt einen kleinen Dienst, der keinen Traffic verursacht, aber stabiles Internet verlangt, diesen lasse ich über die Telekom leitung laufen.
Dementsprechend wurde über den DHCP dem einen Client worauf der Dienst läuft DNS und Gateway auf die 1.3 gelegt.
Das funktioniert soweit, alles ist von aussen erreichbar, da über das Telekom Netz und ich kann lokal wenn ich mich im Heimnetz befinde auch
direkt auf diesen einen Rechner mit der IP 192.168.1.5 drauf. SSH, FTP was auch inmmer alles funktioniert.
Wenn ich mich jetzt aber via VPN über den 1. Cop in das Heimnetz einwähle, kann ich eigentlich alles im Heimnetz vom handy aus beispielweise erreichen.
Mailserver, Webserver, alles was im lokalen Netz läuft ist über VPN abrufbar, wenn diese Geräte auch DNS und Gateway vom 1. Cop eingetragen bzw. bekommen haben.
Der eine Rechner mit der IP 192.168.1.5 welcher DNS und Gateway auf die 1.3 bekommen hat ist über VPN nicht erreichbar.
Da passen die Routen/Rückrouten oder was auch immer nicht.
Eine Portweiterleitung aus dem Gastnetz (Blau) auf diesen Rechner geht aus den selben Gründen auch nicht.
Meine Frage an Euch ist jetzt ob ich beim IPCop irgendwie eine Route etc. einrichten kann, damit genau das funktioniert?
Vielleicht lässt sich diese manuelle Route dann ja auf Gegenseitigkeit der beiden Cops einstellen.
ich weiss nicht ob der Titel aussagekräftig genug ist, aber ich versuche mal mein Problem ausführlich zu beschreiben.
Und zwar habe ich eine Telekom Internetleitung, die leider nur 2 Mbit liefert.
Irgendwann hat sich ein lokaler Anbieter dazugesellt und bot mir 50Mbit.
Da der neue Anbieter zuerst nicht so stabil lief, da keine Glasfaser sondern Richtfunk in das Dorf eingesetzt wurde, habe ich beide Anschlüsse jetzt parallel laufen.
Dementsprechen habe ich jetzt 2 IPCops. An PFSense traue ich mich nicht und so bin ich auch zufrieden, wenn ich nicht ein problem hätte.
Der Cop-1 nutzt den lokalen Anbieter und hat IP 192.168.1.2 dieser macht auch DHCP
Der Cop-2 nutzt die Telekom und hat die IP 192.168.1.3
Es gibt einen kleinen Dienst, der keinen Traffic verursacht, aber stabiles Internet verlangt, diesen lasse ich über die Telekom leitung laufen.
Dementsprechend wurde über den DHCP dem einen Client worauf der Dienst läuft DNS und Gateway auf die 1.3 gelegt.
Das funktioniert soweit, alles ist von aussen erreichbar, da über das Telekom Netz und ich kann lokal wenn ich mich im Heimnetz befinde auch
direkt auf diesen einen Rechner mit der IP 192.168.1.5 drauf. SSH, FTP was auch inmmer alles funktioniert.
Wenn ich mich jetzt aber via VPN über den 1. Cop in das Heimnetz einwähle, kann ich eigentlich alles im Heimnetz vom handy aus beispielweise erreichen.
Mailserver, Webserver, alles was im lokalen Netz läuft ist über VPN abrufbar, wenn diese Geräte auch DNS und Gateway vom 1. Cop eingetragen bzw. bekommen haben.
Der eine Rechner mit der IP 192.168.1.5 welcher DNS und Gateway auf die 1.3 bekommen hat ist über VPN nicht erreichbar.
Da passen die Routen/Rückrouten oder was auch immer nicht.
Eine Portweiterleitung aus dem Gastnetz (Blau) auf diesen Rechner geht aus den selben Gründen auch nicht.
Meine Frage an Euch ist jetzt ob ich beim IPCop irgendwie eine Route etc. einrichten kann, damit genau das funktioniert?
Vielleicht lässt sich diese manuelle Route dann ja auf Gegenseitigkeit der beiden Cops einstellen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 299127
Url: https://administrator.de/contentid/299127
Printed on: April 19, 2024 at 12:04 o'clock
117 Comments
Latest comment
Der eine Rechner mit der IP 192.168.1.5 welcher DNS und Gateway auf die 1.3 bekommen hat ist über VPN nicht erreichbar. Da passen die Routen/Rückrouten oder was auch immer nicht.
Du hast es erfasst !Der würde es ja über ein anderes Gateway schicken und damit kommen Antwortpakete an deinem Client mit einer anderen IP Adresse an was zum sofortigen Sessionabbruch im TCP/IP führt.
In deinem Konstrukt musst du dich für einen Router / Firewall entscheiden anders geht das nicht.
Mit der pfSense könntest du einen Dual WAN Port Rouuter / Firewall realisieren, die das Problem sofort fixt.
https://doc.pfsense.org/index.php/Multi-WAN
Warum traust du dich nicht...ist doch kinderleicht:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
und du hast sehr viele Optionen mehr und ein erheblich besseres GUI zum konfigurieren !!
Ansonsten ohne wechsel wäre ein Dual WAN Port Router wie der Draytek 29xx, Linksys LTE644 usw. usw die bessere Wahl außer der pfSense natürlich, denn technisch ist es so mit der 2 mal IPCop Lösung nicht hinzubekommen.
Es hat ja per se nichts mit den Cops zu tun sondern mit den festen Gateways der Endgeräte.
Du könntest aber noch folgendes versuchen.
Richte auf dem betreffenden Endgerät eine statische Route ein nur für diese Anwendung als:
route add >zielnetz> maske <maske> <ipcop_ip> -p
Das sollte ggf. ebenso das Problem fixen.
Nachteil ist aber das du für alle Ziele eine statische Route definieren musst und außerdem funktioniert das nur wenn das Ziel keine dynamsichen IPs hat, also der Client z.B. in wechselnden IPs ist.
Hallo
Danke für Deine ausführliche Antwort.
Zu den Routen, da Stelle ich mich etwas unbeholfen an.
Einfach gar keine Erfahrung mit.
Also Cop 1 192.168.1.2
Cop 2 192.168.1.3
Client mit den Dienst 192.168.1.5 dieser hat 1.3 als DNS und Gateway.
Es wird alles über dhcp vergeben, aber immer fest zugeordnet.
Vpn hat das Subnet 10.0.0.0
Dementsprechend 6 am Ende e.t.c.
Wie würde da die Route lauten und vor allem wohin?
Zum Thema Pfsense:
Es ist Englisch, gut das würde noch gehen, aber mir fehlt da was am DHCP.
Und zwar gibt es auch noch den Nachbarn.
Es läuft ohne eigenes Subnet.
Die Clients von drüben bekommen von meinem DHCP IPs.
Ich gebe denen dann aber einen anderen Gateway und dns mit, damit diese die Internet Leitung vom Nachbarn nutzen.
Diese Funktion habe ich bisher nur beim Cop gesehen oder geht das auch mit pfsense?
Dann würde ich sonst mal in einer vm testen
Danke für Deine ausführliche Antwort.
Zu den Routen, da Stelle ich mich etwas unbeholfen an.
Einfach gar keine Erfahrung mit.
Also Cop 1 192.168.1.2
Cop 2 192.168.1.3
Client mit den Dienst 192.168.1.5 dieser hat 1.3 als DNS und Gateway.
Es wird alles über dhcp vergeben, aber immer fest zugeordnet.
Vpn hat das Subnet 10.0.0.0
Dementsprechend 6 am Ende e.t.c.
Wie würde da die Route lauten und vor allem wohin?
Zum Thema Pfsense:
Es ist Englisch, gut das würde noch gehen, aber mir fehlt da was am DHCP.
Und zwar gibt es auch noch den Nachbarn.
Es läuft ohne eigenes Subnet.
Die Clients von drüben bekommen von meinem DHCP IPs.
Ich gebe denen dann aber einen anderen Gateway und dns mit, damit diese die Internet Leitung vom Nachbarn nutzen.
Diese Funktion habe ich bisher nur beim Cop gesehen oder geht das auch mit pfsense?
Dann würde ich sonst mal in einer vm testen
Ich habe gestern mal etwas herumprobiert, aber ohne Erfolg.
Und zwar habe ich beim IPCop1 in der rc.event.local folgendes eingetragen.
if [ ${1} == "network" -a ${2} == "up" ]; then
## added for RW-Connection trough cop1 to cop2
/sbin/ip route add 10.0.0.0/24 via 192.168.1.3
#
fi
if [ ${1} == "network" -a ${2} == "down" ]; then
Und zwar habe ich beim IPCop1 in der rc.event.local folgendes eingetragen.
if [ ${1} == "network" -a ${2} == "up" ]; then
## added for RW-Connection trough cop1 to cop2
/sbin/ip route add 10.0.0.0/24 via 192.168.1.3
#
fi
if [ ${1} == "network" -a ${2} == "down" ]; then
- added for RW-Connection trough cop1 to cop2
#
fi
10.0.0.0 ist das VPN Netz und die 1.3 halt der IPCop2
Das haut so aber nicht hin.
Geht das überhaupt wenn beide COPs direkt die IPs aus dem selben Subnet haben?
Ich stehe da auf dem Schlauch.
kann mir da einer helfen?
PFSense habe ich mir angesehen, das kann das wohl auch mit dem DHCP, aber ich bin einfach zu blöde es in einer Virtuellen Maschine mit 4 NICs ans laufen zu bringen.
Nur bömische Dörfer.
Ansonsten wäre es sicher interessant
Vpn hat das Subnet 10.0.0.0
Es ist völlig unwichtig welches interne IP Netz das VPN selber hat, denn diese IP Adressen (RFC 1918) werfden im Internet ja gar nicht geroutet !Wichtig ist allein die Tunnelziel adresse, denn das ist eine öffentliche IP und die muss immer über einen Router laufen bei dir.
Klar das deine Basteleien dann eher hilflose Probierei ist. Dir fehlen wirklich die einfachsten Routing Grundlagen.
Setze die statische Route für das Tunnelinterface, dann klappt das auch sofort.
aber ich bin einfach zu blöde es in einer Virtuellen Maschine mit 4 NICs ans laufen zu bringen.
Warum ?? Woran haperts ??Macht dir jeder Grundschüler in 10 Minuten.
Grundlagen dazu findest du hier:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
Hallo
Wie recht Du hast.
Ich probiere und freue mich dann über Erfolg.
Ich mache das nicht beruflich, deshalb fehlen da natürlich auch die Basics.
IPCop ist ja recht einfach zu bedienen.
Klar es hat das blaue Netz.
Da sind die Firewall Regeln halt so definiert.
Ist für den User einfacher.
Bisher separiere ich die VLans über das Switch und dementsprechend kommt dann das Vlan an der blauen Nic raus.
Ich bin da gerade am überlegen was für mich besser ist.
Gerade jetzt am Wochenende ist der eine Provider tot gewesen.
Ein Failover wäre da toll gewesen.
Aber das Failover sollten dann nicht alle nutzen dürfen, wegen der 2 Mbit und der Latenz bei dem einen Dienst.
Nur Du sagst es so einfach mit dem Routing.
Läuft dann alles darüber?
Wie muss die Route denn genau aussehen und würde das passen wo ich die eintrage?
Kannst Du als Experte mir da helfen?
Wie recht Du hast.
Ich probiere und freue mich dann über Erfolg.
Ich mache das nicht beruflich, deshalb fehlen da natürlich auch die Basics.
IPCop ist ja recht einfach zu bedienen.
Klar es hat das blaue Netz.
Da sind die Firewall Regeln halt so definiert.
Ist für den User einfacher.
Bisher separiere ich die VLans über das Switch und dementsprechend kommt dann das Vlan an der blauen Nic raus.
Ich bin da gerade am überlegen was für mich besser ist.
Gerade jetzt am Wochenende ist der eine Provider tot gewesen.
Ein Failover wäre da toll gewesen.
Aber das Failover sollten dann nicht alle nutzen dürfen, wegen der 2 Mbit und der Latenz bei dem einen Dienst.
Nur Du sagst es so einfach mit dem Routing.
Läuft dann alles darüber?
Wie muss die Route denn genau aussehen und würde das passen wo ich die eintrage?
Kannst Du als Experte mir da helfen?
Ich mache das nicht beruflich, deshalb fehlen da natürlich auch die Basics.
Keinen Sorge, das geht vielen so hier. Trotzdem kennen sie aber wenigstens die Basics bzw. haben sich diese erarbeitet und angelesen !IPCop ist ja recht einfach zu bedienen.
Nein !Liegt aber wohl daran das du noch nie eine Alternative gesehen hast, oder ?
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Bisher separiere ich die VLans über das Switch und dementsprechend kommt dann das Vlan an der blauen Nic raus.
Den Switch...aber egal. Hier findest du weitere Grundlagen dazu:VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Aber das Failover sollten dann nicht alle nutzen dürfen, wegen der 2 Mbit und der Latenz bei dem einen Dienst.
Dafür gibt es auf jeder Firewall ja Accesslisten oder FW Regeln !!Wie muss die Route denn genau aussehen und würde das passen wo ich die eintrage?
Dazu müsstest du nochmal genau schildern was du vorhast. Eine kleine Skizze hier würde sehr helfen dein Anliegen genau zu verstehen.
So, dann versuche ich mich mal zu erklären mit der ersten Visio Zeichnung.
Also ich habe 2 Internet Leitungen, was eigentlich nicht so sein sollte, aber die Arche Geschichte war zuerst sehr wackelig und ist in unser Dorf auch nur via Richtfunk angebunden.
Telekom ist leider nur mit RAM auf 2Mbit und darüber läuft auch das Telefon noch.
Da der eine Serverdienst nicht viel Traffic hat, aber möglichst kurze Latenzen erfordert, läuft dieser über die Telekom Leitung.
Der IPCop-1 erledigt den DHCP Server und alles wird über Fixed-Leases vergeben. Dem "Server" werden dabei über den DHCP die Gateway und DNS IP 192.168.1.3 übergeben.
Mit der Portweiterleitung funktioniert somit alles wie es soll.
Nun ist es so, dass ich von intern ganz wunderbar auf die interne Website usw des Servers komme, da ich ja im selben IP Adresssegment bin, aber da die Rückroute zu dem 192.168.1.5 Rechner fehlt, geht das nicht mehr über VPN oder aus dem Blauen Netz im 192.168.10.0 Subnet.
Mir fehlt jetzt also eine Route womit ich ganz einfach nur vom IPCop-1 wenn ich mit diesem über VPN verbunden bin, auf den einen Rechner 192.168.1.5 komme , obwohl dieser den IPCop-2 als Router hat.
Gern kann das auch so ausgeweitet werden, dass ich auf IPCop-2 gleiuch mit komme.
Das wäre vorerst eine Lösung.
Dann interessiert mich das Routing schon und PFSense macht mich auch neugierig.
Mich reizt da gerade das Failover sehr. Gerade letztes Wochenende war die Arche Leitung tot, da irgendwo in der Republik ein Glasfaserkabel durchgebaggert wurde. Gut, das ist höhere Gewalr, aber wenn man schon 2 Leitungen hat...
Was mich an PFSense frage, ist ob ich da auch die Möglichkeit habe im DHCP einen anderen Router und Gateway mitzugeben.
In der Gleichung gibt es nämlich noch meinen Nachbarn mit dem ich lokal vernetz bin im selben Subnet 192.168.1.0
Deren Router läuft auf der 192.168.1.1 und macht keinen DHCP. Bei IPCop sage ich bei den entsprechenden Clients halt, er solle das dementsprechend anders mitgeben. IPCop hat die "option Routers" Funktion.
Kann das PFSense? Klar wäre ein anderes Subnet da auch machbar, aber dann geht der Broadcast nicht mehr und ich sehe die anderen Rechner so leicht nicht mehr. Ausserdem ist es nicht so riesig.
Und bei Failover sagtest Du, könnte man auch die Rechner beschränken, ja?
Gerade wegen dem Dienst müsste ja der Gastzugang im Fall der Fälle nicht laufen.
Also ich habe 2 Internet Leitungen, was eigentlich nicht so sein sollte, aber die Arche Geschichte war zuerst sehr wackelig und ist in unser Dorf auch nur via Richtfunk angebunden.
Telekom ist leider nur mit RAM auf 2Mbit und darüber läuft auch das Telefon noch.
Da der eine Serverdienst nicht viel Traffic hat, aber möglichst kurze Latenzen erfordert, läuft dieser über die Telekom Leitung.
Der IPCop-1 erledigt den DHCP Server und alles wird über Fixed-Leases vergeben. Dem "Server" werden dabei über den DHCP die Gateway und DNS IP 192.168.1.3 übergeben.
Mit der Portweiterleitung funktioniert somit alles wie es soll.
Nun ist es so, dass ich von intern ganz wunderbar auf die interne Website usw des Servers komme, da ich ja im selben IP Adresssegment bin, aber da die Rückroute zu dem 192.168.1.5 Rechner fehlt, geht das nicht mehr über VPN oder aus dem Blauen Netz im 192.168.10.0 Subnet.
Mir fehlt jetzt also eine Route womit ich ganz einfach nur vom IPCop-1 wenn ich mit diesem über VPN verbunden bin, auf den einen Rechner 192.168.1.5 komme , obwohl dieser den IPCop-2 als Router hat.
Gern kann das auch so ausgeweitet werden, dass ich auf IPCop-2 gleiuch mit komme.
Das wäre vorerst eine Lösung.
Dann interessiert mich das Routing schon und PFSense macht mich auch neugierig.
Mich reizt da gerade das Failover sehr. Gerade letztes Wochenende war die Arche Leitung tot, da irgendwo in der Republik ein Glasfaserkabel durchgebaggert wurde. Gut, das ist höhere Gewalr, aber wenn man schon 2 Leitungen hat...
Was mich an PFSense frage, ist ob ich da auch die Möglichkeit habe im DHCP einen anderen Router und Gateway mitzugeben.
In der Gleichung gibt es nämlich noch meinen Nachbarn mit dem ich lokal vernetz bin im selben Subnet 192.168.1.0
Deren Router läuft auf der 192.168.1.1 und macht keinen DHCP. Bei IPCop sage ich bei den entsprechenden Clients halt, er solle das dementsprechend anders mitgeben. IPCop hat die "option Routers" Funktion.
Kann das PFSense? Klar wäre ein anderes Subnet da auch machbar, aber dann geht der Broadcast nicht mehr und ich sehe die anderen Rechner so leicht nicht mehr. Ausserdem ist es nicht so riesig.
Und bei Failover sagtest Du, könnte man auch die Rechner beschränken, ja?
Gerade wegen dem Dienst müsste ja der Gastzugang im Fall der Fälle nicht laufen.
OK, ein relativ einfaches Design.
Ein paar Fragen und Anmerkungen dazu:
Der Knackpunkt ist dann das du ein Policy Based Routing aufsetzen musst und es fraglich ist ob der SG-300 das supportet.
Wie sowas aussieht kannst du hier sehen:
Cisco Router 2 Gateways für verschiedene Clients
Generell hast du das Problem das du ja ein automatisches Failover brauchst wenn eine Leitung nicht aktiv ist oder ausgefallen ist.
Auf dem Switch realisiert man das dann mit 2 statischen Default Routen wobei eine eine schlechtere Metric bekommt. Bei dir hat das aber den Nachteil das statische Routen durch die Kaskadierung mit FW und NAT Router nicht merken wenn ein Link Down ist. Dazu ist eine SLA Funktion auf dem Switch erforderlich die der SG-300 de facto nicht hat.
Daran krankt dein ganzes Design.
So wie du es oben gemacht hast nagelst du ja auch alle Endgeräte auf eins der IPCops fest. Fällt die Leutung daran aus geht an diesen Endgeräten nichts mehr.
Bei dir müsste der eine IPCop dem anderen also mitteilen das sein Link ausgefallen ist und der müsste ein Gateway Failover machen wie z.B. bei VRRP usw.
Es ist sehr fraglich ob die IPCops das mit ihren rudimentären Features supporten. Wenn dann nur mit erheblichem manuellen Aufwand und Customizing.
Da du schon an solchen Routing Aufgaben scheiterst ist die Frage ob dir das wirklich hilft. Sorry nicht bös gemeint.
Du solltest deshalb darüber nachdenken ob du das speziell für das design nicht anders und besser löst.
Die 2 singulären Firewalls sind nicht optimal.
Besser ist es hier in der Tat eine einzige einzusetzen mit 2 WAN Ports.
Damit hast du dann ein zentrales Gateway für die Endgeräte egal ob du es über den L3 Switch laufen lässt oder direkt.
Die WAN Ports pingen zur Prüfung der Erreichbarkeit der beiden Provider dann jeweils deren Next Hop Gateways. So erkennt die Firewall automatisch einen Ausfall und routet alles über den anderen ISP und vice versa.
Außerdem kannst du auch noch eine moderate Lastverteilung machen indem du einen Teil der Last auf beide ISPs per Balancing verteilst und das mit gleichzeitigem Failover.
Diese Einrichtung ist mit ein paar Mausklicks erledigt und behebt alle deine aktuellen problem auf Schlag.
https://doc.pfsense.org/index.php/Multi-WAN
Der Gang mit einer pfSense wäre also durchaus angebracht. Bei den geringen Bandbreiten die du hast rennt das sogar fehlerlos auf einem ALIX 2D13 Board.
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
http://varia-store.com/Hardware/PC-Engines-Bundles/PC-Engines-ALIX-2D13 ...
Alternative APU1D.
Worauf laufen die IPCops derzeit ? PC Plattform ? Auch da kannst du die pfSense schnell und unkompliziert installieren:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
Du musst nur sicherstellen das du mindestens 3 Netzwerk Interfaces hast !
Eine NIC kostet ja nicht mehr die Welt:
https://www.reichelt.de/Netzwerkkarten/LOGILINK-PC0039/3/index.html?& ...
PCIe
https://www.reichelt.de/Netzwerkkarten/LOGILINK-PC0029A/3/index.html?&am ...
Letztlich ist das der beste Weg für dich um problemlos und auch einfach an dein Ziel zu kommen.
Ein paar Fragen und Anmerkungen dazu:
- Warum hast du einen L3 Switch im Einsatz wenn du gar nicht routest lokal ? Ein SG-200 wäre da besser gewesen.
- Mit dem 300er wäre ein anderes und besseres Design in deinem Falle hilfreicher.
- Ein gravierender IP Designfehler ist die beiden FB Transfernetze mit identischer IP Adressierung zu betrieben. Das verstößt gegen fundamentale TCP/IP Design Richtlinien.
- Aufteilung der Netze auf dem SG-300 in 3 VLANs: 1.) .1.0 /24 2.) .10.0 /24 3.) .99.0 /24 Letzteres ist das WAN VLAN. Damit wird eine zentrale Routing Entscheidung auf dem Switch getroffen und du bist unabhängig von den Internet Zugängen der IPCops.
Der Knackpunkt ist dann das du ein Policy Based Routing aufsetzen musst und es fraglich ist ob der SG-300 das supportet.
Wie sowas aussieht kannst du hier sehen:
Cisco Router 2 Gateways für verschiedene Clients
Generell hast du das Problem das du ja ein automatisches Failover brauchst wenn eine Leitung nicht aktiv ist oder ausgefallen ist.
Auf dem Switch realisiert man das dann mit 2 statischen Default Routen wobei eine eine schlechtere Metric bekommt. Bei dir hat das aber den Nachteil das statische Routen durch die Kaskadierung mit FW und NAT Router nicht merken wenn ein Link Down ist. Dazu ist eine SLA Funktion auf dem Switch erforderlich die der SG-300 de facto nicht hat.
Daran krankt dein ganzes Design.
So wie du es oben gemacht hast nagelst du ja auch alle Endgeräte auf eins der IPCops fest. Fällt die Leutung daran aus geht an diesen Endgeräten nichts mehr.
Bei dir müsste der eine IPCop dem anderen also mitteilen das sein Link ausgefallen ist und der müsste ein Gateway Failover machen wie z.B. bei VRRP usw.
Es ist sehr fraglich ob die IPCops das mit ihren rudimentären Features supporten. Wenn dann nur mit erheblichem manuellen Aufwand und Customizing.
Da du schon an solchen Routing Aufgaben scheiterst ist die Frage ob dir das wirklich hilft. Sorry nicht bös gemeint.
Du solltest deshalb darüber nachdenken ob du das speziell für das design nicht anders und besser löst.
Die 2 singulären Firewalls sind nicht optimal.
Besser ist es hier in der Tat eine einzige einzusetzen mit 2 WAN Ports.
Damit hast du dann ein zentrales Gateway für die Endgeräte egal ob du es über den L3 Switch laufen lässt oder direkt.
Die WAN Ports pingen zur Prüfung der Erreichbarkeit der beiden Provider dann jeweils deren Next Hop Gateways. So erkennt die Firewall automatisch einen Ausfall und routet alles über den anderen ISP und vice versa.
Außerdem kannst du auch noch eine moderate Lastverteilung machen indem du einen Teil der Last auf beide ISPs per Balancing verteilst und das mit gleichzeitigem Failover.
Diese Einrichtung ist mit ein paar Mausklicks erledigt und behebt alle deine aktuellen problem auf Schlag.
https://doc.pfsense.org/index.php/Multi-WAN
Der Gang mit einer pfSense wäre also durchaus angebracht. Bei den geringen Bandbreiten die du hast rennt das sogar fehlerlos auf einem ALIX 2D13 Board.
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
http://varia-store.com/Hardware/PC-Engines-Bundles/PC-Engines-ALIX-2D13 ...
Alternative APU1D.
Worauf laufen die IPCops derzeit ? PC Plattform ? Auch da kannst du die pfSense schnell und unkompliziert installieren:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
Du musst nur sicherstellen das du mindestens 3 Netzwerk Interfaces hast !
Eine NIC kostet ja nicht mehr die Welt:
https://www.reichelt.de/Netzwerkkarten/LOGILINK-PC0039/3/index.html?& ...
PCIe
https://www.reichelt.de/Netzwerkkarten/LOGILINK-PC0029A/3/index.html?&am ...
Letztlich ist das der beste Weg für dich um problemlos und auch einfach an dein Ziel zu kommen.
Hallo
Zuerst einmal vielen Dank für Deine sehr ausführliche Antwort und Hilfe.
Ich werde die offenen Fragen mal beantworten.
Mein Nachbar hat das SG200-26 und damit war klar es sollte auch diese Serie sein.
Ich habe in weiser Voraussicht gekauft, falls mal was mit Telekom und VLAN Routing laufen soll.
Das kann das 200er nicht und somit wurden es 300er. Waren auch nicht so viel teurer.
Die laufen momentan aber auf L2.
Deshalb mache ich mich ja gerade schlau und recht hast Du, was Routing anbetrifft, bin ich einfach ein Anfänger, den das Ganze aber interessiert
als Hobby und nicht nur einfach irgendwie laufen haben möchte.
Das pingen könnte ich natürlich umgehen, wenn ich meine eigentliche Planung wieder aufleben lasse und die Einwahl die Firewall machen lasse.
Es war ein Vigor130 VDSL Modem geplant und ein Speedport 201 für die Telekom.
Die geräte sind auch noch vorhanden.
Ich entschied mich für die FritzBoxen, da die mir den Netzausfall des zweiten Providers schön dokumentieren und als Statusmail zuschicken.
DDNS machen die Fritzboxen aufgrund der angesprochenen Problematik auch.
Und ich finde man kann sauberer sagen wie die Zwangstrennung funktionieren soll.
FritzBox sagt man zwischen 3 und 4 und es funktioniert. Beim IPCop geht das auf die Minute genau. Da kam mein provider shcon zuvor und es gab 2 Trennungen, was abe rnicht so schlimm wäre, wenn dies nachts passiert.
Des weiteren könnte ich, wenn Telefon in betracht kommt dieses vor der Firewall abzwacken. Ginge die PFSense nicht, ginge auch kein Telefon sonst.
Fazit ich könnte es umstellen auf Direkteinwahl.
Also der COP-2 läuft auf einem Alix 2D13. Da ist das GUI aber sowas von quälend lahm, das macht keinen Spass.
Der COP-1 hat etwas mehr Dampf und läuft auch mit einer Festplatte und das bewusst.
Ich habe immer gerne einen Proxy laufen und ich befürchte ein kaputtschreiben einer CF.
SSD sieht da denke ich schon anders aus.
Könnte man auch umstellen, das sollte nicht das Problem sein.
Des weiteren lasse ich die Windows Updates gerne speichern um nicht zig mal das selbe Update zu laden.
Das kann die PFSense ja auch.
Als Rechner selber läuft ein Fujitsu D3003-S2 mit AMD Dual Core T56N (1.65GHz)
4GB Ram meine ich und das Teil hat schon 2 Gigabit NICs onboard.
Über PCI Express wurde dann noch eine DualPort Intel Gigabit Nic LowProfil eingebaut.
Somit hat die Kiste 4x Gigabit Lan.
Das sollte denke ich reichen.
Der alte AlixCop wäre auch nicht auf verlorenem Posten, der würde wohl dann zu meiner Freundin umziehen und dort auch eine PFSense werden, dann aber dort mit integriertem WLan
Ich muss halt mit PFSense etwas üben auf einem alten Rechner, damit der Umstieg nicht Stunden verschlingt und nichts läuft.
Deshalb frage ich halt vorher und schaue parallel um nicht alles in Schutt und Asche zu legen und nichts läuft.
Zuerst einmal vielen Dank für Deine sehr ausführliche Antwort und Hilfe.
Ich werde die offenen Fragen mal beantworten.
Warum hast du einen L3 Switch im Einsatz wenn du gar nicht routest lokal ? Ein SG-200 wäre da besser gewesen.
Als ich vor der Switchauswahl stand, habe ich mich etwas eingelesen.Mein Nachbar hat das SG200-26 und damit war klar es sollte auch diese Serie sein.
Ich habe in weiser Voraussicht gekauft, falls mal was mit Telekom und VLAN Routing laufen soll.
Das kann das 200er nicht und somit wurden es 300er. Waren auch nicht so viel teurer.
Die laufen momentan aber auf L2.
Du solltest deshalb darüber nachdenken ob du das speziell für das design nicht anders und besser löst.
Die 2 singulären Firewalls sind nicht optimal.
Routing auf dem Switch ist glaube ich doof. Ich kann von dem Design ja abweichen und auf eine PFSense ausweichen.Die 2 singulären Firewalls sind nicht optimal.
Deshalb mache ich mich ja gerade schlau und recht hast Du, was Routing anbetrifft, bin ich einfach ein Anfänger, den das Ganze aber interessiert
als Hobby und nicht nur einfach irgendwie laufen haben möchte.
Besser ist es hier in der Tat eine einzige einzusetzen mit 2 WAN Ports.
Damit hast du dann ein zentrales Gateway für die Endgeräte egal ob du es über den L3 Switch laufen lässt oder direkt.
Die WAN Ports pingen zur Prüfung der Erreichbarkeit der beiden Provider dann jeweils deren Next Hop Gateways. So erkennt die Firewall automatisch einen Ausfall und routet alles über den anderen ISP und vice versa.
Außerdem kannst du auch noch eine moderate Lastverteilung machen indem du einen Teil der Last auf beide ISPs per Balancing verteilst und das mit gleichzeitigem Failover.
Diese Einrichtung ist mit ein paar Mausklicks erledigt und behebt alle deine aktuellen problem auf Schlag.
https://doc.pfsense.org/index.php/Multi-WAN
Damit hast du dann ein zentrales Gateway für die Endgeräte egal ob du es über den L3 Switch laufen lässt oder direkt.
Die WAN Ports pingen zur Prüfung der Erreichbarkeit der beiden Provider dann jeweils deren Next Hop Gateways. So erkennt die Firewall automatisch einen Ausfall und routet alles über den anderen ISP und vice versa.
Außerdem kannst du auch noch eine moderate Lastverteilung machen indem du einen Teil der Last auf beide ISPs per Balancing verteilst und das mit gleichzeitigem Failover.
Diese Einrichtung ist mit ein paar Mausklicks erledigt und behebt alle deine aktuellen problem auf Schlag.
https://doc.pfsense.org/index.php/Multi-WAN
Das pingen könnte ich natürlich umgehen, wenn ich meine eigentliche Planung wieder aufleben lasse und die Einwahl die Firewall machen lasse.
Es war ein Vigor130 VDSL Modem geplant und ein Speedport 201 für die Telekom.
Die geräte sind auch noch vorhanden.
Ich entschied mich für die FritzBoxen, da die mir den Netzausfall des zweiten Providers schön dokumentieren und als Statusmail zuschicken.
DDNS machen die Fritzboxen aufgrund der angesprochenen Problematik auch.
Und ich finde man kann sauberer sagen wie die Zwangstrennung funktionieren soll.
FritzBox sagt man zwischen 3 und 4 und es funktioniert. Beim IPCop geht das auf die Minute genau. Da kam mein provider shcon zuvor und es gab 2 Trennungen, was abe rnicht so schlimm wäre, wenn dies nachts passiert.
Des weiteren könnte ich, wenn Telefon in betracht kommt dieses vor der Firewall abzwacken. Ginge die PFSense nicht, ginge auch kein Telefon sonst.
Fazit ich könnte es umstellen auf Direkteinwahl.
Der Gang mit einer pfSense wäre also durchaus angebracht. Bei den geringen Bandbreiten die du hast rennt das sogar fehlerlos auf einem ALIX 2D13 Board.
Worauf laufen die IPCops derzeit ? PC Plattform ? Auch da kannst du die pfSense schnell und unkompliziert installieren:
Worauf laufen die IPCops derzeit ? PC Plattform ? Auch da kannst du die pfSense schnell und unkompliziert installieren:
Also der COP-2 läuft auf einem Alix 2D13. Da ist das GUI aber sowas von quälend lahm, das macht keinen Spass.
Der COP-1 hat etwas mehr Dampf und läuft auch mit einer Festplatte und das bewusst.
Ich habe immer gerne einen Proxy laufen und ich befürchte ein kaputtschreiben einer CF.
SSD sieht da denke ich schon anders aus.
Könnte man auch umstellen, das sollte nicht das Problem sein.
Des weiteren lasse ich die Windows Updates gerne speichern um nicht zig mal das selbe Update zu laden.
Das kann die PFSense ja auch.
Als Rechner selber läuft ein Fujitsu D3003-S2 mit AMD Dual Core T56N (1.65GHz)
4GB Ram meine ich und das Teil hat schon 2 Gigabit NICs onboard.
Über PCI Express wurde dann noch eine DualPort Intel Gigabit Nic LowProfil eingebaut.
Somit hat die Kiste 4x Gigabit Lan.
Das sollte denke ich reichen.
Der alte AlixCop wäre auch nicht auf verlorenem Posten, der würde wohl dann zu meiner Freundin umziehen und dort auch eine PFSense werden, dann aber dort mit integriertem WLan
Letztlich ist das der beste Weg für dich um problemlos und auch einfach an dein Ziel zu kommen.
Ich muss halt mit PFSense etwas üben auf einem alten Rechner, damit der Umstieg nicht Stunden verschlingt und nichts läuft.
Deshalb frage ich halt vorher und schaue parallel um nicht alles in Schutt und Asche zu legen und nichts läuft.
Ich habe in weiser Voraussicht gekauft,
OK, unter dem Gesichtspunkt macht das Sinn. (Übrigens der Switch und der SG-200)Routing auf dem Switch ist glaube ich doof.
Nein, bei VLANs macht das Sinn. Es sei denn die VLANs sollen vollkommen getrennt bleiben dann sollte man es lassen.Ich kann von dem Design ja abweichen und auf eine PFSense ausweichen.
Es geht primär erstmal nicht um das Produkt letztlich, sondern erstmal einzig um das IP und Routing Design.bin ich einfach ein Anfänger, den das Ganze aber interessiert
Was schon mal sehr positiv ist und darauf kann man aufbauen 
Wir bekommen das hier mit dir schon zum Fliegen...Planung wieder aufleben lasse und die Einwahl die Firewall machen lasse.
Löst nur teilweise das Problem, aber generell gilt sowenig wie möglich Komponenten kaskadiert...das ist primär richtig.Ich entschied mich für die FritzBoxen, da die mir den Netzausfall des zweiten Providers schön dokumentieren und als Statusmail zuschicken.
Na ja...das kann jeder Pupsrouter auch der SNMP kann oder ein Syslog hat. Mit einem Raspberry Pi im Hintergrund kannst du das dann sogar für alle Komponenten customizen und optisch visualisieren:Netzwerk Management Server mit Raspberry Pi
DDNS machen die Fritzboxen aufgrund der angesprochenen Problematik auch.
Jeder andere Pupsrouter auch.... Dito. mit der Zwangstrennung obwohl das immer Provider spezifisch ist.Letztlich ist es für dein Gesamtkonzept und die eigentliche Zielstellung mit dem Failover aber vollkommen irrelevant ob da ein Modem, Baumarktrouter oder ne FritzBox zum ISP steht.
Also der COP-2 läuft auf einem Alix 2D13. Da ist das GUI aber sowas von quälend lahm, das macht keinen Spass.
Wäre ja perfekt...Einfach mal eine zweite CF Karte nehmen und die pfSense flashen. Das GUI rennt da auch schneller.Das sollte denke ich reichen.
Ja, allemal...zu meiner Freundin umziehen und dort auch eine PFSense werden, dann aber dort mit integriertem WLan
Und sie customized das Teil auch ! Respekt ! So eine Freundin hätte jeder Netzwerker gerne 
üben auf einem alten Rechner, damit der Umstieg nicht Stunden verschlingt und nichts läuft.
Deshalb frage ich halt vorherSehr weise ! Wenn was nicht klappen sollte weist du ja wo du fragen musst
Naja so einfach mal den Alix vom Netz nehmen ist nicht, da darüber halt der eine Client läuft.
Das wäre der letzte Router, der umgestellt werden würde.
Vorher würde ich mir eine neue 2,5" HDD kaufen und darauf in dem Fujitsu die ersten Tests fahren.
Kann das mit den FritzBoxen also so laufen bleiben, ja?
Mit dem nackten Modem bleiben mir Dämpfungswerte usw alles verborgen.
Statistik über Syslog klingt interessant. Das werde ich wohl mal auf dem Windows Server testen.
Das DDNS alle Router können, weiss ich.
Ich kaufte speziell die 7360 Fritz, da diese wohl ein recht gutes Modem haben soll.
Das mit meiner Freundin, ist eine Option.
Klar das ich das dann einrichte.
Nur das mit den Subnets wurmt mich noch.
Du sagst das nachbarhaus in ein eigenes Subnet?
Das haben wir bisher nie aufgrund der niedrigen Rechneranzahl in betracht gezogen und ich würde das auch nur unter Protest umbiegen wollen.
Aber PFSense kann ich doch auch so umbiegen, dass sich eine NIC wie beim IPCop das blaue Netz verhält und nur Internet geht, oder?
Da mache ich ja das Routing über die Switches.
Das wäre der letzte Router, der umgestellt werden würde.
Vorher würde ich mir eine neue 2,5" HDD kaufen und darauf in dem Fujitsu die ersten Tests fahren.
Kann das mit den FritzBoxen also so laufen bleiben, ja?
Mit dem nackten Modem bleiben mir Dämpfungswerte usw alles verborgen.
Statistik über Syslog klingt interessant. Das werde ich wohl mal auf dem Windows Server testen.
Das DDNS alle Router können, weiss ich.
Ich kaufte speziell die 7360 Fritz, da diese wohl ein recht gutes Modem haben soll.
Das mit meiner Freundin, ist eine Option.
Klar das ich das dann einrichte.
Nur das mit den Subnets wurmt mich noch.
Du sagst das nachbarhaus in ein eigenes Subnet?
Das haben wir bisher nie aufgrund der niedrigen Rechneranzahl in betracht gezogen und ich würde das auch nur unter Protest umbiegen wollen.
Aber PFSense kann ich doch auch so umbiegen, dass sich eine NIC wie beim IPCop das blaue Netz verhält und nur Internet geht, oder?
Da mache ich ja das Routing über die Switches.
Kann das mit den FritzBoxen also so laufen bleiben, ja?
Ja... Allerdings solltest du die beiden Transfer Netze zu den FBs (LAN Ports) zwingend so umkonfigurieren das das 2 unterschiedliche IP Netze sind.Deine o.a. Konfig ist diesbezüglich falsch und nicht standardkonform !!
Mit dem nackten Modem bleiben mir Dämpfungswerte usw alles verborgen.
Nein, nicht wenn du managebare Modems hast !Statistik über Syslog klingt interessant. Das werde ich wohl mal auf dem Windows Server testen.
Ein RasPi tuts auch:Netzwerk Management Server mit Raspberry Pi
Sonst findest du Winblows Syslog SW hier:
http://www.kiwisyslog.com/free-edition.aspx
http://www.mikrotik.com/archive.php
da diese wohl ein recht gutes Modem haben soll.
Nöö....ist ein Standard xDSL Chipset den andere auch haben...Massenware.Du sagst das nachbarhaus in ein eigenes Subnet?
Ist ein Muss wenn du ein Balancing über beide Anschlüsse machen willst. IP Netze müssen immer einzigartig sein in einem Netz ! Logisch, ansonsten wäre eine eindeutige Wegefindung und Routing unmöglich.Das ist ein Kardinalsfehler den du da begangen hast !
Das haben wir bisher nie aufgrund der niedrigen Rechneranzahl in betracht gezogen
Hat damit auch rein gar nichts zu tun. Ob du da 2 oder 200 Rechner drinhast ist für die eindeutige Wegefindung (Routing) in einem IP Netz vollkommen unerheblich. Weist du sicher auch selber..?!!und ich würde das auch nur unter Protest umbiegen wollen.
Komisches Argument... Wär so als wenn du dein Benzinauto mit Diesel volltankst und du den Tankwart der dir helfen will wegschickst mit dem Argument: "Hau ab, getankt ist getankt...ich fahr den jetzt leer !"Muss man wohl nicht weiter kommentieren, oder ?
Aber PFSense kann ich doch auch so umbiegen,
Yepp...mit der kannst du 200% mehr machen als mit dem Cop
Ich glaube eine Sache läuft da gerade missverständlich.
Die 2 COPs laufen bei mir und auch die 2 Internetleitungen sind meine.
Zum Nachbarn bin ich vernetzt.
Dort gibt es quasi Internetleitung 3 die auf der 192.168.1.1 läuft.
Über meinen DHCP gebe ich diesen Rechnern dann Gateway und DNS auf diesen Router mit.
Das meine FritzBoxen die sozusagen Router 2/3 sind andere Subnetze bekommen, wäre OK.
Es soll ein Failover zwischen den Beiden Leitungen bei mir stattfinden welche genau nebeneinander im Serverschrank landen.
Physikalisch liegen die Kabel also nebeneinander.
Die Wegfindung über 1.1 ist nicht erforderlich, vielleicht irgendwann mal Leitung 3 auf dem Router, aber das wenn später und ist Nebensache jetzt vorerst.
Die 2 COPs laufen bei mir und auch die 2 Internetleitungen sind meine.
Zum Nachbarn bin ich vernetzt.
Dort gibt es quasi Internetleitung 3 die auf der 192.168.1.1 läuft.
Über meinen DHCP gebe ich diesen Rechnern dann Gateway und DNS auf diesen Router mit.
Das meine FritzBoxen die sozusagen Router 2/3 sind andere Subnetze bekommen, wäre OK.
Es soll ein Failover zwischen den Beiden Leitungen bei mir stattfinden welche genau nebeneinander im Serverschrank landen.
Physikalisch liegen die Kabel also nebeneinander.
Die Wegfindung über 1.1 ist nicht erforderlich, vielleicht irgendwann mal Leitung 3 auf dem Router, aber das wenn später und ist Nebensache jetzt vorerst.
Die 2 COPs laufen bei mir und auch die 2 Internetleitungen sind meine.
Spielt ja keine Rolle und ändert nichts an der Tatsache das du die beiden Transfernetz FALSCH mit 192.168.178.0 /24 konfiguriert hast ! Das geht so nicht.Dort gibt es quasi Internetleitung 3 die auf der 192.168.1.1 läuft.
Ist das das 192.168.1.0er Netz was oben in der Zeichnung angegeben ist ??Es soll ein Failover zwischen den Beiden Leitungen bei mir stattfinden welche genau nebeneinander im Serverschrank landen.
Das ist dann kein Problem und eine Kleinigkeit mit einem Dual WAN Port Router oder Firewall wie oben schon beschrieben.Die Wegfindung über 1.1 ist nicht erforderlich, vielleicht irgendwann mal Leitung 3 auf dem Router,
Wäre dann auch kein Problem die Konfig dann entsprechend zu erweitern.
Also auf gut Deutsch die Deiden FritzBoxen in andere Subnets packen.
178 und 179 beispielsweise und fertig.
Das lässt sich ja schnell erledigen.
Ich habe jetzt erstmal eine USB NIC bestellt, damit kann ich den alten abgeschaltete COP für die 3 Netze aufrüsten um dann direkt mit der Originalhardware experimentieren zu können.
Der Vorteil an den FritzBoxen ist dann ja der Switch. So kann ich den WAN parallel nutzen und testen, ohne das in der Phase das normale Netz ausfällt.
178 und 179 beispielsweise und fertig.
Das lässt sich ja schnell erledigen.
Ich habe jetzt erstmal eine USB NIC bestellt, damit kann ich den alten abgeschaltete COP für die 3 Netze aufrüsten um dann direkt mit der Originalhardware experimentieren zu können.
Der Vorteil an den FritzBoxen ist dann ja der Switch. So kann ich den WAN parallel nutzen und testen, ohne das in der Phase das normale Netz ausfällt.
Also auf gut Deutsch die Deiden FritzBoxen in andere Subnets packen. 178 und 179 beispielsweise und fertig.
Bingo !
Sodele
Nun melde ich mich auch mal wieder zu Wort.
Nicht das gedacht wird, ich habe das Interesse verloren, sondern es war wenig Zeit und es musste Ersatz geschaffen werden.
Was ist also passiert.
Ich habe den alten IPCop welcher ersetzt wurde auf aktuellen Stand gebracht und somit die config des werkelnden IPCop-1 darauf übertragen.
Somit läuft alles wie bisher weiter und ich habe die Hardware wo wenn dann alles drauf laufen soll für PFSense frei.
Da ich später mal vor habe Windows Updates zu cachen habe ich auch eine neue HDD geordert.
Somit habe ich gleich eine schön grosse neue HDD verbaut und kann jederzeit zurück indem ich nur die alte HDD wieder einbaue.
2 Fliegen mit einer Klappe also.
Nun schaue ich mir PFSense so langsam an und lese viel.
Aktuell ist es so, dass das Lan1 die IP 192.168.1.39 hat und WAN bekommt per DHCP eine IP zugewiesen.
WAN hängt zwar am selben Switch, dort wird es aber in das VLan 10 gesteckt und kommt somit in einem anderen Subnet am IPCop an wie quasi ein Gast im Wlan und bekommt eine IP zugewiesen.
Ich kann allerdings nicht pingen von der PFSense heraus. www.heise.de löst er zwar auf, aber es kommt nichts zurück.
Warum ist mir fraglich, denn von der PFSense heraus kann ich die Zusatzpaketliste laden. Also muss ja was gehen.
Jedenfalls bin ich jetzt dabei das extra Interface als LAN2 einzustellen.
LAN1 soll auf Rechner in LAN2 zugreifen können, aber LAN2 darf nur ins Internet und nicht in das LAN1
Ich habe da mal die Regeln mit Deiner Hilfestellung aus einem anderen Thread erstellt.
Zusätzlich habe ich eine Regel erstellt (noch deaktiviert) welche wie ich meine den Traffic von LAN2 zu LAN1 blockt.
Bin ich da jetzt auf dem richtigen Weg oder verrenne ich mich hier schon?
Es ist doch ohne explizite Regel von LAN2 eigentlich gar nichts möglich oder?
Nun melde ich mich auch mal wieder zu Wort.
Nicht das gedacht wird, ich habe das Interesse verloren, sondern es war wenig Zeit und es musste Ersatz geschaffen werden.
Was ist also passiert.
Ich habe den alten IPCop welcher ersetzt wurde auf aktuellen Stand gebracht und somit die config des werkelnden IPCop-1 darauf übertragen.
Somit läuft alles wie bisher weiter und ich habe die Hardware wo wenn dann alles drauf laufen soll für PFSense frei.
Da ich später mal vor habe Windows Updates zu cachen habe ich auch eine neue HDD geordert.
Somit habe ich gleich eine schön grosse neue HDD verbaut und kann jederzeit zurück indem ich nur die alte HDD wieder einbaue.
2 Fliegen mit einer Klappe also.
Nun schaue ich mir PFSense so langsam an und lese viel.
Aktuell ist es so, dass das Lan1 die IP 192.168.1.39 hat und WAN bekommt per DHCP eine IP zugewiesen.
WAN hängt zwar am selben Switch, dort wird es aber in das VLan 10 gesteckt und kommt somit in einem anderen Subnet am IPCop an wie quasi ein Gast im Wlan und bekommt eine IP zugewiesen.
Ich kann allerdings nicht pingen von der PFSense heraus. www.heise.de löst er zwar auf, aber es kommt nichts zurück.
Warum ist mir fraglich, denn von der PFSense heraus kann ich die Zusatzpaketliste laden. Also muss ja was gehen.
Jedenfalls bin ich jetzt dabei das extra Interface als LAN2 einzustellen.
LAN1 soll auf Rechner in LAN2 zugreifen können, aber LAN2 darf nur ins Internet und nicht in das LAN1
Ich habe da mal die Regeln mit Deiner Hilfestellung aus einem anderen Thread erstellt.
Zusätzlich habe ich eine Regel erstellt (noch deaktiviert) welche wie ich meine den Traffic von LAN2 zu LAN1 blockt.
Bin ich da jetzt auf dem richtigen Weg oder verrenne ich mich hier schon?
Es ist doch ohne explizite Regel von LAN2 eigentlich gar nichts möglich oder?
Aktuell ist es so, dass das Lan1 die IP 192.168.1.39 hat
Das ist immer eine ungünstige Adressierung. Router, Gateways und Firewalls sollten meist besser Adressen ganz unten oder ganz oben haben um nicht mitten drin im Hostbereich zu sein. Der Sinn ist IP Überschneidungen zu verhindern. OK, ein kosmetischer Aspekt aber durchaus sinnvoll.Besser also die 192.168.1.1 oder die 192.168.1.254 für Router oder Firewall verwenden wenn immer möglich !
WAN hängt zwar am selben Switch, dort wird es aber in das VLan 10 gesteckt und kommt somit in einem anderen Subnet am
Das ist korrekt und kann man natürlich so machen !Ich kann allerdings nicht pingen von der PFSense heraus. www.heise.de löst er zwar auf, aber es kommt nichts zurück.
Erste Frage ist welches Source Interface du im Ping Tool unter Diagnosis gewählt hast ??Wenn es das falsche ist greift hier vielleicht eine FW Regel ?! (ICMP Traffic (Ping) verboten etc.)
Wie geht das VLAN 10 nach draußen ins Internet ?? Ist da noch ein Router davor ?? Oder ist das mit dem IPCop kaskadiert ? Dieser Sachverhalt ist leider etwas unklar !
LAN1 soll auf Rechner in LAN2 zugreifen können, aber LAN2 darf nur ins Internet und nicht in das LAN1
OK, regelt man mit einer einfachen und simplen FW Regel am LAN 2 Port ! Hast du ja auch gemacht.Deine Regel für den LAN 2 Port oben ist soweit richtig ! Aaaaber...
Kleine kosmetische Korrektur ums noch wasserdichter zu machen:
Du lässt zuerst DNS, HTTP und HTTPS Traffic von LAN2 nach überall passieren überallhin. Das bedeutet dann aber auch das dieser Traffic auch ins LAN 1 erlaubt ist.
Die Firewall verfährt beim Regelwerk nach dem Verfahren: First match wins !
Das bedeutet der erste positive Hit einer Regel hat zur Folge das die nachfolgenden Regeln nicht mehr ausgeführt werden !
Wird also mit deiner Regel HTTP, sprich Webtraffic, ins LAN 1 gesendet kann er normal passieren, denn die folgenden Regeln und damit deine Block Regel werden nicht mehr ausgeführt, da der ALLOW Hit ja positiv war.
Ganz wichtig ist also hier immer die Reihenfolge der einzelnen Regeln am Port !!!
Du siehst jetzt selber wie deine Regel optimiert werden kann....
Nämlich indem du ganz einfach die BLOCK Regel am Ende die LAN2 Traffic ins LAN 1 blockiert ganz einfach an den Anfang des Regelwerks setzt.
Dann erst kommen die ALLOW Regeln und alles ist gut.
Nun wird sämtlicher Traffic ins LAN1 blockiert und der Rest dann erlaubt
Ansonsten ist alles richtig soweit !
Also. Heute komme ich nicht mehr zum testen, wollte mich aber noch gemeldet haben.
Die 192.168.1.39 ist vorübergehend und Testweise, da die PFSense noch nicht in einer Aktivumgebung ist.
Die 1.2 übernimmt jetzt der Hilfscop.
Das wird noch getauscht, wenn alles läuft und ich halbwegs verstanden habe. Aber so kann man ja gut testen. Sogar das failover parallel an den Fritzen dann später.
Die Test PFSense hängt jetzt wie ein normaler Rechner somit hinten dran.
Kaskade wie Du schreibst.
Er ist quasi wie der AP mit dem 1.0 Netz und Vlan 10, welches aber über LAN2 realisiert wird und kommt direkt in das 10.0 Subnet.
Bezüglich der Regeln.
First Match Wins verstehe ich.
Aber widerspricht sich das nicht wenn ich erst alles verbiete und danach DNS etc freigebe?
Muss denn DNS freigegeben werden oder merkt die Firewall das so? Hängt ja immerhin an ihr.
Webseiten aus dem Homenet sollen natürlich nicht ins Gastnetz gestellt werden. Eine vielleicht aber die gilt es dann ja explizit freizugeben.
Die 192.168.1.39 ist vorübergehend und Testweise, da die PFSense noch nicht in einer Aktivumgebung ist.
Die 1.2 übernimmt jetzt der Hilfscop.
Das wird noch getauscht, wenn alles läuft und ich halbwegs verstanden habe. Aber so kann man ja gut testen. Sogar das failover parallel an den Fritzen dann später.
Die Test PFSense hängt jetzt wie ein normaler Rechner somit hinten dran.
Kaskade wie Du schreibst.
Er ist quasi wie der AP mit dem 1.0 Netz und Vlan 10, welches aber über LAN2 realisiert wird und kommt direkt in das 10.0 Subnet.
Bezüglich der Regeln.
First Match Wins verstehe ich.
Aber widerspricht sich das nicht wenn ich erst alles verbiete und danach DNS etc freigebe?
Muss denn DNS freigegeben werden oder merkt die Firewall das so? Hängt ja immerhin an ihr.
Webseiten aus dem Homenet sollen natürlich nicht ins Gastnetz gestellt werden. Eine vielleicht aber die gilt es dann ja explizit freizugeben.
Aber widerspricht sich das nicht wenn ich erst alles verbiete und danach DNS etc freigebe?
Nein natürlich nicht !Du verbietest ja gar nicht ALLES ! (Das wäre dann any any)
Du verbietest lediglich allen Traffic der eine Absender IP aus LAN2 und eine Ziel IP aus LAN1 hat im Paket.
DNS Traffic gehört logischerweise nicht dazu, denn dein DNS Server ist ja nicht in LAN1 bzw. hat keine Ziel IP aus LAN1 !!
DNS musst du schon freigeben, das ist richtig aber die FW ist ja selber DNS Proxy, sprich als DNS Server ist die IP Adresse am LAN2 Port an den LAN2 Clients konfiguriert und dieser Traffic darf ja passieren, da hast du als Absender LAN2 und als Ziel die LAN2 FW Host IP. Da greift dann logischerweise keine Blocking Regel denn du permittest DNS ja mit Absender IP LAN2 nach any.
Am Anfang ist das etwas undurchsichtig, aber es klingt alles logisch und ich habe es auch geändert.
Ich habe den Netzwerkplan auch mal auf Stand gebracht wie ich es mir dann letztendlich vorstelle.
Aktuell ist halt der Testbetrieb bis ich es soweit habe.
Wie man sieht wieder die 2 Internet Geschichten an 2 WAN NICs
Dahinter die 2 LAN Nics mit den getrennten Netzen.
Das Internet am blauen Netz hat schon funktioniert jetzt und man kommt nicht nach grün.
Ich möchte aber von grün nach blau, aber das wird dann denke ich im LAN1 eine allow Regel werden analog zur verbietregel im LAN2.
Was mir jetzt durch den Kopf geht...
Ist es einfach die WAN Schnittstellen hinter der FritzBox auf DHCP laufen zu lassen?
Ich habe gesehen, dass wenn man es statisch machen möchte, muss man die 3 Einstellungen über zig Seiten verstreut eingeben.
Dann soll ja alles über die schnelle Arche Leitung laufen.
Passiert das automatisch oder wird er auch versuchen einiges über die andere Leitung zu schicken?
Des weiteren soll ja der eine Rechner über die Telekom Leitung von aussen erreichbar sein.
Nach meinem Verständnis müsste es doch da reichen, wenn ich einen PortForward mit dem gewissen Port von der WAN2 Schnittstelle an diesen einen Rechner mache, oder sehe ich das falsch?
Wird er über WAN2 angesprochen, dann antwortet er auch über WAN2 oder nicht?
Bezüglich Failover habe ich auch mal etwas geschaut.
Failover sollte aber auch nur für ausgewählte Clients und gar nicht im LAN2 Netz aktiv sein.
Das heisst keine Gäste und sonst auch nicht jeder.
Es gab einige Anleitungen zu lesen, aber CARP was das eigentlich sein sollte, wurde da nie erwähnt.
Es lief alles über Regeln und Gateway Groups.
Und die passende Regel in der LAN1 Schnittstelle.
Demnach dürfte das pauschal ja erstmal nur für LAN1 gelten, da diese Regel ja nicht für LAN2 eingetragen wurde.
Aber wenn das so gehen sollte, wie kann ich dann da eine Whitelist etc anlegen, aus der die Nutzer hervorgehen, die diese Regel nutzen dürfen?
Oder für jeden Client eine extra Regel?
VPN und der externe Zugang gehen beim Failover dann denke ich nicht, weil die DDNS Geschichte nicht mehr passt.
Ich kann ja jede IP nur einmal hinterlegen und wenn das dann down ist, gehts nicht, wenn DDNS die FritzBox erledigt.
Oder aber kann man das ggf automatisieren indem DDNS die PFSense macht und dann hinterlegt wird, das wenn 10 Minuten keine wiedereinwahl möglich ist bzw Internet besteht, das dann selbst DDNS geschwenkt wird?
Also WAN1 heisst vereinfacht wan1.dyndns.com und WAN2 heisst wan2.dyndns.com
Bekommt WAN2 10 Minuten kein Netz, dann wird die WAN1 IP an wan2.dyndns.com übermittelt bis das Netz wieder läuft, danach wird es zurück gewechselt.
Natürlich müsste ich da meinen Provider schauen, ob das geht, da es sich um den Hoster ALL-inkl handelt, welcher ddns anbietet über eine Subdomain.
Das sind gerade meine Gedanken.
Ich habe den Netzwerkplan auch mal auf Stand gebracht wie ich es mir dann letztendlich vorstelle.
Aktuell ist halt der Testbetrieb bis ich es soweit habe.
Wie man sieht wieder die 2 Internet Geschichten an 2 WAN NICs
Dahinter die 2 LAN Nics mit den getrennten Netzen.
Das Internet am blauen Netz hat schon funktioniert jetzt und man kommt nicht nach grün.
Ich möchte aber von grün nach blau, aber das wird dann denke ich im LAN1 eine allow Regel werden analog zur verbietregel im LAN2.
Was mir jetzt durch den Kopf geht...
Ist es einfach die WAN Schnittstellen hinter der FritzBox auf DHCP laufen zu lassen?
Ich habe gesehen, dass wenn man es statisch machen möchte, muss man die 3 Einstellungen über zig Seiten verstreut eingeben.
Dann soll ja alles über die schnelle Arche Leitung laufen.
Passiert das automatisch oder wird er auch versuchen einiges über die andere Leitung zu schicken?
Des weiteren soll ja der eine Rechner über die Telekom Leitung von aussen erreichbar sein.
Nach meinem Verständnis müsste es doch da reichen, wenn ich einen PortForward mit dem gewissen Port von der WAN2 Schnittstelle an diesen einen Rechner mache, oder sehe ich das falsch?
Wird er über WAN2 angesprochen, dann antwortet er auch über WAN2 oder nicht?
Bezüglich Failover habe ich auch mal etwas geschaut.
Failover sollte aber auch nur für ausgewählte Clients und gar nicht im LAN2 Netz aktiv sein.
Das heisst keine Gäste und sonst auch nicht jeder.
Es gab einige Anleitungen zu lesen, aber CARP was das eigentlich sein sollte, wurde da nie erwähnt.
Es lief alles über Regeln und Gateway Groups.
Und die passende Regel in der LAN1 Schnittstelle.
Demnach dürfte das pauschal ja erstmal nur für LAN1 gelten, da diese Regel ja nicht für LAN2 eingetragen wurde.
Aber wenn das so gehen sollte, wie kann ich dann da eine Whitelist etc anlegen, aus der die Nutzer hervorgehen, die diese Regel nutzen dürfen?
Oder für jeden Client eine extra Regel?
VPN und der externe Zugang gehen beim Failover dann denke ich nicht, weil die DDNS Geschichte nicht mehr passt.
Ich kann ja jede IP nur einmal hinterlegen und wenn das dann down ist, gehts nicht, wenn DDNS die FritzBox erledigt.
Oder aber kann man das ggf automatisieren indem DDNS die PFSense macht und dann hinterlegt wird, das wenn 10 Minuten keine wiedereinwahl möglich ist bzw Internet besteht, das dann selbst DDNS geschwenkt wird?
Also WAN1 heisst vereinfacht wan1.dyndns.com und WAN2 heisst wan2.dyndns.com
Bekommt WAN2 10 Minuten kein Netz, dann wird die WAN1 IP an wan2.dyndns.com übermittelt bis das Netz wieder läuft, danach wird es zurück gewechselt.
Natürlich müsste ich da meinen Provider schauen, ob das geht, da es sich um den Hoster ALL-inkl handelt, welcher ddns anbietet über eine Subdomain.
Das sind gerade meine Gedanken.
Was in deiner Zeichnung unklar ist: Warum gehen NIC1 und 2 auf den SG Switch ?? Machst du da ein Link Aggregation ?? Oder warum 2 Interfaces ?? Am SG ist ja nur ein einziges Netz ? Und auch wenn könnte man das mit einem Tagged Port machen ?
Das ist technisch unverständlich....
https://doc.pfsense.org/index.php/Multi-WAN
Jeder Netzwerker weiss das Router Interfaces NIEMALS mit dynamischen IP Adressen laufen sollen !
Konfiguriere also statische IPs hier dann kannst du niemals in Schwierigkeiten geraten mit Port Forwarting ACLs, ACLs im allgemeinen, NAT Regeln usw.
DHCP Adressen haben auf Routern und Firewalls nichts zu suchen.
Ausnahme ist nur wenn du die IP des oder der WAN Ports in den DHCP Servern der FB fest auf ihre Mac Adresse bindest (DHCP Mac Nailing) damit hast du ja dann quasi immer eine feste IP. Das wäre dann OK !
Das definiert du logischerweise mit einer Forwarding Regel und einer Wichtung der Leitungen. Sieh dir das o.a. Dokument zu den Multiple WAN Interfaces an, da ist alles haarklein beschrieben !
Das ist technisch unverständlich....
Wie man sieht wieder die 2 Internet Geschichten an 2 WAN NICs
Ist ja kein Thema wenn man ein Regel basiertes Balancing machen will:https://doc.pfsense.org/index.php/Multi-WAN
Dahinter die 2 LAN Nics mit den getrennten Netzen.
Das war die obige Unbekannte...?!und man kommt nicht nach grün.
Klar und logisch, denn das verhindert deine Firewall !! Bzw. du hast eine Regel vergessen die das erlaubt. Die Firewall blockiert ALLES was nicht explizit erlaubt ist...eine Firewall eben !aber das wird dann denke ich im LAN1 eine allow Regel werden analog zur verbietregel
Genau so ist es !!Ist es einfach die WAN Schnittstellen hinter der FritzBox auf DHCP laufen zu lassen?
Das macht die pfSense als Default !! WAN Port ist im Default immer DHCP Client ! Aaaaber...Jeder Netzwerker weiss das Router Interfaces NIEMALS mit dynamischen IP Adressen laufen sollen !
Konfiguriere also statische IPs hier dann kannst du niemals in Schwierigkeiten geraten mit Port Forwarting ACLs, ACLs im allgemeinen, NAT Regeln usw.
DHCP Adressen haben auf Routern und Firewalls nichts zu suchen.
Ausnahme ist nur wenn du die IP des oder der WAN Ports in den DHCP Servern der FB fest auf ihre Mac Adresse bindest (DHCP Mac Nailing) damit hast du ja dann quasi immer eine feste IP. Das wäre dann OK !
muss man die 3 Einstellungen über zig Seiten verstreut eingeben.
Stimmt nicht wirklich ! Wenn du Angst davor hast, dann mach das Mac zu DHCP Binding wie oben beschrieben in der FritzBox.Passiert das automatisch oder wird er auch versuchen einiges über die andere Leitung zu schicken?
Nein, denn woher soll die FW wissen was die schnellere Leitung ist ??Das definiert du logischerweise mit einer Forwarding Regel und einer Wichtung der Leitungen. Sieh dir das o.a. Dokument zu den Multiple WAN Interfaces an, da ist alles haarklein beschrieben !
Des weiteren soll ja der eine Rechner über die Telekom Leitung von aussen erreichbar sein.
Kein Thema auch das erreicht man mit einem statischen Gateway und einer entspr. Regel.Failover sollte aber auch nur für ausgewählte Clients und gar nicht im LAN2 Netz aktiv sein.
Ist alles customizebar.eine Whitelist etc anlegen, aus der die Nutzer hervorgehen, die diese Regel nutzen dürfen?
Was bezeichnest du mit Nutzer ?? Die FW kennt nur IP Adressen und Dienste aus denen sie das schliessen kann.Ich kann ja jede IP nur einmal hinterlegen und wenn das dann down ist, gehts nicht
Du hast ja 2 DDNS Adressen. Je eine pro WAN Port. So hättest du eine Redundanz.Oder aber kann man das ggf automatisieren indem DDNS die PFSense macht und dann hinterlegt wird, das wenn 10 Minuten keine wiedereinwahl möglich ist bzw Internet besteht, das dann selbst DDNS geschwenkt wird?
Ja, das ginge. Erfordert etwas Scripting.
Ja, das war die unbekannte.
Da wo LAN2 ans Switch geht, ist VLan10 unttagged.
Quai wie IPCop als eigenes Interface.
Die Telekom Leitung soll niemand nutzen ausser der Dienst auf dem einen Rechner.
Bei Ausfall der Hauptleitung sollen nur einige die Telekom Leitung als Fallback haben.
Dazu die IP Liste, also quasi User oder Rechner.
Da wo LAN2 ans Switch geht, ist VLan10 unttagged.
Quai wie IPCop als eigenes Interface.
Die Telekom Leitung soll niemand nutzen ausser der Dienst auf dem einen Rechner.
Bei Ausfall der Hauptleitung sollen nur einige die Telekom Leitung als Fallback haben.
Dazu die IP Liste, also quasi User oder Rechner.
Da wo LAN2 ans Switch geht, ist VLan10 unttagged.
Warum machst du das nicht über einen Tagged Uplink ? Weniger Strippenverhau und Fehleranfälligkeit...zudem spart es dir Ports ! Wäre doch sinniger, oder ?
Da ist halt aus der IPCop Zeit, wo das so läuft.
Die Kabel liegen.
Nur werde ich wohl taggen um die Ports zu reduzieren.
Momentan ist im Serverschrank ein SG300-20 und bei mir direkt noch ein 28er davon.
2 Kabel als LAG Uplink.
So kann ich auf das 10er zurück und so Strom sparen
Die Kabel liegen.
Nur werde ich wohl taggen um die Ports zu reduzieren.
Momentan ist im Serverschrank ein SG300-20 und bei mir direkt noch ein 28er davon.
2 Kabel als LAG Uplink.
So kann ich auf das 10er zurück und so Strom sparen
OK, kann ja auch erstmal zum Testen so bleiben... Später wenn alles rennt wäre das sinnvoller das umzustellen.
Sodele,
nach einigem Stress und einfach viel zu vielen Baustellen, möchte ich die PFSense in der nächsten zeit in die aktive Phase bringen.
Ich bitte die Verzögerung zu entschuldigen.
Sieht so desinteressiert aus, ist es aber nicht.
Ich habe mich gestern an die VLan Geschichte gemacht.
VLan 10 erstellt, dem Lan Port 1 zugewiesen und in der Firewall die bereits vorhandenen Regeln von Lan 2 kopiert und auf VLan umgestrickt.
Es sollte jetzt so sein wie mit Lan 2
Jetzt muss denke ich nur noch am Switch der Port tagged sein und nicht mehr untagged wie bei den 2 Leitungen und das würde laufen.
Wo ich gerade auf dem Schlauch stehe ist das mit der Verteilung der 2 WAN Ports.
Ich vergebe am DHCP static leases. (Mapping bei der PFSense)
Wie das geht habe ich auch heraus gefunden und kann ich denke ich vorher alles schon erstellen anhand der Mac Adressen.
Gehen somit dann alle über WAN1 wie es gewünscht ist?
WAN2 soll ein Client nutzen. Gebe ich in den DHCP Einstellungen dann einen anderen Gateway vor?
Wie kann ich der Failover Regel erklären, dass nur ausgewählte Rechner die WAN2 Schnittstelle nutzen dürfen?
Ist WAN1 platt braucht da kein Gastnetz rüber und auch sonst nicht trafficlastiges.
Das würde ich gerne anhand einer Whitelist einschränken.
nach einigem Stress und einfach viel zu vielen Baustellen, möchte ich die PFSense in der nächsten zeit in die aktive Phase bringen.
Ich bitte die Verzögerung zu entschuldigen.
Sieht so desinteressiert aus, ist es aber nicht.
Ich habe mich gestern an die VLan Geschichte gemacht.
VLan 10 erstellt, dem Lan Port 1 zugewiesen und in der Firewall die bereits vorhandenen Regeln von Lan 2 kopiert und auf VLan umgestrickt.
Es sollte jetzt so sein wie mit Lan 2
Jetzt muss denke ich nur noch am Switch der Port tagged sein und nicht mehr untagged wie bei den 2 Leitungen und das würde laufen.
Wo ich gerade auf dem Schlauch stehe ist das mit der Verteilung der 2 WAN Ports.
Ich vergebe am DHCP static leases. (Mapping bei der PFSense)
Wie das geht habe ich auch heraus gefunden und kann ich denke ich vorher alles schon erstellen anhand der Mac Adressen.
Gehen somit dann alle über WAN1 wie es gewünscht ist?
WAN2 soll ein Client nutzen. Gebe ich in den DHCP Einstellungen dann einen anderen Gateway vor?
Wie kann ich der Failover Regel erklären, dass nur ausgewählte Rechner die WAN2 Schnittstelle nutzen dürfen?
Ist WAN1 platt braucht da kein Gastnetz rüber und auch sonst nicht trafficlastiges.
Das würde ich gerne anhand einer Whitelist einschränken.
möchte ich die PFSense in der nächsten zeit in die aktive Phase bringen.
Hört sich gut an...Sieht so desinteressiert aus, ist es aber nicht.
Keine Sorge..wir beobachten das.... etzt muss denke ich nur noch am Switch der Port tagged sein
Genau richtig !Guckst du hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Wo ich gerade auf dem Schlauch stehe ist das mit der Verteilung der 2 WAN Ports.
Guckst du hier:https://doc.pfsense.org/index.php/Multi-WAN
Wie kann ich der Failover Regel erklären, dass nur ausgewählte Rechner die WAN2 Schnittstelle nutzen dürfen?
Mit einer Policy Accessliste.
Hmmm
Policy Access scheint in den Firewall Rules angelegt werden zu müssen.
Es scheint aber nicht eine Liste an sich zu sein, wo man alle MACs oder IPs einfügt, sondern je erlaubter Client eine Regel.
Ich stehe da etwas auf dem Schlauch
Policy Access scheint in den Firewall Rules angelegt werden zu müssen.
Es scheint aber nicht eine Liste an sich zu sein, wo man alle MACs oder IPs einfügt, sondern je erlaubter Client eine Regel.
Ich stehe da etwas auf dem Schlauch
Mmmhhh... Normal macht man das mit einer ACL Rule die den Traffic klassifiziert den man dann per Policy Route entsprechend forwardet.
https://doc.pfsense.org/index.php/What_is_policy_routing
Bei der pfSense ist das dann in der Tat eine FW Rule. Ob das nun eine Regel je Client ist oder eine Regel für mehrere Clients oder ein ganzes Netz ist ja eine simple Frage der Konfiguration !
https://doc.pfsense.org/index.php/What_is_policy_routing
Bei der pfSense ist das dann in der Tat eine FW Rule. Ob das nun eine Regel je Client ist oder eine Regel für mehrere Clients oder ein ganzes Netz ist ja eine simple Frage der Konfiguration !
Sollte das besser der Switch machen?
Ist bei WLAN natürlich doof.
Könnte ja sonst ein vlan sein
Ist bei WLAN natürlich doof.
Könnte ja sonst ein vlan sein
Wenn dein Switch routen kann und auch PBR supportet dann ja. Dann kannst du die ISP Router als reine Router verwenden.
Muss aber nicht sein, beide Wege sind ja möglich und machbar.
Das sinnvollste ist das mit einer Box zu machen, Dual ISP Konfig und dann mit PBR das zu dem schicken wo du das hinhaben willst.
Das geht am besten mit einer simplen VLAN Switch Konfig, tagged Uplink auf die pfSense und da PBR auf die beiden ISP.
Der gemeine Klassiker für sowas...
Muss aber nicht sein, beide Wege sind ja möglich und machbar.
Das sinnvollste ist das mit einer Box zu machen, Dual ISP Konfig und dann mit PBR das zu dem schicken wo du das hinhaben willst.
Das geht am besten mit einer simplen VLAN Switch Konfig, tagged Uplink auf die pfSense und da PBR auf die beiden ISP.
Der gemeine Klassiker für sowas...
Nur kann ich dann schlecht wlan Geräte auswählen über das vlan.
Ideal wäre da eine Liste wo man alle rein schreiben kann
Ideal wäre da eine Liste wo man alle rein schreiben kann
Nur kann ich dann schlecht wlan Geräte auswählen über das vlan.
Warum ?? Wenn du MSSID fähige APs hast ist das doch ein Kinderspiel:VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Das sind Unifis.
Da alle 4 SSIDs vergeben.
Aber klar, vlan 10 darf nicht und fertig.
Oder aber zig Regeln mit je der Mac.
Ich muss da mal versuchen eine Regel zu erstellen.
Gibt's da eventuell Screenshots?
Da alle 4 SSIDs vergeben.
Aber klar, vlan 10 darf nicht und fertig.
Oder aber zig Regeln mit je der Mac.
Ich muss da mal versuchen eine Regel zu erstellen.
Gibt's da eventuell Screenshots?
Für was für eine Regel denn genau ?? Auf IP oder Mac Basis ? Mac ist eher schlecht...
Dann müsste es doch theoretisch ein erlauben nach IP geben und ganz unten drunter eine Liste die den Rest verbietet.
Ja, ganz genau. Eine Firewall ACL Liste ist bekanntlich per se default immer "deny any any", sprich also alles per default verboten wenn du nix einträgst.
Du erlaubst also immer per IP. Ein explizites deny any am Schluss musst du nicht machen.
Du erlaubst also immer per IP. Ein explizites deny any am Schluss musst du nicht machen.
Und die Regel muss bei WAN2 rein oder?
Aktuell ist bei WAN noch keine Regel.
Ich weiss ja nicht ob da generell welche hinzugefügt werden müssen oder ob es so geht?
Alternativ könnte ja auch von Lan kommend blockiert werden in Richtung WAN.
Aktuell ist bei WAN noch keine Regel.
Ich weiss ja nicht ob da generell welche hinzugefügt werden müssen oder ob es so geht?
Alternativ könnte ja auch von Lan kommend blockiert werden in Richtung WAN.
Am WAN Port ist immer eine deny any any Regel inbound (eingehend) aktiv, logisch da dort ja meistens das offene Internet ist.
Allow Regeln brauchst du nur wenn du etwas das von außen kommt durchlassen willst nach innen.
In der Default Konfig klappt das schon so ohne spezifische Regeln, denn die Firewall lässt outbound Sessions natürlich im Default zu !
Auch der Default LAN Port hat einen Default Regel die alles nach außen erlaubt.
Deshalb klappt es in der Default Einstellung auf LAN und WAN. Das gilt aber nur außschlieslich für diese beiden Ports !
Alle anderen Ports OPT oder VLAN Ports etc. haben immer, und wie es bei FWs durchgehend üblich ist, eine deny any any Regel aktiv die man erst öffnen muss für das was man will was von innen raus darf.
Allow Regeln brauchst du nur wenn du etwas das von außen kommt durchlassen willst nach innen.
In der Default Konfig klappt das schon so ohne spezifische Regeln, denn die Firewall lässt outbound Sessions natürlich im Default zu !
Auch der Default LAN Port hat einen Default Regel die alles nach außen erlaubt.
Deshalb klappt es in der Default Einstellung auf LAN und WAN. Das gilt aber nur außschlieslich für diese beiden Ports !
Alle anderen Ports OPT oder VLAN Ports etc. haben immer, und wie es bei FWs durchgehend üblich ist, eine deny any any Regel aktiv die man erst öffnen muss für das was man will was von innen raus darf.
Alternativ könnte ja auch von Lan kommend blockiert werden in Richtung WAN.
Wäre der richtige Weg wenn du bestimmte Kommunikation nach außen unterbinden willst !
Also muss dem extra Interface, welches erst Opt war und nun halt in Wan2 umbenannt wurde, Robe Regel erstellt werden damit es überhaupt wie wan1 funktionieren will?
Aktuell sehe ich 2 Gateways.
Der zweite down, da im Test kein Kabel dran ist.
Werde ich aber mal testen
Aktuell sehe ich 2 Gateways.
Der zweite down, da im Test kein Kabel dran ist.
Werde ich aber mal testen
Robe Regel erstellt werden damit es überhaupt wie wan1 funktionieren will?
Was ist eine "Robe Regel" ??Ja, du musst das machen wenn du direkt NAT an der FW ins Internet machen willst.
Wenn externe Router NAT machen, die FW also nur in einer Kaskade rennt mit Routing dann natürlich nicht, dann musst du einzig lediglich die Regeln deinen Anforderungen anpassen, plus natürlich die Balancing Regeln einrichten.
Wie sieht denn dein finales Design jetzt aus ?? Statt der 2 IPCops eine zentrale pfSense mit 2 WAN Ports und daran dran die beiden FritzBoxen als NAT Router ins Internet ?
Robe sollte eine heißen, entschuldige bitte.
Ganz genau wie Du es sagst, so soll es sein.
IPCop1 wird temporär von einer alten IPCop Hardware übernommen und somit habe ich die eigentliche IPCop Hardware direkt für die PFSense frei und teste darauf.
4 Nics, allerdings werden jetzt durch Vlan nur 3 genutzt.
Aktuell habe ich immer die 39 als IP vergeben, da die frei ist und habe als Wan Test einen untagged vlan10 Port zugewiesen.
Somit gab es vom Gastnetz DHCP eine 10.x IP.
Ich werde die Hardware jetzt aber den FritzBoxen zuführen.
LAN 2 je an der FritzBox und somit kann ich parallel testen mit einem Rechner der die 39 dann als Gateway und DNS hat.
Ist ja egal ob der Exposed Host woanders hin zeigt.
Ganz genau wie Du es sagst, so soll es sein.
IPCop1 wird temporär von einer alten IPCop Hardware übernommen und somit habe ich die eigentliche IPCop Hardware direkt für die PFSense frei und teste darauf.
4 Nics, allerdings werden jetzt durch Vlan nur 3 genutzt.
Aktuell habe ich immer die 39 als IP vergeben, da die frei ist und habe als Wan Test einen untagged vlan10 Port zugewiesen.
Somit gab es vom Gastnetz DHCP eine 10.x IP.
Ich werde die Hardware jetzt aber den FritzBoxen zuführen.
LAN 2 je an der FritzBox und somit kann ich parallel testen mit einem Rechner der die 39 dann als Gateway und DNS hat.
Ist ja egal ob der Exposed Host woanders hin zeigt.
OK, oben in der zeichnung gibt es am Cisco Switch ja nur ein VLAN. Bleibt das so und auch die beiden Transfer Netze zu den FBs ?
Ggf. solltest du nochmal eine neue Zeichnung hier posten wie es im neuen IP Design aussehen soll.
Erleichtert sicher das Verständnis.
Ggf. solltest du nochmal eine neue Zeichnung hier posten wie es im neuen IP Design aussehen soll.
Erleichtert sicher das Verständnis.
Ich werde die Zeichnung noch mal aktualisieren.
Geändert hat sich eigentlich jetzt nur das die Leitung zum Switch von der PFSense jetzt tagged erfolgt im vlan und die Nic2 deaktiviert ist.
Ansonsten bleibt alles so.
Jetzt in der Testphase wo die 2 Cops noch laufen, ist die PFSense noch auf der 1.39
Dies ändert sich dann sofort wenn die Cops abgeschaltet werden und die PFSense den aktiven Betrieb übernimmt.
Geändert hat sich eigentlich jetzt nur das die Leitung zum Switch von der PFSense jetzt tagged erfolgt im vlan und die Nic2 deaktiviert ist.
Ansonsten bleibt alles so.
Jetzt in der Testphase wo die 2 Cops noch laufen, ist die PFSense noch auf der 1.39
Dies ändert sich dann sofort wenn die Cops abgeschaltet werden und die PFSense den aktiven Betrieb übernimmt.
OK, dann richtest du an der pfSense einen Dual WAN Port ein:
https://doc.pfsense.org/index.php/Multi-WAN
https://www.youtube.com/watch?v=omuklZrzopM
etc.
Schliesst daran die beiden FBs an richtest Balancing Policy und entsprechende Regeln ein und das wars.
https://doc.pfsense.org/index.php/Multi-WAN
https://www.youtube.com/watch?v=omuklZrzopM
etc.
Schliesst daran die beiden FBs an richtest Balancing Policy und entsprechende Regeln ein und das wars.
Balancing halt nicht.
Die 2. Verbindung darf nur der eine Client nutzen.
Bei Ausfall von Verbindung 1 darf das Failover auch nur ein ausgewählter Kreis nutzen.
Also auf Deutsch die Telekom Leitung darf nicht jeder nutzen
Die 2. Verbindung darf nur der eine Client nutzen.
Bei Ausfall von Verbindung 1 darf das Failover auch nur ein ausgewählter Kreis nutzen.
Also auf Deutsch die Telekom Leitung darf nicht jeder nutzen
Die 2. Verbindung darf nur der eine Client nutzen.
OK, ist ja ähnlich, rennt eben mit der ACL und der Policy die du eh anlegen musst.
Sodele
Nach einigen unschönen Terminen muss es weiter gehen.
Die PFSense ist jetzt am Bestimmungsort, wenn auch noch nicht produktiv.
Funktioniert auch noch nicht ;-(
Da das noch ein testbetrieb ist, ist sie noch auf hohen IPs.
192.168.1.39
Vlan10 192.168.10.39
TestVlan20 192.168.20.1
Die WAN Fritzboxen liegen jetzt auf
192.168.101.1 und 192.168.102.1
Da habe ich jetzt den gateway direkt angelegt.
Die IP jeweils beim WAN auf die 10 und den Gateway auf die 1
Die PFSense selber hat Internet.
Man kann die Package Liste laden etc.
Das VLAN20 ist neu, da ich den DHCP testen möchte in statischen Leases und das darf logischerweise nicht im produktiven Bereich wo ein anderer DHCP läuft passieren.
Das ganze ist in den Switches soweit geregelt und an einem Port kommt Vlan20 untagged raus um einen Rechner via Kabel anzuschliessne und zu testen.
Es wird auch eine 192.168.20.x IP vergeben.
Nur bekomme ich kein Internet.
Ich habe bei VLan 20 in den Rules eine Alles erlauben Regel erstellt.
Normalerweise dachte ich ich komme zumindest ins Netz.
Auf die PFSense komme ich, aber nicht weiter.
Hat sich da irgendwo anders durch den Umzug in den Keller und der statischen Umstellung ein Fehler eingeschlichen???
Oder liegt das an den neuen statischen Gateways?
Die IP sieht da beispielsweise so aus 192.168.101.11/24
Standard ist da /32 und ich habe auf /24 umgestellt, da ja eine Fritzbox in dem Fall auf der 101.1 liegt.
Steht es auf 32 bleibt es offline.
Ist das schon der Fehler??
Ich liste einfach die Veränderungen auf, bin nur ratlos.
Wie gesagt die hohen IPs sind im Testbetrieb nur aktiv.
Ich kann hier nicht alles zusammen brechen lassen, solange hier nichts richtig läuft.
Das muss vorerst parallel laufen und wenn es funktioniert stelle ich um.
Nach einigen unschönen Terminen muss es weiter gehen.
Die PFSense ist jetzt am Bestimmungsort, wenn auch noch nicht produktiv.
Funktioniert auch noch nicht ;-(
Da das noch ein testbetrieb ist, ist sie noch auf hohen IPs.
192.168.1.39
Vlan10 192.168.10.39
TestVlan20 192.168.20.1
Die WAN Fritzboxen liegen jetzt auf
192.168.101.1 und 192.168.102.1
Da habe ich jetzt den gateway direkt angelegt.
Die IP jeweils beim WAN auf die 10 und den Gateway auf die 1
Die PFSense selber hat Internet.
Man kann die Package Liste laden etc.
Das VLAN20 ist neu, da ich den DHCP testen möchte in statischen Leases und das darf logischerweise nicht im produktiven Bereich wo ein anderer DHCP läuft passieren.
Das ganze ist in den Switches soweit geregelt und an einem Port kommt Vlan20 untagged raus um einen Rechner via Kabel anzuschliessne und zu testen.
Es wird auch eine 192.168.20.x IP vergeben.
Nur bekomme ich kein Internet.
Ich habe bei VLan 20 in den Rules eine Alles erlauben Regel erstellt.
Normalerweise dachte ich ich komme zumindest ins Netz.
Auf die PFSense komme ich, aber nicht weiter.
Hat sich da irgendwo anders durch den Umzug in den Keller und der statischen Umstellung ein Fehler eingeschlichen???
Oder liegt das an den neuen statischen Gateways?
Die IP sieht da beispielsweise so aus 192.168.101.11/24
Standard ist da /32 und ich habe auf /24 umgestellt, da ja eine Fritzbox in dem Fall auf der 101.1 liegt.
Steht es auf 32 bleibt es offline.
Ist das schon der Fehler??
Ich liste einfach die Veränderungen auf, bin nur ratlos.
Wie gesagt die hohen IPs sind im Testbetrieb nur aktiv.
Ich kann hier nicht alles zusammen brechen lassen, solange hier nichts richtig läuft.
Das muss vorerst parallel laufen und wenn es funktioniert stelle ich um.
Da habe ich jetzt den gateway direkt angelegt.
Die IP jeweils beim WAN auf die 10 und den Gateway auf die 1
Bahnhof ???Die IP jeweils beim WAN auf die 10 und den Gateway auf die 1
Sorry aber was genau soll das bedeuten ?? Eine .10 gibt es als Host IP gar nicht und die .1 kann ja entweder die 101.1 oder die 102.1 sein ?? Verwirrung komplett...
Es wird auch eine 192.168.20.x IP vergeben.
Nur bekomme ich kein Internet.
OK, zeigt das der DHCP Server sauber rennt und die VLAN 20 Konfig auf auf dem Switch funktioniert....Nur bekomme ich kein Internet.
Was sagt ein ipconfig -all auf dem Endgerät ??
Stimmen DNS und Gateway ?? Sollte beides mal die pfSense IP im VLAN 20 sein !
Kannst du einen nackte Internet IP pingen z.B. 8.8.8.8 nur um DNS Problematiken auf dem VLAN 20 Endgerät auszuschliessen ?!
Wenn ipconfig soweit stimmt, dann gehe mal ins pfsense Menü Diagnostics - Ping und checke mal die Ping Connectivity von dort auf eine nackte Internet IP wie z.B. 8.8.8.8. Verwende dazu unbedingt als Source IP die IP des VLAN 20.
Mache das gleiche nochmal mit einem Traceroute. Wie weit kommst du ?
Die IP sieht da beispielsweise so aus 192.168.101.11/24
Welche ?? Die WAN IP der pfSense ?Standard ist da /32 und ich habe auf /24 umgestellt, da ja eine Fritzbox in dem Fall auf der 101.1 liegt.
Wenn du auf der FB eine 24 Bit Maske eingestellt hast, dann ist /24 ja auch richtig !Steht es auf 32 bleibt es offline.
Logisch, denn das ist eine Host IP ohne Netzwerk ! Bitte Nachdenken !!!
Also, das mit den IPs WAN Seitig sieht aktuell so aus.
FritzBox 1 hat 192.168.101.1
Der IPCop welcher noch aktiv läuft die 192.168.101.10
Die PFSense welche jetzt halt testweise läuft die 192.168.101.11/24
Das Ganze für WAN2 Analaog zu WAN1 nur mit der 102 statt der 101
Clientseitig Bekomme ich eine IP zugewiesen und Gateway/DNS stehen auf die IP der PFSense 192.168.20.1
Ping direkt ausgeführt von der PFSense aus dem VLan20 funktioniert zu www.google.de als auch zu 8.8.8.8
Also wird DNS ja auch aufgelöst.
Die ANY Regel im Post davor sollte doch erstmal ein Scheunentor machen oder?
FritzBox 1 hat 192.168.101.1
Der IPCop welcher noch aktiv läuft die 192.168.101.10
Die PFSense welche jetzt halt testweise läuft die 192.168.101.11/24
Das Ganze für WAN2 Analaog zu WAN1 nur mit der 102 statt der 101
Clientseitig Bekomme ich eine IP zugewiesen und Gateway/DNS stehen auf die IP der PFSense 192.168.20.1
Ping direkt ausgeführt von der PFSense aus dem VLan20 funktioniert zu www.google.de als auch zu 8.8.8.8
Also wird DNS ja auch aufgelöst.
Die ANY Regel im Post davor sollte doch erstmal ein Scheunentor machen oder?
Das Ganze für WAN2 Analaog zu WAN1 nur mit der 102 statt der 101
OK, das ist so richtig !Clientseitig Bekomme ich eine IP zugewiesen und Gateway/DNS stehen auf die IP der PFSense 192.168.20.1
Auch gut !Also wird DNS ja auch aufgelöst.
Perfekt ! Dann klappt doch alles...wo ist dann dein Problem ? Dann kanns ja nur ne falsche FW Regel auf dem VLAN 20 Port sein ?Was hast du da denn verbrochen ? Bedenke das die Reihenfolge hier zählt ! Es gilt immer First match wins !!
Die o.a. Regel ist also falsch.
Als Erstes miss da stehen:
PASS Source: vlan20_net, Source Port: any -> Destination: any, Desination Port: any
Schau dir das einfach vom LAN Port ab dort wo die Default Regel ist die an VLAN 20 muss identisch sein. (OK anderes Source Netz natürlich !)
Wenn du 2 WAN Ports hast, dann hast du hoffentlich auch das hier umgesetzt ??
https://doc.pfsense.org/index.php/Multi-WAN
http://www.tecmint.com/how-to-setup-failover-and-load-balancing-in-pfse ...
https://turbofuture.com/computers/Dual-Wan-Router-How-To-Build-One-On-a- ...
usw.
Wie oben schon geklärt, wird es kein Autofailover geben. Nicht für alle.
Policy Routing wird das.
Soweit bin ich aber noch nicht.
Ich habe das mal genauso als Regel erstellt wie Du geschrieben hast.
Es sah identisch aus wie die alte Regel, aber es funktionierte.
Das ist doch genauso wie hier gewesen oder nicht?
Da sind die beiden oberen deaktiviert gewesen.
Oder dauert das nach dem speichern und gültig machen mehrere Stunden bis die scharf werden?
Aber vom VLan20 kann man nicht über http in ein anderes Subnet.
Müsste die Scheunentorregel das nicht auch beinhalten?
Policy Routing wird das.
Soweit bin ich aber noch nicht.
Ich habe das mal genauso als Regel erstellt wie Du geschrieben hast.
Es sah identisch aus wie die alte Regel, aber es funktionierte.
Das ist doch genauso wie hier gewesen oder nicht?
Da sind die beiden oberen deaktiviert gewesen.
Oder dauert das nach dem speichern und gültig machen mehrere Stunden bis die scharf werden?
Aber vom VLan20 kann man nicht über http in ein anderes Subnet.
Müsste die Scheunentorregel das nicht auch beinhalten?
Oder dauert das nach dem speichern und gültig machen mehrere Stunden bis die scharf werden?
Nein, natürlich nicht ! Das ist mit Mausklick aktiv.Aber vom VLan20 kann man nicht über http in ein anderes Subnet.
Das ist ungewöhnlich. Da steckt irgendwo noch ein Fehler in der Konfig !Die any any Regel inkludiert das natürlich.
Hast du auch den Rückweg bedacht ?!
Thema Rückweg habe ich in einem anderen Thread von Dir mal angeschnitten gesehen.
Muss ich die selbe Regel bei dem anderen Subnet etwas modifiziert auch anlegen?
Also in dem Fall LAN 1 zu Vlan20?
Muss ich die selbe Regel bei dem anderen Subnet etwas modifiziert auch anlegen?
Also in dem Fall LAN 1 zu Vlan20?
Ja, denn du musst ja sehen das die Antwortpakete an dem Segment von dem die kommen nicht hängenbleiben.
Also im Zweifel da auch erstmal Scheunentor nur um erstmal zu checken das alles sauber durchgeht und dann Schritt für Schritt wieder zumachen...
Also im Zweifel da auch erstmal Scheunentor nur um erstmal zu checken das alles sauber durchgeht und dann Schritt für Schritt wieder zumachen...
Ich habe gerade geschaut.
Von Lan1 zu Any hatte ich schon eine Scheunentor Regel, eben weil ich immer in andere Netze kommen wollte vom Hauptnetz.
Nur ist da bestimmt wieder das selbe Problem gerade, was auch die 2 COPs mit sich gebracht haben.
Da die anderen Geräte noch via COP Gateway und DNS bekommen, passt die Rückroute zum anderen DNS nicht.
Kann das sein???
Von Lan1 zu Any hatte ich schon eine Scheunentor Regel, eben weil ich immer in andere Netze kommen wollte vom Hauptnetz.
Nur ist da bestimmt wieder das selbe Problem gerade, was auch die 2 COPs mit sich gebracht haben.
Da die anderen Geräte noch via COP Gateway und DNS bekommen, passt die Rückroute zum anderen DNS nicht.
Kann das sein???
Yepp, das kann sein. Setz doch einfach eine neue statische Route erstmal temporär um das zu fixen.
Das ist doch schnell gemacht.
Das ist doch schnell gemacht.
Ich habe testweise einem alten EeePC DNS und Gateway der PFSense gegeben und dann lief es.
Lag also daran.
Habe jetzt mal angefangen die static leases im DHCP zu schreiben.
Manuel in der dhcpd.conf scheint er das nicht zu fressen bzw einzulesen.
Bezüglich der Freigaben.
Bei mir kommt ja nicht hinz und kunz, sondern nur auserwählte ins Gastnetz.
In einem anderen Thread habe ich von Dir die ganzen Ports wie facetime etc gesehen.
An so etwas denkt man in der Regel ja nicht. Ich zumindest nicht.
Beim IPCop war/ist es ja so, dass das blaue Netz 8Gastnetz) uneingeschränkt ins Internet darf, nur die Netze gegeneinander abgeschirmt sind.
Ich glaube so würde ich das auch laufen lassen wollen bzw. die komplette Einschränkung nur beim wirklichen Gastnetz.
Dementsprechend wäre das doch eine Regel die zuerst alles verbietet und dann sage ich Vlanxx darf nur zu Wan1 und somit wäre doch das Internet gangbar, aber es könnte keiner in das lan1 rüber kommen oder?
Mit einer statischen Route könnte man dieses Phänomen was ich geschildert habe umgehen???
Lag also daran.
Habe jetzt mal angefangen die static leases im DHCP zu schreiben.
Manuel in der dhcpd.conf scheint er das nicht zu fressen bzw einzulesen.
Bezüglich der Freigaben.
Bei mir kommt ja nicht hinz und kunz, sondern nur auserwählte ins Gastnetz.
In einem anderen Thread habe ich von Dir die ganzen Ports wie facetime etc gesehen.
An so etwas denkt man in der Regel ja nicht. Ich zumindest nicht.
Beim IPCop war/ist es ja so, dass das blaue Netz 8Gastnetz) uneingeschränkt ins Internet darf, nur die Netze gegeneinander abgeschirmt sind.
Ich glaube so würde ich das auch laufen lassen wollen bzw. die komplette Einschränkung nur beim wirklichen Gastnetz.
Dementsprechend wäre das doch eine Regel die zuerst alles verbietet und dann sage ich Vlanxx darf nur zu Wan1 und somit wäre doch das Internet gangbar, aber es könnte keiner in das lan1 rüber kommen oder?
Mit einer statischen Route könnte man dieses Phänomen was ich geschildert habe umgehen???
Habe jetzt mal angefangen die static leases im DHCP zu schreiben.
Hier kannst du sehen wie das syntaktisch richtig ist in der .conf Datei:Netzwerk Management Server mit Raspberry Pi
Bei mir kommt ja nicht hinz und kunz, sondern nur auserwählte ins Gastnetz.
So sollte es auch sein ! Idealerweise natürlich mit einem Einmalpasswort:WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
bzw.
Voucher für pfSense online verwalten und optional Voucher per SMS verschicken
An so etwas denkt man in der Regel ja nicht. Ich zumindest nicht.
An was...??? Die Absicherung für Gäste ?? Solltest du aber...!das blaue Netz 8Gastnetz) uneingeschränkt ins Internet darf
Uuuuhhh. Riiisiko. Na wenigstens die bösesten Ports sollte man IMMER mit einer Whitelist sperren !! Da alles aufzumachen ist etwas blauäugig.Dementsprechend wäre das doch eine Regel die zuerst alles verbietet
Yepp...richtig ! Das wäre das Whitelist Prinzip.Mit einer statischen Route könnte man dieses Phänomen was ich geschildert habe umgehen???
Uuuhh... jetzt gleitest du aber ins Rate Nirvana ab. Was bitte haben denn Firewall Regeln mit Routing zu tun und andersrum...?Genausoviel wie ein Fisch mit einem Fahrrad...richtig...nämlich gar nix !
Denk mal etwas nach bevor du solche Klopper hier raushaust in einem Admin Forum...no comment !
aqui das ganz unten mit der statischen Route habe ich dann falsch verstanden. Das bezog sich auf Dein Post darüber und da sah ich nur Fragezeichen bzw. war selbst am zweifeln.
Noch mal zu den Routen.
Ich selbst bin Lan1
Das Gastnetz liegt auf Vlan_10
vom Lan1 soll ich ja überall hinkommen, auch in die anderen Netze.
Aus dem Grunde könnte ja eine Regel wie folgt gesetzt werden.
Source Lan1
Port & Destination * bzw any
Das sogenannte Gastnetz soll ins Internet kommen und nicht ins Lan1
Wenn ich dann eine Regel mit den einzelnen Ports definiere
z.B.
Source Vlan10
Port 80 Destination Any
dann könnte man aus dem gastnetz doch auch Port 80 im Lan1 erreichen, da man ja überall hin darf.
Um genau das zu unterbinden, müsste ich eine Gatewaygruppe (wegen 2xWAN) bilden und über die dann die Rules erstellen oder?
Im Gastnetz dann wie folgt
Source Vlan10
Port Any+
Destination GatewayGruppe bzw WAN...
Somit müsste es doch gesperrt sein oder?
Und dann hätte ich noch eine Frage zu den sogenannten bösen Ports.
Welche wären das? Gibt es da eine Liste?
Beim IPCop müsste denke ich aktuell alles auf sein.
Da wäre dann ja zuerst verbieten angesagt und ganz unten eine any Regel, da ja First Match winns und das wäre ja verbieten.
Quasi genau anders herum.
Verstehe ich das richtig und kann die Regeln so erstellen?
Noch mal zu den Routen.
Ich selbst bin Lan1
Das Gastnetz liegt auf Vlan_10
vom Lan1 soll ich ja überall hinkommen, auch in die anderen Netze.
Aus dem Grunde könnte ja eine Regel wie folgt gesetzt werden.
Source Lan1
Port & Destination * bzw any
Das sogenannte Gastnetz soll ins Internet kommen und nicht ins Lan1
Wenn ich dann eine Regel mit den einzelnen Ports definiere
z.B.
Source Vlan10
Port 80 Destination Any
dann könnte man aus dem gastnetz doch auch Port 80 im Lan1 erreichen, da man ja überall hin darf.
Um genau das zu unterbinden, müsste ich eine Gatewaygruppe (wegen 2xWAN) bilden und über die dann die Rules erstellen oder?
Im Gastnetz dann wie folgt
Source Vlan10
Port Any+
Destination GatewayGruppe bzw WAN...
Somit müsste es doch gesperrt sein oder?
Und dann hätte ich noch eine Frage zu den sogenannten bösen Ports.
Welche wären das? Gibt es da eine Liste?
Beim IPCop müsste denke ich aktuell alles auf sein.
Da wäre dann ja zuerst verbieten angesagt und ganz unten eine any Regel, da ja First Match winns und das wäre ja verbieten.
Quasi genau anders herum.
Verstehe ich das richtig und kann die Regeln so erstellen?
Noch mal zu den Routen. Ich selbst bin Lan1
OK, ich nehm' jetzt mal die o.a. Zeichnung zugrunde. VLAN 1 ist dann das 192.168.1.0 /24 Netzwerk, richtig ?Das Gastnetz liegt auf Vlan_10
Jepp, .10.0 /24 laut Zeichnung...passt !vom Lan1 soll ich ja überall hinkommen, auch in die anderen Netze.
Genau ! Solange du natürlich an der Default Firewall Regel nix geändert hast ?!Aus dem Grunde könnte ja eine Regel wie folgt gesetzt werden. Source Lan1, Port & Destination * bzw any
Ja richtig, aber die musst du nicht extra setzen, denn die ist in der Default Konfig der pfSense schon so gesetzt. Kannst du auch sehen in den "FW Rules".VLAN 1 ist immer das native Parent Interface (untagged) auf dem diese Regel dann aktiv ist.
Das sogenannte Gastnetz soll ins Internet kommen und nicht ins Lan1
Das haben Gastnetze in der Regel so an sich Wenn ich dann eine Regel mit den einzelnen Ports definiere z.B. Source Vlan10, Port 80 Destination Any dann könnte man aus dem gastnetz doch auch Port 80 im Lan1 erreichen, da man ja überall hin darf.
Ja richtig !Ist auch logisch, denn du gibts ja als Destination Any an und das inkludiert dann logischerweise alles, also auch dein VLAN 1 !
Um genau das zu unterbinden, müsste ich eine Gatewaygruppe (wegen 2xWAN) bilden und über die dann die Rules erstellen oder?
Nein, falsch !!Die definierst in den Gastnetz Regeln VOR allen Regeln folgendes:
DENY Source: VLAN 10 net, Destination: VLAN 1 net
PASS Source: VLAN 10 net, Destination: any, Port UDP/TCP 53 DNS
PASS Source: VLAN 10 net, Destination: any, Port TCP 80 HTTP
(Das erlaubt z.B. rein nur Browsing, HTTP im Gastnetz !)
Dann kann nix mehr vom VLAN 10 ins VLAN 1 aber alles was du erlaubst aus dem VLAN 10 in die große weite Welt !
Eigentlich ganz logisch !
Um genau das zu unterbinden, müsste ich eine Gatewaygruppe
Nein, viel zu umständlich, geht einfacher. Siehe oben.Oder hab ich dich jetzt falsch verstanden ?!?
Und dann hätte ich noch eine Frage zu den sogenannten bösen Ports.
Hier denkst du ganz falsch !!Niemals eine Blacklist machen, sondern mache immer eine Whitelist !!!
D.h. du erlaubst alles was DU im Gastnetz willst und nur das ! Also z.B. Browsen und Email. Damit blockst du dann so oder so immer alles automatisch was böse ist !
Wenn ein Gast z.B. Telnet machen will wird er sich schon bei dir melden ! Du generierst dann am besten unter Aliases eine Liste und trägst da TCP 23 nach.
So bekommst du sukzessive eine Liste die unter deiner Kontrolle ist was im Gastnetz geht und was nicht als ewig Ports hinterherzuhecheln die du sperren musst ! Immer clever denken...
Beim IPCop müsste denke ich aktuell alles auf sein.
Wäre sehr verwunderlich bei einer Firewall und ist vermutlich falsch ! Goldene Default Grundregel bei einer Firewall: "Es ist alles verboten was der Admin nicht explizit erlaubt !"Das sollte beim IPCop keineswegs anders sein.
Da wäre dann ja zuerst verbieten angesagt und ganz unten eine any Regel, da ja First Match winns und das wäre ja verbieten.
Generell stimmt diese Aussage. Gilt aber nur wenn du mit "Any" arbeiten musst. Dort muss man natürlich VORHER einschränken und dann erst erlauben. Wenn du dediziert etwas erlaubst, dann muss man es nicht.Pauschla kann man das nicht sagen da es IMMER von deinem individuellen Regelwerk abhängt !
So.
Ich habe mich mal hingesetzt und mir Gedanken gemacht und eine Portliste von Dir aus einem anderen Thread zu Hilfe genommen.
Für die Gäste habe ich so das regelwerk erstellt
Ganz oben wollte ich erreichen, dass ein Port aus dem Vlan in das Lan durchgelassen wird.
Die Regel habe ich nach ganz oben geschoben, da ich darunter alles verbiete.
Leider funktioniert diese Regel nicht.
Liegt es da vielleicht an der Rückroute die ich setzen sollte?
LoadBalancing ist ja nicht gewollt.
Ein Failover ist gewollt und wird auch wieder erstellt. Ging nicht mehr nach der Wan Umstellung.
Ein Client soll aber permanent Gateway 2 Telekom benutzen.
Ich habe dafür eine Firewall Regel im lan erstellt.
Das funktioniert so, jedoch wollte ich noch mal hinterfragt haben ob das so der richtige Weg dafür war/ist?
Dementsprechend würde die Failover Regel nur im Lan erstellt werden und das Gastnetz wäre ausgeschlossen nehme ich an.
Dies zu der Firewall.
Dann habe ich ein uraltes Tut von Dir ausgegraben wo das Thema OpenVPN behandelt wird
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Ich kenne es vom IPCop so, dass ich ein CA Zertifikat erstelle und dann die einzelnen User.
Die User haben dann die Zertifikate und wenn man sich dann verbinden möchte, wird ein Kennwort abgefragt.
So kenne ich das und finde es nicht schlecht.
Auf PFSense übertragen gehe ich also in den Cert-Manager und erstelle das CA Zertifikat.
Dein Tutorial verstehe ich dann alelrdings so, dass das Feld daneben, Certificates, die einzelnen Userzertifikate sind.
Gehe ich allerdings unter VPN / OpenVPN schauen, dann habe ich da das Menü Clients.
Ich würde denken, dass dort die einzelnen Clients angelegt werden.
Nur was macht dann das obere Certificates?
Mühsam ernährt sich das Eichhörnchen, aber es wird.
Ich habe mich mal hingesetzt und mir Gedanken gemacht und eine Portliste von Dir aus einem anderen Thread zu Hilfe genommen.
Für die Gäste habe ich so das regelwerk erstellt
Ganz oben wollte ich erreichen, dass ein Port aus dem Vlan in das Lan durchgelassen wird.
Die Regel habe ich nach ganz oben geschoben, da ich darunter alles verbiete.
Leider funktioniert diese Regel nicht.
Liegt es da vielleicht an der Rückroute die ich setzen sollte?
LoadBalancing ist ja nicht gewollt.
Ein Failover ist gewollt und wird auch wieder erstellt. Ging nicht mehr nach der Wan Umstellung.
Ein Client soll aber permanent Gateway 2 Telekom benutzen.
Ich habe dafür eine Firewall Regel im lan erstellt.
Das funktioniert so, jedoch wollte ich noch mal hinterfragt haben ob das so der richtige Weg dafür war/ist?
Dementsprechend würde die Failover Regel nur im Lan erstellt werden und das Gastnetz wäre ausgeschlossen nehme ich an.
Dies zu der Firewall.
Dann habe ich ein uraltes Tut von Dir ausgegraben wo das Thema OpenVPN behandelt wird
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Ich kenne es vom IPCop so, dass ich ein CA Zertifikat erstelle und dann die einzelnen User.
Die User haben dann die Zertifikate und wenn man sich dann verbinden möchte, wird ein Kennwort abgefragt.
So kenne ich das und finde es nicht schlecht.
Auf PFSense übertragen gehe ich also in den Cert-Manager und erstelle das CA Zertifikat.
Dein Tutorial verstehe ich dann alelrdings so, dass das Feld daneben, Certificates, die einzelnen Userzertifikate sind.
Gehe ich allerdings unter VPN / OpenVPN schauen, dann habe ich da das Menü Clients.
Ich würde denken, dass dort die einzelnen Clients angelegt werden.
Nur was macht dann das obere Certificates?
Mühsam ernährt sich das Eichhörnchen, aber es wird.
Für die Gäste habe ich so das Regelwerk erstellt
Das sieht auch schon sehr gut aus.Ganz oben wollte ich erreichen, dass ein Port aus dem Vlan in das Lan durchgelassen wird.
Das ist irgendwie unverständlich...und stimmt NICHT mit dem geposteten Screenshot überein, denn deine erste Regel ist das Erlauben des Captive Portals bzw. der Webpage !Das ist auch so richtig wenn man mal von der Tatsache absieht, das du einen falschen CP Port benutzt.
Hier ist mal ein Screenshot einer sehr einfachen Regel für ein Captive Portal Segment was nur Webbrowsing erlaubt:
Wie du siehst werden immer erst DNS Auflösung erlaubt sonst funktioniert generell kein DNS, dann die Captive Portal Seite des Gastsegments, die ja immer erscheinen muss.
Danach wird der Zugriff aufs Heimnetz generell verboten und dann HTTP und HTTPS in den Rest der Welt (Internet) erlaubt.
Deine Beschriftung der Regel ist irreführend oder dein CP liegt irgendwi nicht auf der Firewall selber, was dann nicht funktionieren würde.
Generell erlaubt diese erte Regel bei dir den Zugriff von jeglichem Host aus dem VLAN-20 Gastnetz auf einen einzigen Host mit der IP 192.168.1.4 und dem Zielport 8880.
Dieser Traffic wird also passieren.
Antwortet der Host 192.168.1.4 kommt dieser Traffic auch durch. Natürlich nur wenn du am Firewall LAN Port des 192.168.1.0er Netzes keine Regel erstellt hast die das VLAN20 Gastnetz als Ziel hat. Ansonsten würde das Antwortpaket natürlich dort gefiltert...klar.
Das wäre ein möglicher Grund warum diese Regel nicht greift bei dir. Hast du mal ins Firewall Log der FW gesehen ???
Liegt es da vielleicht an der Rückroute die ich setzen sollte?
Wie meinst du das mit "Rückroute setzen" ???Das .1.0er Segment wird doch sicher direkt an der FW dran sein oder ?
Wenn der Host .1.4 einen Gateway Eintrag auf die Firewall IP in diesem IP Segment hat ist doch alles richtig. Eine Rückroute ist dann Unsinn, denn es sind ja lokale Netze die direkt an der FW dran sind ?! Warum also Rückroute ? Es reicht vollkommen wenn das Gateway stimmt es sei denn du routest über ein anderes Gateway ?!
LoadBalancing ist ja nicht gewollt.
OK, das vereinfacht die Sache dann... Das funktioniert so, jedoch wollte ich noch mal hinterfragt haben ob das so der richtige Weg dafür war/ist?
Ja, ist der richtige Weg und passt !Dann habe ich ein uraltes Tut von Dir ausgegraben wo das Thema OpenVPN behandelt wird
Ja und das ist auch noch weiter aktuell auch für die aktuelle pfSense Version im neuen GUI.Ich kenne es vom IPCop so, dass ich ein CA Zertifikat erstelle und dann die einzelnen User.
Jau, genau richtig. Eine Standardprozedur bei OpenVPN mit dem mitgelieferten easy-rsa. Man kann aber auch andere Tools verwenden.Das ist übrigens vollkommen unabhängig von Plattform und Betriebsystem bei OpenVPN. Ein großer Vorteil dieser VPN Lösung.
wenn man sich dann verbinden möchte, wird ein Kennwort abgefragt.
Oooopss...nein falsch !Bei Zertifikaten ist ein Kennwort doch Blödsinn. Das ist doch gerade der tiefere Sinn von Zertifikaten !
Du kannst OVPN auch nur mit Passwörtern aufsetzen aber davon sollte man Abstand nehmen. Das ist vermeitlich einfacher, weil man sich die Zertifikatserstellung spart oder sparen kann.
Hat aber den gravierenden Nachteil statischer Passwörter.
Verrät nur einer deine Clients oder User das Passwort ist das gesamte VPN kompromittiert und du müsst es für ALLE ändern. Bei Zertifikaten ist das nicht der Fall, denn die sind User spezifisch.
Hier hast du also was bei OVPN missverstanden oder gründlich falsch gemacht mit dem IPCop.
Du erzeugst immer ein Root Zertifikat über System -> CertManager,
Ich nehme das aber mal als Anlass und Aufforderung das Tutorial mal mit neuen Screenshots upzudaten.
Also das Problem mit dem 8880 ist gelöst.
Es war wie immer meine Dummheit beim Testen zu vergessen den 192.168.1.4 Rechner auf die PFSense mit Gateway und DNS umzustellen.
Mal sehen wie lange ich noch auf die heisse Herdplatte fasse.
Was mir nur aufgefallen ist und was doof ist, dass wenn das Regelwerk so wie oben steht, dass ich dann aus dem VLAN 20 jeglichen Rechner im LAN1 erreiche, wenn dieser einen Webserver hat.
In dem Fall habe ich einfach 192.168.1.4 eingegeben im Browser und der Rechner hat auf Port80 geantwortet.
Dies soll ja nun gar nicht sein.
Ich gehe davon aus, dass die VLAN 20 Rules dann nicht auf Destination Any zeigen dürfen, sondern explizit auf WAN.
Macht es da jetzt Sinn eine WAN Gruppe zu erstellen, damit nicht jede Regel doppelt erstellt werden muss (Einmal WAN1 & einmal WAN2)?
Eine verbieterregel im Lan1 funktioniert da nicht leider nicht wie ich gesehen habe.
Generell muss man aber bei Source keinen Port angeben, da der sich aus dem Zielport ergibt wie ich das verstehe oder?
Würde ich Source 80 und Destination 81 sagen, so würde die Firewall auf Port 80 was erwarten und auf 81 am Ziel lenken.
Thema VPN.
Ich erstelle ein CA Certifikat unter System -> Cert Manager -> CA
Aber was wird unter System -> Cert Manager -> Certificates erstellt? Einige Tuts verstehe ich so, dass dort die Userzertifikate erstellt werden.
Wenn ich Dich im obigen Post verstehe, lasse ich das Certificates im Cert Manager weg und erstelle nur ein CA.
Die User lege ich dann unter VPN -> OpenVPN -> Clients an.
Und da hatte der IPCop standardmässig um es mit Deinen Worten zu sagen zum Gürtel noch den Hosenträger.
Daher kenne ich das. Fand ich jetzt auch nicht so schlecht.
Unter VPN -> OpenVPN -> Server definiert man dann quasi noch auf welchen Port VPN horcht und vergibt das Subnet und das wars dann dementsprechend hoffe ich für die Verbindung.
Dadurch dann in den Firewall Rules OpenVPN definieren.
Entweder je Port einzeln analog zu Vlan20 oder eine Any wenn man es nur selbst nutzt und kein anderer. Ist ja auch privat die Firewall und keine Firma bzw Fremde die VPN nutzen.
Bin ich da so langsam auf dem richtigen Weg?
Es war wie immer meine Dummheit beim Testen zu vergessen den 192.168.1.4 Rechner auf die PFSense mit Gateway und DNS umzustellen.
Mal sehen wie lange ich noch auf die heisse Herdplatte fasse.
Was mir nur aufgefallen ist und was doof ist, dass wenn das Regelwerk so wie oben steht, dass ich dann aus dem VLAN 20 jeglichen Rechner im LAN1 erreiche, wenn dieser einen Webserver hat.
In dem Fall habe ich einfach 192.168.1.4 eingegeben im Browser und der Rechner hat auf Port80 geantwortet.
Dies soll ja nun gar nicht sein.
Ich gehe davon aus, dass die VLAN 20 Rules dann nicht auf Destination Any zeigen dürfen, sondern explizit auf WAN.
Macht es da jetzt Sinn eine WAN Gruppe zu erstellen, damit nicht jede Regel doppelt erstellt werden muss (Einmal WAN1 & einmal WAN2)?
Eine verbieterregel im Lan1 funktioniert da nicht leider nicht wie ich gesehen habe.
Generell muss man aber bei Source keinen Port angeben, da der sich aus dem Zielport ergibt wie ich das verstehe oder?
Würde ich Source 80 und Destination 81 sagen, so würde die Firewall auf Port 80 was erwarten und auf 81 am Ziel lenken.
Thema VPN.
Ich erstelle ein CA Certifikat unter System -> Cert Manager -> CA
Aber was wird unter System -> Cert Manager -> Certificates erstellt? Einige Tuts verstehe ich so, dass dort die Userzertifikate erstellt werden.
Wenn ich Dich im obigen Post verstehe, lasse ich das Certificates im Cert Manager weg und erstelle nur ein CA.
Die User lege ich dann unter VPN -> OpenVPN -> Clients an.
Und da hatte der IPCop standardmässig um es mit Deinen Worten zu sagen zum Gürtel noch den Hosenträger.
Daher kenne ich das. Fand ich jetzt auch nicht so schlecht.
Unter VPN -> OpenVPN -> Server definiert man dann quasi noch auf welchen Port VPN horcht und vergibt das Subnet und das wars dann dementsprechend hoffe ich für die Verbindung.
Dadurch dann in den Firewall Rules OpenVPN definieren.
Entweder je Port einzeln analog zu Vlan20 oder eine Any wenn man es nur selbst nutzt und kein anderer. Ist ja auch privat die Firewall und keine Firma bzw Fremde die VPN nutzen.
Bin ich da so langsam auf dem richtigen Weg?
Was mir nur aufgefallen ist und was doof ist, dass wenn das Regelwerk so wie oben steht, dass ich dann aus dem VLAN 20 jeglichen Rechner im LAN1 erreiche, wenn dieser einen Webserver hat.
Das ist ja auch kein Wunder, weil du keinerlei Regel hast die das verbietet !!In sofern ist dein Regelwerk oben ja auch vollkommen falsch !
Dort ist eine Regel auf dem VLAN 20 Interface definiert die VLAN-10 Absender IP Adressen blocken soll ins LAN 1.
Da fragt man sich dann allen Ernstes WO denn diese Absenderpakete am VLAN 20 Interface herkommen sollen die eine VLAN-10 IP Adresse als Absender haben??
Diese Regel ist also schlicht Unsinn und damit überflüssig, denn am VLAN 20 können inbound ja nur Pakete kommen die VLAN 20 IPs als Absender Adresse haben !! Wo sollten denn hier VLAN10 Absender Adressen herkommen ??
Folglich sollte die BLOCKING Regel an VLAN-20 FW Port dann auch lauten:
PASS: Source: VLAN-20_net, Port: any , -> Destination: Host: 192.168.1.4, Port: TCP 8880
DENY, Source: VLAN-20_net, Port: any , -> Destination: LAN 1_net, Port: any
Dann ist auch Schluss mit dem Zugriff von Gast VLAN 20 auf dein LAN 1 außer eben auf den Host .1.4 mit Port TCP 8880 !!
Fazit: Wieder ne heisse Herdplatte !! Richtige Regel ergibt auch richtiges Verhalten. Es lohnt immer mal logisch zu denken beim Aufsetzen der FW Regeln
Nimm dir im Zweifel immer den Wireshark zur Hand auf deinem Client PC und sieh dir dort an WIE deine IP Pakete ans Ziel adressiert sind.
Besser als im Wireshark kann man es nicht sehen und es lernen...
Ich gehe davon aus, dass die VLAN 20 Rules dann nicht auf Destination Any zeigen dürfen, sondern explizit auf WAN.
Nein, falsch !Bei WAN könnten sie dann nur nicht auf Ziel IPs im WAN Segment zugreifen. Ist ja Unsinn weil du da im WAN IP Netz ja gar keine Ziel Endgeräte hast...vergessen also.
Any bedeutet alle übrigen Destination IP Adressen außer den im Regelwerk am Port definierten. Da man nicht Milliarden IPv4 Internet Adressen explizit definieren will (was man theoretisch könnte) nimmt man halt den Schrotschuss Any.
Eine verbieterregel im Lan1 funktioniert da nicht leider nicht wie ich gesehen habe.
Na ja... wieder die Herdplatte !! Logisch denken !!!Du hast am LAN-1 Interface eine Regel erstellt die Absender IPs aus VLAN 20 ins eigene LAN 1 Netz blocken sollen.
Der Blödsinn fällt dir vermutlich jetzt auch sicher selber auf...oder ??
Gleiches Thema wie oben...unsinige Absender IP Adressdefinition.
Wie sollen bitte sehr am LAN 1 Segment inbound (eingehend) dort IP Pakete mit einer VLAN-20 Absender IP eingehen ??? Du bist doch am LAN 1 Segment der FW und da können logischerweise nur Pakete eingehen die auch LAN 1 IP Absenderadressen ala 192.168.1.x haben ! Niemals aber .20.x (VLAN-20)
Dann Adressen in der Destination zu filtern die aufs eigene Netz zeigen ist auch Blödsinn. Solche IP Adress Konstellation in eimem Paket dort kann es niemals geben an dem Port.
LAN-1 Destination am LAN-1 Port gehen ja ga nicht über die FW sondern bleiben selber in der L2 Domain. Die FW ist da gar nicht involviert.
Fazit: Völlig unlogische Regeln, die natürlich auch nicht greifen können.
Wenn, dann müsste hier an LAN 1 stehen:
PASS: Source IP: Host:192.168.1.4, Destination IP: VLAN-20_net
DENY: Source IP: LAN-1_net , Destination IP: VLAN-20_net
Das lässt dan den Traffic vom Host .1.4 ins VLAN 20 durch, blockt aber den Rest allen Traffics vom LAN-1 Netz ins VLAN 20 Netz.
Da du aber schon so eine Regel am VLAN 20 Port hast (s.o.) wäre diese nicht unbedingt nötig am LAN-1 Port, da sie quasi das gleiche nochmal macht zw. LAN-1 und VLAN-20.
Das wäre dann die ganz wasserdichte Lösung...
Also nochmal: Bitte logisch nachdenken wie IP Pakete aussehen mit ihren Absender und Ziel IPs und wie sie sich im Regelwerk bewegen. Dann kommt auch nicht so ein unlogisches Durcheinander sprich heisse Herplatte dabei raus.
Generell muss man aber bei Source keinen Port angeben, da der sich aus dem Zielport ergibt wie ich das verstehe oder?
Nein. Stimmt nur bedingt. https://de.wikipedia.org/wiki/Transmission_Control_ProtocolGrob gesehen stimmt es. Der Source Port ist so gut wie immer Random >1023 (Zufall). Wichtig ist der Destination Port, denn der bestimmt am Ziel welche Applikation angesprochen wird. Z.B. TCP 80 = HTTP (Webserver)
So gesehen ist der Destination Port meist immer der relevantere und wichtigere bei FW Regeln wenn man Dienste filtern oder erlauben will.
Aber was wird unter System -> Cert Manager -> Certificate s erstellt?
Nein, nicht die Server und Clients Certs bei OpenVPN, die generiert man unter Service - OpenVPN unter bezugnachem auf die generierte Root CA. Ist mehr oder weniger genau der gleiche Prozess wie mit easy-rsa auf dem CLI nur eben unter einem GUI.Fand ich jetzt auch nicht so schlecht.
OK, kann man machen aber verkompliziert das User Handling etwas. Letztlich aber immer eine Sicherheits Policy die jeder mit sich selber ausmachen muss, keine Frage.Unter VPN -> OpenVPN -> Serve r definiert man dann quasi noch auf welchen Port VPN horcht und vergibt das Subnet und das wars dann dementsprechend hoffe ich für die Verbindung.
Jepp, genau richtig ! UDP 1194 ist der OVPN Default. Generell sollte man wegen des Overheads keine TCP Encapsulation wählen.Dadurch dann in den Firewall Rules OpenVPN definieren.
Richtig. Am WAN Port musst du schlicht und einfach nur PASS: Source IP: Any, Port: Any, Destination: WAN IP Adress, Port: UDP 1194 erlauben. (Jede Internet IP darf mit UDP 1194 auf die FW WAN IP zugreifen für OVPN)Bin ich da so langsam auf dem richtigen Weg?
So einigermaßen... 
Hmpf das war ja ein doofer Fehler.
Da habe ich die Rule von VLAN 10 kopiert und die Source nicht geändert.
Asche auf mein Haupt. An sich war die Regel ja da, nur ein Fehler drin. So fatal kanns enden.
Und da starrt man drauf und sieht es nicht ;-(
Sorry dafür.
Ich habe jetzt mal 3 Stunden versucht das Failover lauffähig zu haben, aber irgendwie bockt auch das ;-(
Ich habe die 2 WANs erstellt, die haben je eine Monitor IP und funktionieren auch, zumindest werden sie als online angezeigt.
Ich komme wenn ich jeweils die GatewayIP aufrufe auf die entsprechend vorgelagerte FritzBox.
Als nächstes habe ich 2 Gatewaygruppen erstellt und je anders prioritisiert.
Unter System general Setup habe ich verschiedene DNS Einstellungen probiert, aber ob so oder auf google gestellt, geht es nicht.
Dann noch die 2 Lan Rules dafür mit den alternativen Gateways.
Da habe ich die any any ganze unten schon deaktiviert testweise, aber bringt mich nicht nach vorne.
Einschränken über Hosts werde ich später, deshalb deaktiviert.
Ist doch echt zum verzweifeln, wenn die PFSense solch ein Eigenleben hat.
Zum Testen habe ich die Hauptfritzbox neugestartet.
Man kann dann schön den Paketloss beobachten und dann wird der Gateway auf offline geschaltet.
Ab dem Zeitpunkt kann ich zwar google aufrufen, aber keine neuen Seiten.
Als ob das noch aus dem Cache kommt.
Komischwerweise wenn ich die Seite www.wieistmeineip.de offen habe und die aktualisiere, ändert sich das ganze auf die Telekom IP.
Aber warum nur geht nicht mehr?
DNS Fehler?
Da habe ich die Rule von VLAN 10 kopiert und die Source nicht geändert.
Asche auf mein Haupt. An sich war die Regel ja da, nur ein Fehler drin. So fatal kanns enden.
Und da starrt man drauf und sieht es nicht ;-(
Sorry dafür.
Ich habe jetzt mal 3 Stunden versucht das Failover lauffähig zu haben, aber irgendwie bockt auch das ;-(
Ich habe die 2 WANs erstellt, die haben je eine Monitor IP und funktionieren auch, zumindest werden sie als online angezeigt.
Ich komme wenn ich jeweils die GatewayIP aufrufe auf die entsprechend vorgelagerte FritzBox.
Als nächstes habe ich 2 Gatewaygruppen erstellt und je anders prioritisiert.
Unter System general Setup habe ich verschiedene DNS Einstellungen probiert, aber ob so oder auf google gestellt, geht es nicht.
Dann noch die 2 Lan Rules dafür mit den alternativen Gateways.
Da habe ich die any any ganze unten schon deaktiviert testweise, aber bringt mich nicht nach vorne.
Einschränken über Hosts werde ich später, deshalb deaktiviert.
Ist doch echt zum verzweifeln, wenn die PFSense solch ein Eigenleben hat.
Zum Testen habe ich die Hauptfritzbox neugestartet.
Man kann dann schön den Paketloss beobachten und dann wird der Gateway auf offline geschaltet.
Ab dem Zeitpunkt kann ich zwar google aufrufen, aber keine neuen Seiten.
Als ob das noch aus dem Cache kommt.
Komischwerweise wenn ich die Seite www.wieistmeineip.de offen habe und die aktualisiere, ändert sich das ganze auf die Telekom IP.
Aber warum nur geht nicht mehr?
DNS Fehler?
Deine Regeln am LAN1_Home sind mal wieder unsinnig. Die erlaubst dediziert das LAN1_Home an 2 Failovers und unten erlaubts du so oder so LAN1_Home an Any ! Unlogisch und sinnfrei.
Als DNS Server für die einzelnen Links sollte immer nur der Proxy DNS des angekoppelten Routers FritzBox eingetragen werden. Bzw. in der statischen Definition dann diese beiden DNS.
Dein 2ter WAN Port ist der OPT1 Port. Hast du diesen auch für NAT aktiviert ?? Der WAN Port macht ja per Default NAT. Bei einem 2ten Port musst du das explizit aktivieren.
Wie ist denn deine Failover oder Balancing Policy gesetzt. Machst du Round Robin oder ein dediziertes Forwarding je nach Absender IP Netzwerk mit Failover ?
Ein Eigenleben gibts logischerweise nicht. Die macht genau das was du ihr in der Konfig vorgibst....
Als DNS Server für die einzelnen Links sollte immer nur der Proxy DNS des angekoppelten Routers FritzBox eingetragen werden. Bzw. in der statischen Definition dann diese beiden DNS.
Dein 2ter WAN Port ist der OPT1 Port. Hast du diesen auch für NAT aktiviert ?? Der WAN Port macht ja per Default NAT. Bei einem 2ten Port musst du das explizit aktivieren.
Wie ist denn deine Failover oder Balancing Policy gesetzt. Machst du Round Robin oder ein dediziertes Forwarding je nach Absender IP Netzwerk mit Failover ?
Ein Eigenleben gibts logischerweise nicht. Die macht genau das was du ihr in der Konfig vorgibst....
Deine Regeln am LAN1_Home sind mal wieder unsinnig. Die erlaubst dediziert das LAN1_Home an 2 Failovers und unten erlaubts du so oder so LAN1_Home an Any ! Unlogisch und sinnfrei.
Ich hatte im Test die unteren Regeln auch deaktiviert.
In dem Tutorial stand die sollen weg, also vorerst deaktiviert.
Löschen kann man ja immer.
Als DNS Server für die einzelnen Links sollte immer nur der Proxy DNS des angekoppelten Routers FritzBox eingetragen werden. Bzw. in der statischen Definition dann diese beiden DNS.
Nach meinem Verständnis dann so wie auf dem Bild, jeweils nur die IP der vorgelagerten FritzBox oder?
Dein 2ter WAN Port ist der OPT1 Port. Hast du diesen auch für NAT aktiviert ?? Der WAN Port macht ja per Default NAT. Bei einem 2ten Port musst du das explizit aktivieren.
Hmmm. Das würde schon nach dem Fehler klingen, da dann ja keine Rückantwort kommen kann.
Nach meinem Verständnis des folgendes Bildes müsste es aber an sein.
Wie ist denn deine Failover oder Balancing Policy gesetzt. Machst du Round Robin oder ein dediziertes Forwarding je nach Absender IP Netzwerk mit Failover ?
Failover gibt es ja nur und da gibt es nur das was ich mit den Bildern dokumentiert habe.
In dem Fall nur Lan1_Home und nicht die anderen Vlans.
Wenn es funktioniert, dann werde ich es über die Alias Liste etwas mehr einschränken, allerding muss es dazu ja erstmal laufen und extra Fallstricke möchte ich mir gerade nicht legen.
Ein Eigenleben gibts logischerweise nicht. Die macht genau das was du ihr in der Konfig vorgibst....
In dem Fall sitzt der Fehler vor dem Gerät, ich weiss.
Aber der Versuch dies zu ändern ist ja im Gange.
Nach meinem Verständnis dann so wie auf dem Bild, jeweils nur die IP der vorgelagerten FritzBox oder?
Richtig !Das würde schon nach dem Fehler klingen, da dann ja keine Rückantwort kommen kann.
Auch richtig. Wichtig hier WIE sehen deinen Routing Groups aus ?? System - Routing -GroupsDer Screenshot wäre hilfreich !
Mit den FW Gegeln und der Zuweisung auf die Group definierst du ja wie der Traffic über die 2 WAN Port gesteuert wird.
Öhm, ich habe da nur das, was ich als Bilder habe.
Gateway Groups und keine Routing Groups.
Müsste heute Abend erstmal schauen wie die anzulegen sind.
Gateway Groups und keine Routing Groups.
Müsste heute Abend erstmal schauen wie die anzulegen sind.
Ja, die Gateway Groups werden ja im Menü Routing --> Groups definiert.
Der Screenshot fehlte irgendwie noch.
Der Screenshot fehlte irgendwie noch.
Wenn das nicht das hier ist, dann habe ich es nicht und muss schauen was ich da machen muss.
Hast Du da einen Screenshot auf Lager?
Hast Du da einen Screenshot auf Lager?
Da ich bei dem Failover mit den gateway Groups nicht weiter gekommen bin, habe ich mich mal aktiv an OpenVPN gewagt.
Da muss ich sagen war es über den IPCop sehr viel einfacher gestrickt.
Da lief es über eine p12 Datei und die benötigte configdatei mit den DDNS Angaben, Port und Dateinamen der p12 waren da schon hinterlegt.
Diese 2 Datein seiner Zeit in den config Ordner geschoben und ab ging die wilde fahrt.
Aber es soll ja nun die PFSense werden und aufgeben ist eigentlich nicht das Ziel. Dümmer wird man ja auch nicht.
Vorab gesagt ich habe etwas rum getestet und TLS am Server deaktiviert.
In der Clientconfig wurde es auskommentiert und danach hat er sich verbunden.
Ich bekam die 10.20.40.2 zugewiesen. Bei Eingabe von 192.168.1.39 (PFSense aktuell selbst) gab es ein Timeout.
Das hätte doch die Regel dann machen müssen oder wäre die PFSense selbst nur unter 10.20.40.1 erreichbar?
Bzw hätte die Regel bei OpenVPN jeweils in die Subnetze als Destination zeigen müssen?
Aufgefallen ist mir auch, dass man unter Interface -> assign den VPN Server hinzufügen kann.
Muss man dies? Sorry vielleicht eine doofe Frage, aber im Tut steht es nicht.
Was habe ich getan ich sonst so eingestellt.
Ich habe mit Deinem Tutorial OpenVPN installieren gearbeitet soweit es ging aufgrund der neuen PFSense, da sind einige Bilder halt nicht mehr aktuell.
Ich versuche mal zu dokumentieren.
Erstellt wurde ein ca Zertifikat
Dann unter certificates ein Serverzertifikat und ein User.
Im VPN Menü wurde der Server eingestellt.
Im Detail
Es gibt die Firewall Regeln
Dann wurden die Datein wie im Tut beschrieben auf den Client gebracht und die Pfade entsprechend angepasst in der config.
Beim verbinden, der Versuch hat über mein Handy als Hotspot stattgefunden, gab es keine Verbindung.
Die Pfsense sagt dazu
Da ist doch die TLS Geschichte anscheinend noch nicht paarig
Viel Text und Bilder. Sorry
Da muss ich sagen war es über den IPCop sehr viel einfacher gestrickt.
Da lief es über eine p12 Datei und die benötigte configdatei mit den DDNS Angaben, Port und Dateinamen der p12 waren da schon hinterlegt.
Diese 2 Datein seiner Zeit in den config Ordner geschoben und ab ging die wilde fahrt.
Aber es soll ja nun die PFSense werden und aufgeben ist eigentlich nicht das Ziel. Dümmer wird man ja auch nicht.
Vorab gesagt ich habe etwas rum getestet und TLS am Server deaktiviert.
In der Clientconfig wurde es auskommentiert und danach hat er sich verbunden.
Ich bekam die 10.20.40.2 zugewiesen. Bei Eingabe von 192.168.1.39 (PFSense aktuell selbst) gab es ein Timeout.
Das hätte doch die Regel dann machen müssen oder wäre die PFSense selbst nur unter 10.20.40.1 erreichbar?
Bzw hätte die Regel bei OpenVPN jeweils in die Subnetze als Destination zeigen müssen?
Aufgefallen ist mir auch, dass man unter Interface -> assign den VPN Server hinzufügen kann.
Muss man dies? Sorry vielleicht eine doofe Frage, aber im Tut steht es nicht.
Was habe ich getan ich sonst so eingestellt.
Ich habe mit Deinem Tutorial OpenVPN installieren gearbeitet soweit es ging aufgrund der neuen PFSense, da sind einige Bilder halt nicht mehr aktuell.
Ich versuche mal zu dokumentieren.
Erstellt wurde ein ca Zertifikat
Dann unter certificates ein Serverzertifikat und ein User.
Im VPN Menü wurde der Server eingestellt.
Im Detail
Es gibt die Firewall Regeln
Dann wurden die Datein wie im Tut beschrieben auf den Client gebracht und die Pfade entsprechend angepasst in der config.
Beim verbinden, der Versuch hat über mein Handy als Hotspot stattgefunden, gab es keine Verbindung.
Die Pfsense sagt dazu
Da ist doch die TLS Geschichte anscheinend noch nicht paarig
Viel Text und Bilder. Sorry
Da muss ich sagen war es über den IPCop sehr viel einfacher gestrickt.
Na ja das ist wie immer Geschmackssache...Ich habe hier in 5 Minuten die Schlüssel mit easy-rsa erstellt, dann ber cut and paste die in die pfSense übertragen...fertisch.
War in 7 Minuten gegessen das ganze. Ist das nun kompliziert ??
Das was du im eays-rsa machst klickst du ja identisch auch im GUI. Ist ja seit langem bekannt das Klicki Bunti nicht immer schneller sein muss als das CLI...im Gegenteil
Es gibt ja auch noch IPsec das geht noch schneller. Aber du hast recht mit p12 ist das schon eleganter...
Was wichtig ist das du im virtuellen OpenVPN Interface die IPs zulässt. Per default ist das Interface im Blocking und lässt nix durch den Tunnel.
hier musst du die internen OVPN IP Netze und das Zielnetz erlauben. S
Diese Regeln stehen aber ganz klar im Tutorial....wenn auch in einem anderen GUI.
Aber danke für den Hinweis. ich werde das OVPN Tutorial mal übers Wochenende mit einem aktuellen GUI versehen...
Was sagt das Log im Client uns Server ??
Da man nicht täglich die Zertifikate ändert, stellt das auch kein Problem da.
Vorteil hier man kann die Schlüssel importieren.
Ist beim Cop ggf über Umwege möglich
Die Logs vom Server und Client sind angehängt.
Die Sache mit den IPs im virtuellen Netz zulassen verstehe ich als Firewall Rule.
Erledigt da nicht vorerst die Any Any Regel?
Oder geht es um Interface assign?
Zu dem Gateway Thema.
Die Groups müssten doch so passen oder nicht?
Vorteil hier man kann die Schlüssel importieren.
Ist beim Cop ggf über Umwege möglich
Die Logs vom Server und Client sind angehängt.
Die Sache mit den IPs im virtuellen Netz zulassen verstehe ich als Firewall Rule.
Erledigt da nicht vorerst die Any Any Regel?
Oder geht es um Interface assign?
Zu dem Gateway Thema.
Die Groups müssten doch so passen oder nicht?
Sodele,
gestern Abend habe ich die PFSense in die Produktivumgebung gehoben.
Beide Cops sind abgeschaltet und die PFSense übernimmt alles.
Nun kann man besser die Feinabstimmungen machen.
DHCPs laufen gut.
Zuerst hatte ich noch Probleme aus dem Vlan, wo ich mit einer Regel den GUI Zugriff auf die PFSense selbst verbieten wollte.
Die Regel war als Source Lan1_VLAN10 Port Any zu Destination Self Any
Klar, da ging dann kein Internet mehr, das habe ich dann aber selbst gelöst indem es nur Port 80 und 443 wurde.
Das läuft nun.
Und ich wunderte mich, dass ich nicht an die vorgelagerten Fritzboxen kam.
Halt nur an die erste, worüber auch der Standardgateway läuft.
Auch dies lies sich mit einer Regel erledigen und läuft. Ich versuche ja wie gesgat zu verstehen und umzusetzen.
Was noch nicht so will wie ich ist das OpenVPN und das Failover.
Das Failover werde ich mal testen indem ich ein Kabel ziehe.
Beim OpenVPN hast Du einige Bilder geupdatet wie Du gesgat hast, habe ich gesehen.
Die unteren sind auch neuer im neuen Menü, aber sei es drum.
Ich habe da noch so meine Probleme mit den Zertifikaten.
Ich stelle mich da noch etwas unbeholfen an.
Wenn ich den Teil mit den TLS aktiviere woraus sich der ta.key ergibt, läuft gar nichts mehr.
Was mich nur wundert es gibt die p12 Dateien in der GUI zum downloaden.
Was ist denn jetzt der Nachteil, wenn man die p12 nur nimmt?
So funktionieren tut das nicht, da muss dann sicher was umgestellt werden.
gestern Abend habe ich die PFSense in die Produktivumgebung gehoben.
Beide Cops sind abgeschaltet und die PFSense übernimmt alles.
Nun kann man besser die Feinabstimmungen machen.
DHCPs laufen gut.
Zuerst hatte ich noch Probleme aus dem Vlan, wo ich mit einer Regel den GUI Zugriff auf die PFSense selbst verbieten wollte.
Die Regel war als Source Lan1_VLAN10 Port Any zu Destination Self Any
Klar, da ging dann kein Internet mehr, das habe ich dann aber selbst gelöst indem es nur Port 80 und 443 wurde.
Das läuft nun.
Und ich wunderte mich, dass ich nicht an die vorgelagerten Fritzboxen kam.
Halt nur an die erste, worüber auch der Standardgateway läuft.
Auch dies lies sich mit einer Regel erledigen und läuft. Ich versuche ja wie gesgat zu verstehen und umzusetzen.
Was noch nicht so will wie ich ist das OpenVPN und das Failover.
Das Failover werde ich mal testen indem ich ein Kabel ziehe.
Beim OpenVPN hast Du einige Bilder geupdatet wie Du gesgat hast, habe ich gesehen.
Die unteren sind auch neuer im neuen Menü, aber sei es drum.
Ich habe da noch so meine Probleme mit den Zertifikaten.
Ich stelle mich da noch etwas unbeholfen an.
Wenn ich den Teil mit den TLS aktiviere woraus sich der ta.key ergibt, läuft gar nichts mehr.
Was mich nur wundert es gibt die p12 Dateien in der GUI zum downloaden.
Was ist denn jetzt der Nachteil, wenn man die p12 nur nimmt?
So funktionieren tut das nicht, da muss dann sicher was umgestellt werden.
wo ich mit einer Regel den GUI Zugriff auf die PFSense selbst verbieten wollte.
Du kannst da ganz einfach die Antilockout Rule deaktivieren und den Zugriff dann nur über die Firewall Rules regeln.Ich habe da noch so meine Probleme mit den Zertifikaten.
Warum ??Eigentlich ganz einfach. Man macht exakt das was man mit easy-rsa auch macht nur eben mit Klicki Bunti im GUI.
Nutze den Wizzard im OVPN Menü. Das ist wenn man unsicher ist die wasserdichteste Methode.
Wenn ich den Teil mit den TLS aktiviere woraus sich der ta.key ergibt, läuft gar nichts mehr.
Klar, denn das musst du dann auch im Client bzw. der Client Konfig aktivieren ! Sonst natürlich nada mit VPN.Was ist denn jetzt der Nachteil, wenn man die p12 nur nimmt?
Gar keiner...ist nur ein anderes Format und einfacher zu handhaben.So funktionieren tut das nicht, da muss dann sicher was umgestellt werden.
Stimmt.Aber wenn der p12 Import geht warum nimmst du nicht alle deine Zertifikate vom IP Cop importierst die in die pfSense (Cert manager) und arbeitest genau so weiter wie mit dem Cops gewohnt ?!
Das wäre doch am allereinfachsten, oder ?
Hmmm, importieren und 1:1 so weiter laufen lassen klingt interessant.
Allerdings versuche ich schon das so hinzubekommen.
Ich muss ja bei einem neuen User auch bescheid wissen.
Ich habe mich eigentlich an Dein Tut gehalten, aber anscheinend mache ich da was falsch oder verstehe es nicht.
Das mit der Clientconfig ist für mich auch recht schwer zu verstehen.
Das war sie ja beim EeePC.
Habe ich das richtig umgesetzt?
Bezüglich der Firewall OpenVPN Rule müsste es doch auch erstmal so gehen wie sie definiert ist oder?
Allerdings versuche ich schon das so hinzubekommen.
Ich muss ja bei einem neuen User auch bescheid wissen.
Ich habe mich eigentlich an Dein Tut gehalten, aber anscheinend mache ich da was falsch oder verstehe es nicht.
Das mit der Clientconfig ist für mich auch recht schwer zu verstehen.
Das war sie ja beim EeePC.
Habe ich das richtig umgesetzt?
Bezüglich der Firewall OpenVPN Rule müsste es doch auch erstmal so gehen wie sie definiert ist oder?
Allerdings versuche ich schon das so hinzubekommen.
Und...wo ist das Problem. Die Zertifikate sind simple ASCII Dateien auf allen OS, die kannst du schlicht und einfach mit cut and paste im Cert Manager übertragen. Dafür ist der da... Das mit der Clientconfig ist für mich auch recht schwer zu verstehen.
Was genau ist da schwer zu verstehen ??Das war sie ja beim EeePC.
Bitte keine Bilderlinks...was soll der Unsinn ? Kamerasymbol klicken und dann "+" wo du das Bild im Text haben willst. Was ist daran so schwer ??Bezüglich der Firewall OpenVPN Rule
Schon wieder grrrrr Kamerasymbol !!!Ja das geht so, das ist ja die berühmte Scheunentorregel
Entschuldige das mit den Bildern.
Ich versuche jetzt noch mal beim Urknall anzufangen.
Ich bin da echt zu blöde für.
Jetzt erstmal nur Serverseitig alles klar stellen.
Wenn hier schon Fehler sind, brauche ich gar nicht zum Client schauen.
Die Firewallregeln haben ja gepasst.
Es kommt auch was an, aber alles mit Fehlern laut log.
Also erstellt wurde ein CA unter System -> Cert Manager
Dann wurde das Server Certificate und ein Usercertificate erstellt. (Private Daten geschwärzt)
Als nächstes unter VPN -> OpenVPN -> Servers der Server erstellt.
Und bei diesem die Einstellungen im Detail.
Ist jetzt hierbei schon was vergessen oder ein Fehler?
Mehr muss doch Serverseitig nicht passieren ausser die Rules die ja schon passen oder verstehe ich das so falsch?
Ich versuche jetzt noch mal beim Urknall anzufangen.
Ich bin da echt zu blöde für.
Jetzt erstmal nur Serverseitig alles klar stellen.
Wenn hier schon Fehler sind, brauche ich gar nicht zum Client schauen.
Die Firewallregeln haben ja gepasst.
Es kommt auch was an, aber alles mit Fehlern laut log.
Also erstellt wurde ein CA unter System -> Cert Manager
Dann wurde das Server Certificate und ein Usercertificate erstellt. (Private Daten geschwärzt)
Als nächstes unter VPN -> OpenVPN -> Servers der Server erstellt.
Und bei diesem die Einstellungen im Detail.
Ist jetzt hierbei schon was vergessen oder ein Fehler?
Mehr muss doch Serverseitig nicht passieren ausser die Rules die ja schon passen oder verstehe ich das so falsch?
Also erstellt wurde ein CA unter System -> Cert Manager
Richtig !Dann wurde das Server Certificate und ein Usercertificate erstellt.
Richtig !Als nächstes unter VPN -> OpenVPN -> Servers der Server erstellt.
Richtig ! Wenn du andere Ports als 1194 benutzt beachte das die nicht mit registrierten IANA Ports kollidieren !Im Zweifel immer die freien ephemeral ports nehmen zwischen 49152 und 65535
https://en.wikipedia.org/wiki/Ephemeral_port
Und bei diesem die Einstellungen im Detail.
Alles richtig...ist mehr oder minder Default.Mehr muss doch Serverseitig nicht passieren ausser die Rules die ja schon passen oder verstehe ich das so falsch?
Nein, alles richtig verstanden und passt so !
Gut, dann mache ich beim Server mal einen Haken und denke der Fehler ist beim Client zu suchen.
Extra ausführlich, ich möchte ja den Fehler finden.
Getestet wird mit dem EeePC mittels 32 Bit Windows 7
OpenVPN ist aktualisiert. (openvpn-install-2.3.11-I601-i686.exe)
In dem Odner C:/Program Files/OpenVPN/easy-rsa/clientkeys liegen folgende Dateien.
Clientzertifikat: BaluEeePC.crt
Clientkey: BaluEeePC.key
CA: OpenVPN.crt
Der TLS Keys welcher bei Dir ta.key heisst: tls.key (Der komplette Text bzw. Key wurde dort hinein kopiert)
Die Clientconfig sieht folgendermassen aus:
client
dev tun
proto udp
remote ddns Adresse Port
resolv-retry infinite
nobind
persist-key
persist-tun
ca "C:/Program Files/OpenVPN/easy-rsa/clientkeys/OpenVPN.crt"
cert "C:/Program Files/OpenVPN/easy-rsa/clientkeys/BaluEeePC.crt"
key "C:/Program Files/OpenVPN/easy-rsa/clientkeys/BaluEeePC.key"
;ns-cert-type server
tls-auth "C:/Program Files/OpenVPN/easy-rsa/clientkeys/tls.key" 1
cipher AES-256-CBC
comp-lzo
verb 3
ddns funktioniert, ist aber hier unkenntlich.
Dazu schreibt der client im Log
Wed Aug 10 22:41:19 2016 OpenVPN 2.3.11 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on May 10 2016
Wed Aug 10 22:41:19 2016 Windows version 6.1 (Windows 7) 32bit
Wed Aug 10 22:41:19 2016 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.09
Enter Management Password:
Wed Aug 10 22:41:19 2016 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Aug 10 22:41:19 2016 Need hold release from management interface, waiting...
Wed Aug 10 22:41:20 2016 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Aug 10 22:41:20 2016 MANAGEMENT: CMD 'state on'
Wed Aug 10 22:41:20 2016 MANAGEMENT: CMD 'log all on'
Wed Aug 10 22:41:20 2016 MANAGEMENT: CMD 'hold off'
Wed Aug 10 22:41:20 2016 MANAGEMENT: CMD 'hold release'
Wed Aug 10 22:41:20 2016 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Aug 10 22:41:21 2016 Control Channel Authentication: using 'C:/Program Files/OpenVPN/easy-rsa/clientkeys/tls.key' as a OpenVPN static key file
Wed Aug 10 22:41:21 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Aug 10 22:41:21 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Aug 10 22:41:21 2016 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Aug 10 22:41:21 2016 MANAGEMENT: >STATE:1470861681,RESOLVE,,,
Wed Aug 10 22:41:22 2016 UDPv4 link local: [undef]
Wed Aug 10 22:41:22 2016 UDPv4 link remote: [AF_INET]Hier war die IP nebst Port
Wed Aug 10 22:41:22 2016 MANAGEMENT: >STATE:1470861682,WAIT,,,
Wed Aug 10 22:41:22 2016 MANAGEMENT: >STATE:1470861682,AUTH,,,
Wed Aug 10 22:41:22 2016 TLS: Initial packet from [AF_INET]Hier war die IP nebst Port, sid=249b32ee 21f1d8db
Wed Aug 10 22:41:22 2016 VERIFY OK: depth=1, C=DE, ST=Germany, L=V..., O=fu..., emailAddress=admin@fu.....de, CN=OpenVPN
Wed Aug 10 22:41:22 2016 VERIFY OK: depth=0, C=DE, ST=Germany, L=V... O=fu..., emailAddress=admin@fu..., CN=fu...
Der Server schreibt beim Verbindungsversuch 2 Zeilen ins Log
Kannst Du da etwas erkennen?
Beim Android mit der OpenVPN App von Arne Schwabe bisher muss ich wenn das eine läuft mal schauen wie das geht.
Aber eines nach dem anderen.
Extra ausführlich, ich möchte ja den Fehler finden.
Getestet wird mit dem EeePC mittels 32 Bit Windows 7
OpenVPN ist aktualisiert. (openvpn-install-2.3.11-I601-i686.exe)
In dem Odner C:/Program Files/OpenVPN/easy-rsa/clientkeys liegen folgende Dateien.
Clientzertifikat: BaluEeePC.crt
Clientkey: BaluEeePC.key
CA: OpenVPN.crt
Der TLS Keys welcher bei Dir ta.key heisst: tls.key (Der komplette Text bzw. Key wurde dort hinein kopiert)
Die Clientconfig sieht folgendermassen aus:
client
dev tun
proto udp
remote ddns Adresse Port
resolv-retry infinite
nobind
persist-key
persist-tun
ca "C:/Program Files/OpenVPN/easy-rsa/clientkeys/OpenVPN.crt"
cert "C:/Program Files/OpenVPN/easy-rsa/clientkeys/BaluEeePC.crt"
key "C:/Program Files/OpenVPN/easy-rsa/clientkeys/BaluEeePC.key"
;ns-cert-type server
tls-auth "C:/Program Files/OpenVPN/easy-rsa/clientkeys/tls.key" 1
cipher AES-256-CBC
comp-lzo
verb 3
ddns funktioniert, ist aber hier unkenntlich.
Dazu schreibt der client im Log
Wed Aug 10 22:41:19 2016 OpenVPN 2.3.11 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on May 10 2016
Wed Aug 10 22:41:19 2016 Windows version 6.1 (Windows 7) 32bit
Wed Aug 10 22:41:19 2016 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.09
Enter Management Password:
Wed Aug 10 22:41:19 2016 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Aug 10 22:41:19 2016 Need hold release from management interface, waiting...
Wed Aug 10 22:41:20 2016 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Aug 10 22:41:20 2016 MANAGEMENT: CMD 'state on'
Wed Aug 10 22:41:20 2016 MANAGEMENT: CMD 'log all on'
Wed Aug 10 22:41:20 2016 MANAGEMENT: CMD 'hold off'
Wed Aug 10 22:41:20 2016 MANAGEMENT: CMD 'hold release'
Wed Aug 10 22:41:20 2016 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Wed Aug 10 22:41:21 2016 Control Channel Authentication: using 'C:/Program Files/OpenVPN/easy-rsa/clientkeys/tls.key' as a OpenVPN static key file
Wed Aug 10 22:41:21 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Aug 10 22:41:21 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Aug 10 22:41:21 2016 Socket Buffers: R=[8192->8192] S=[8192->8192]
Wed Aug 10 22:41:21 2016 MANAGEMENT: >STATE:1470861681,RESOLVE,,,
Wed Aug 10 22:41:22 2016 UDPv4 link local: [undef]
Wed Aug 10 22:41:22 2016 UDPv4 link remote: [AF_INET]Hier war die IP nebst Port
Wed Aug 10 22:41:22 2016 MANAGEMENT: >STATE:1470861682,WAIT,,,
Wed Aug 10 22:41:22 2016 MANAGEMENT: >STATE:1470861682,AUTH,,,
Wed Aug 10 22:41:22 2016 TLS: Initial packet from [AF_INET]Hier war die IP nebst Port, sid=249b32ee 21f1d8db
Wed Aug 10 22:41:22 2016 VERIFY OK: depth=1, C=DE, ST=Germany, L=V..., O=fu..., emailAddress=admin@fu.....de, CN=OpenVPN
Wed Aug 10 22:41:22 2016 VERIFY OK: depth=0, C=DE, ST=Germany, L=V... O=fu..., emailAddress=admin@fu..., CN=fu...
Der Server schreibt beim Verbindungsversuch 2 Zeilen ins Log
Kannst Du da etwas erkennen?
Beim Android mit der OpenVPN App von Arne Schwabe bisher muss ich wenn das eine läuft mal schauen wie das geht.
Aber eines nach dem anderen.
Ns cert type server entkommentiren...
Danke erstmal,
Bin heute unterwegs und werde das morgen testen.
Ich meine aber das schon getan zu haben ohne Erfolg.
Als ich mal das mit dem ta.key auskommentiert und an Server deaktiviert hatte, ging es.
Da muss doch alles von kopiert werden samt der Einleitung die mit im Feld steht oder?
Bin heute unterwegs und werde das morgen testen.
Ich meine aber das schon getan zu haben ohne Erfolg.
Als ich mal das mit dem ta.key auskommentiert und an Server deaktiviert hatte, ging es.
Da muss doch alles von kopiert werden samt der Einleitung die mit im Feld steht oder?
Ja, entweder beidseitig aktivieren oder deaktivieren.
Sodele ich habe mich dann mal wieder an den EeePC gemacht.
; rausgenommen und das Log auf der PFSense sagte mir Username und Auth fehlt.
Als ich beim Server nachgesehen habe, sah ich es stand auf Remote Access (SSL/TLS + User Auth)
Als ich es auf SSL/TLS umgestellt habe, bin ich durchgekommen.
Verbindung besteht also und es ist grün am EeePC, allerdings komme ich nicht an lokale Adresse aus dem Lan1 ran.
Es besteht die Scheunentorregel * * im OpenVPN, das wundert mich.
Auf dem Android habe ich die Verbindung auch hinbekommen, nur komme ich dort ebenso wenig ins lokale Netz und dafür benötige ich es.
Ich benötige es weniger um Länderspezifische Sperren oder unterwegs geblockte Webseiten zu umgehen.
; rausgenommen und das Log auf der PFSense sagte mir Username und Auth fehlt.
Als ich beim Server nachgesehen habe, sah ich es stand auf Remote Access (SSL/TLS + User Auth)
Als ich es auf SSL/TLS umgestellt habe, bin ich durchgekommen.
Verbindung besteht also und es ist grün am EeePC, allerdings komme ich nicht an lokale Adresse aus dem Lan1 ran.
Es besteht die Scheunentorregel * * im OpenVPN, das wundert mich.
Auf dem Android habe ich die Verbindung auch hinbekommen, nur komme ich dort ebenso wenig ins lokale Netz und dafür benötige ich es.
Ich benötige es weniger um Länderspezifische Sperren oder unterwegs geblockte Webseiten zu umgehen.
Windows auf dem EEE PC ?
Wenn ja ist das die lokale Firewall die das VPN durch das fehlende Gateway Discovery als öffentlich deklariert.
Du musst das Netzwerk als privat dekalrieren in der FW, dann klappts auch mit der Verbindung. route print am Client ziegt die Erreichbarkeit des remoten Netzes via Tunnel IP ?
Wenn ja ist das die lokale Firewall die das VPN durch das fehlende Gateway Discovery als öffentlich deklariert.
Du musst das Netzwerk als privat dekalrieren in der FW, dann klappts auch mit der Verbindung. route print am Client ziegt die Erreichbarkeit des remoten Netzes via Tunnel IP ?
Es geht genauso wenig am Android Handy
Was sagt das Firewall Log ?
Vorher mal löschen und dann einen Ping machen. Wird da irgendwas geloggt ?
Was sagt die Routing Tabelle auf dem EEE ?
Vorher mal löschen und dann einen Ping machen. Wird da irgendwas geloggt ?
Was sagt die Routing Tabelle auf dem EEE ?
Ist Symantec vor.
Alles deaktiviert bzw. auch das Scheunentor 10.20.30.0
Geht nichts.
Auch kein Ping.
És ging ja früher.
Komischerweise will ja Android auch nicht.
Alles deaktiviert bzw. auch das Scheunentor 10.20.30.0
Geht nichts.
Auch kein Ping.
És ging ja früher.
Komischerweise will ja Android auch nicht.
Oha...Symantec, Kaspersky und Konsorten...die kann man nie deaktivieren.... Solchen endlosen leidensdramen hatten wir schon öfter hier.
Am besten was zum Testen nehmen was das NICHT hat. Boote ein Live Linux oder sowas um ganz sicher zu gehen.
Am besten was zum Testen nehmen was das NICHT hat. Boote ein Live Linux oder sowas um ganz sicher zu gehen.
Android ohne Virenscanner geht wie gesagt auch nicht und früher zu IPCop Zeiten kam mit dem Port und 10er Subnet auch durch.
Edit: So ich hatte einen Erfolg.
Am Handy mäkelte er wegen LZO rum. Als ich den haken entfernt hatte, ging es sofort und ich kam auf die lokalen IPs.
Da ich bei meiner Freundin bin und auch das Zertifikat dafür mit dabei hatte, kommentierte ich die Zeile aus und siehe da auch das ging sofort, trotz Symantec.
Es funktionierte alles, ich kam auf die pfSense usw.
Ich hatte vorhin nur zusätzlich beim Server push "route 192.168.1.0 255.255.255.0" mit hinzugefügt.
Das scheint es wohl zusätzlich zu benötigen.
ich habe es über VPN entfernt. Speichern konnte ich noch drücken, aber dann wars das
Morgen vor Ort noch wieder rein machen und gut.
Ich werde auch die Zertifikate neu erstellen.
Ich habe bei Common-Name überall das selbe rein geschrieben, statt dem Namen den ich oben vergeben habe.
Dementsprechend übersichtlich sieht das jetzt aus.
Das ist aber das kleinere übel denke ich mal.
Irgendwo muss dann ja LZO in der config auch ausgehakt sein.
Edit: So ich hatte einen Erfolg.
Am Handy mäkelte er wegen LZO rum. Als ich den haken entfernt hatte, ging es sofort und ich kam auf die lokalen IPs.
Da ich bei meiner Freundin bin und auch das Zertifikat dafür mit dabei hatte, kommentierte ich die Zeile aus und siehe da auch das ging sofort, trotz Symantec.
Es funktionierte alles, ich kam auf die pfSense usw.
Ich hatte vorhin nur zusätzlich beim Server push "route 192.168.1.0 255.255.255.0" mit hinzugefügt.
Das scheint es wohl zusätzlich zu benötigen.
ich habe es über VPN entfernt. Speichern konnte ich noch drücken, aber dann wars das
Morgen vor Ort noch wieder rein machen und gut.
Ich werde auch die Zertifikate neu erstellen.
Ich habe bei Common-Name überall das selbe rein geschrieben, statt dem Namen den ich oben vergeben habe.
Dementsprechend übersichtlich sieht das jetzt aus.
Das ist aber das kleinere übel denke ich mal.
Irgendwo muss dann ja LZO in der config auch ausgehakt sein.
Ja die Kleinigkeiten...
LZO solltest du aber einschalten, denn das bringt noch etwas an Performance. Man kann es so am Server einstelen das es negotiatable ist. Sprich der Server schlägt es vor zu machen und wenn der Client das kann ist es aktiv. Wenn nicht dann eben nicht. Das wäre die sinnigste Einstellung.
LZO solltest du aber einschalten, denn das bringt noch etwas an Performance. Man kann es so am Server einstelen das es negotiatable ist. Sprich der Server schlägt es vor zu machen und wenn der Client das kann ist es aktiv. Wenn nicht dann eben nicht. Das wäre die sinnigste Einstellung.
Sodele
Ich habe das VPN jetzt am laufen.
Ich habe die Kompression jetzt auf Enabled with Adaptive Compression gestellt und somit funktioniert es mit der Kompression.
Allerdings muss ich noch mal nachhaken, da man an dem Piunkt IPv4 Local network(s) das lokale Netz anwählt und bei push Route noch mal.
Muss man jedes Subnet welches erreichbar sein soll oben und unten eintragen?
Des weiteren habe ich unter Windows gerade mal die Geschwindigkeit getestet mittels eines Dateitransfers.
Er hat sage und schreibe 110 Kilobyte/s und das bei einer 10Mbit UP Leitung.
Da erwarte ich schon so mein knappes Megabyte
Beim IPCop hatte ich damals die Kompression herausgenommen und den Tunnel auf TCP umgestellt, danach war es schnell.
Ich habe das VPN jetzt am laufen.
Ich habe die Kompression jetzt auf Enabled with Adaptive Compression gestellt und somit funktioniert es mit der Kompression.
Allerdings muss ich noch mal nachhaken, da man an dem Piunkt IPv4 Local network(s) das lokale Netz anwählt und bei push Route noch mal.
Muss man jedes Subnet welches erreichbar sein soll oben und unten eintragen?
Des weiteren habe ich unter Windows gerade mal die Geschwindigkeit getestet mittels eines Dateitransfers.
Er hat sage und schreibe 110 Kilobyte/s und das bei einer 10Mbit UP Leitung.
Da erwarte ich schon so mein knappes Megabyte
Beim IPCop hatte ich damals die Kompression herausgenommen und den Tunnel auf TCP umgestellt, danach war es schnell.
Muss man jedes Subnet welches erreichbar sein soll oben und unten eintragen?
Ja, denn damit werden diese Netze per push an in die Routing Tabelle der Clients gesendet. Die "wissen" dann das diese Netze dann auch in den Tunnel geroutet werden müssen. route print oder ip route show.Die langsame Datenrate ist wie immer ein MTU Problem. Setze die korrekte MTU oder MSS und dann klappt das auch.
Den Tunnel auf TCP umstellen ist tödlich. Ist auch klar...denk mal nach der Encapsulation Overhead ist erheblich größer, das resultiert in noch mehr CPU Last und noch größeren Overhead. Das ist nie und nimmer eine Verbesserung.
OVPN selber rät dringenst von einer TCP Encapsulation ab auf seinen Dokumentationsseiten.
Trage ich das nur bei den Clients ein oder auch beim Server?
Edit: Ich habe es jetzt mal beidseitig eingetragen und mit verschiedenen Werten probiert mit mässigem Erfolg.
Was sollte man da denn als Richtwert setzen?
Testen tue ich mit meinem Android Handy über LTE
Edit: Ich habe es jetzt mal beidseitig eingetragen und mit verschiedenen Werten probiert mit mässigem Erfolg.
Was sollte man da denn als Richtwert setzen?
Testen tue ich mit meinem Android Handy über LTE
Nur beim Server !
Der MSS Wert sollte 1340 sein. MTU 1452. Du kannst das aber auch für deinen Anschluss individuell ermitteln.
http://www.tippscout.de/windows-7-mtu-optimieren-download-abgebrochen_t ...
Der MSS Wert sollte 1340 sein. MTU 1452. Du kannst das aber auch für deinen Anschluss individuell ermitteln.
http://www.tippscout.de/windows-7-mtu-optimieren-download-abgebrochen_t ...
Und das trage ich in die Custom Options ein, oder?
tun-mtu 1452
und wo mss???
tun-mtu 1452
und wo mss???
https://www.sonassi.com/help/magestack/setting-correct-mtu-for-openvpn
http://www.unitymediaforum.de/viewtopic.php?f=53&t=23755
Befrag mal Dr. Google nach Openvpn MTU und MSS
http://www.unitymediaforum.de/viewtopic.php?f=53&t=23755
Befrag mal Dr. Google nach Openvpn MTU und MSS
Also in den Custom Options
mssfix 1340;
tun-mtu 1452;
Oder in dem Fall link-mtu
Da sind die Werte dann ja unterschiedlich.
Mit ; anschliessen habe ich denke ich richtig gelesen
C:\Users\Balu\Desktop>mtupath.exe www.google.de
MTU path scan to www.google.de (216.58.210.3), ttl
#1 MSS IN RANGE 1 <== 1471 ==> 1472
#2 MSS EXCEEDED 1473 <== 14911 ==> 16384
mssfix 1340;
tun-mtu 1452;
Oder in dem Fall link-mtu
Da sind die Werte dann ja unterschiedlich.
Mit ; anschliessen habe ich denke ich richtig gelesen
C:\Users\Balu\Desktop>mtupath.exe www.google.de
MTU path scan to www.google.de (216.58.210.3), ttl
- 16 processing - best MSS 1472 (estimated MTU 150
- 01 nearest minimum MTU on local interface
#1 MSS IN RANGE 1 <== 1471 ==> 1472
#2 MSS EXCEEDED 1473 <== 14911 ==> 16384
Darf ich den Experten dabei noch mal um Hilfe bitten?
Ich bin Heavy on the Woodway
Es wurden mehrere Konstellationen getestet, aber es wurde eher langsamer als schneller.
Entweder trage ich die falschen Werte ein (auch 1492 habe ich versucht) oder ich trage es gänzlich falsch ein.
Ich habe mir auch noch Gedanken über den einen Client gemacht, der den anderen Gateway nutzt.
Aktuell sage ich ja die IP soll den anderen gateway nutzen laut Firewall Regel.
Dazu habe ich bei WAN2 eine normale NAT Portweiterleitung.
Ich nehme mal Symbolports. Ich komme über 40000 rein und auf dem Client lasse ich auf 30000 triggern.
Das funktioniert.
Ich könnte doch aber auch nur den Dienst selbst über die Telekom Leitung lassen oder?
Die Weiterleitung würde bestehen bleiben, daran ändert sich nichts, lediglich die Regel der Firewall ist nicht mehr auf IP selbst gesetzt
sondern um bei dem Beispiel zu bleiben Port 30000 nutzt die Telekomleitung.
Es ergäben sich 2 Vorteile.
Egal welcher Rechner (egal welche IP) den Dienst erledigt, er würde immer über die Telekom antworten (die NAT Weiterleitung passt dann nicht mehr) und der Rechner selber könnte geupdatet werden und würde dafür dann die schnellere Leitung nutzen und nicht die langsamere, da er über IP umgeroutet wird.
Ich bin Heavy on the Woodway
Es wurden mehrere Konstellationen getestet, aber es wurde eher langsamer als schneller.
Entweder trage ich die falschen Werte ein (auch 1492 habe ich versucht) oder ich trage es gänzlich falsch ein.
Ich habe mir auch noch Gedanken über den einen Client gemacht, der den anderen Gateway nutzt.
Aktuell sage ich ja die IP soll den anderen gateway nutzen laut Firewall Regel.
Dazu habe ich bei WAN2 eine normale NAT Portweiterleitung.
Ich nehme mal Symbolports. Ich komme über 40000 rein und auf dem Client lasse ich auf 30000 triggern.
Das funktioniert.
Ich könnte doch aber auch nur den Dienst selbst über die Telekom Leitung lassen oder?
Die Weiterleitung würde bestehen bleiben, daran ändert sich nichts, lediglich die Regel der Firewall ist nicht mehr auf IP selbst gesetzt
sondern um bei dem Beispiel zu bleiben Port 30000 nutzt die Telekomleitung.
Es ergäben sich 2 Vorteile.
Egal welcher Rechner (egal welche IP) den Dienst erledigt, er würde immer über die Telekom antworten (die NAT Weiterleitung passt dann nicht mehr) und der Rechner selber könnte geupdatet werden und würde dafür dann die schnellere Leitung nutzen und nicht die langsamere, da er über IP umgeroutet wird.
Yepp, das kann man so machen und du hast Recht es ist sinnvoller, da dann die Port Translation entfällt was das ganze einfacher handhabbar macht.
Das funktioniert auch bereits.
Nur mit der MTU Geschichte weiss ich nicht weiter.
Es wird eher langsamer als schneller...
Magst Du mir da vielleicht sagen wie ich das einzutragen habe?
Nur mit der MTU Geschichte weiss ich nicht weiter.
Es wird eher langsamer als schneller...
Magst Du mir da vielleicht sagen wie ich das einzutragen habe?
Der WAN Port welcher zum Provider geht der muss das max MTU setting haben.
Der lokale LAN Port das MSS Setting.
Generell ist der Klassiker 1492 für die MTU und 1452 fürs MSS.
Beispiel kannst du mal an einer Cisco Konfig sehen die das anschaulich zeigt in der Konfig:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Wie gesagt das gilt nur für xDSL mit einer PPPoE Encapsulation und nicht für Glasfaser (GPON) oder TV Kabel Netze.
Zu den Grundlagen des warum kannst du hier einiges lesen:
http://www.cisco.com/c/en/us/support/docs/long-reach-ethernet-lre-digit ...
Der lokale LAN Port das MSS Setting.
Generell ist der Klassiker 1492 für die MTU und 1452 fürs MSS.
Beispiel kannst du mal an einer Cisco Konfig sehen die das anschaulich zeigt in der Konfig:
Cisco 880, 890 und ISR Router Konfiguration mit xDSL, Kabel oder FTTH Anschluss plus VPN und IP-TV
Wie gesagt das gilt nur für xDSL mit einer PPPoE Encapsulation und nicht für Glasfaser (GPON) oder TV Kabel Netze.
Zu den Grundlagen des warum kannst du hier einiges lesen:
http://www.cisco.com/c/en/us/support/docs/long-reach-ethernet-lre-digit ...
Ah in den Interface Einstellungen...
Und ich war immer dabei das dem VPN mitzugeben.
Mein Provider hat im Dorf einen DSLAM aufgestellt. Die Fritzox synct damit auf DSL Basis.
Es ist doch dann unerheblich ob der Provider sich selbst via Glasfaser oder Richtfunk versorgt oder?
Sollte ich in der vorgelagerten Fritzbox auch etwas einstellen mit der MTU?
AVM gibt an, es ginge automatisch, aber ich weiss nicht wie die Kaskade da rein spielt.
Aufgefallen ist mir jedenfalls, dass ich seinerzeit ohne Router Kaskade immer volle Leistung im Downstream hatte und kaum war ein Router ob Ipcop oder pfSense dahinter, hatte und habe ich nie die 50 Mbit.
Klar es kann auch viele Faktoren der Überlassung haben, aber es ist echt langsamer seit einen Router dahinter und ich wusste nie wo ich überhaupt schauen muss.
So habe ich wenigstens die Richtung und eine Erklärung dafür.
Ich ändere sowie ich zu Hause bin mal unter Interface -> Wan1 den MTU Wert bzw trage generell was ein und bei Lan1 die MSS.
Wenn ich das richtig verstehe, dann muss dies auch bei den Vlans so passieren.
Und ich war immer dabei das dem VPN mitzugeben.
Mein Provider hat im Dorf einen DSLAM aufgestellt. Die Fritzox synct damit auf DSL Basis.
Es ist doch dann unerheblich ob der Provider sich selbst via Glasfaser oder Richtfunk versorgt oder?
Sollte ich in der vorgelagerten Fritzbox auch etwas einstellen mit der MTU?
AVM gibt an, es ginge automatisch, aber ich weiss nicht wie die Kaskade da rein spielt.
Aufgefallen ist mir jedenfalls, dass ich seinerzeit ohne Router Kaskade immer volle Leistung im Downstream hatte und kaum war ein Router ob Ipcop oder pfSense dahinter, hatte und habe ich nie die 50 Mbit.
Klar es kann auch viele Faktoren der Überlassung haben, aber es ist echt langsamer seit einen Router dahinter und ich wusste nie wo ich überhaupt schauen muss.
So habe ich wenigstens die Richtung und eine Erklärung dafür.
Ich ändere sowie ich zu Hause bin mal unter Interface -> Wan1 den MTU Wert bzw trage generell was ein und bei Lan1 die MSS.
Wenn ich das richtig verstehe, dann muss dies auch bei den Vlans so passieren.
Ja, das ist egal ob der Provider sich mit, Glas oder auch einem feuchten Bindfaden versorgt..
Die Fritzbox ist per Default auf 1492 eingestellt. Übrigens viele andere DSL Router auch aber nicht alle eben.
Automatisch geht das nicht, das ist Blödsinn. AVM hat das hardgecodet.
Technisch besser als eine Router Kaskade wäre natürlich ein reines xDSL Modem.
Das erspart das doppelte NAT.
Die Fritzbox ist per Default auf 1492 eingestellt. Übrigens viele andere DSL Router auch aber nicht alle eben.
Automatisch geht das nicht, das ist Blödsinn. AVM hat das hardgecodet.
Technisch besser als eine Router Kaskade wäre natürlich ein reines xDSL Modem.
Das erspart das doppelte NAT.
Klar, eine Kaskade ist nicht so gut, hat aber auch Vorteile mit den Logs der Fritzbox.
Aber nun gut..
Stelle ich dann trotzdem 1492 in der Pfsense ein? Default steht die ja auf 1500 wie ich das sehe
Aber nun gut..
Stelle ich dann trotzdem 1492 in der Pfsense ein? Default steht die ja auf 1500 wie ich das sehe
Die pfSense hat doch aber auch ein Syslog ?? Da hast du keinerlei Nachteile !
An der pfSense musst du dann nichts verändern, wenn die FB als Kaskade davor ist.
Allerdings müsste man das mal genau mit dem Wireshark ansehen ob die MSS auch richtig weitergegeben wird ans LAN Interface.
Das Problem kann dann sein wenn die Geräte vor der FB 1500 Byte Frames senden wird die FB gezwungen zu fragmentieren was sie dann in die Knie zwingt und die vermutlich siehst mit dem schlechteren Durchsatz.
MSS und MTU Settings verhindern das so das nie Frames größer 1452 gesendet werden und niemals fragmentiert werden muss.
An der pfSense musst du dann nichts verändern, wenn die FB als Kaskade davor ist.
Allerdings müsste man das mal genau mit dem Wireshark ansehen ob die MSS auch richtig weitergegeben wird ans LAN Interface.
Das Problem kann dann sein wenn die Geräte vor der FB 1500 Byte Frames senden wird die FB gezwungen zu fragmentieren was sie dann in die Knie zwingt und die vermutlich siehst mit dem schlechteren Durchsatz.
MSS und MTU Settings verhindern das so das nie Frames größer 1452 gesendet werden und niemals fragmentiert werden muss.
Bisher schätzte ich allerdings die nächstliche FritzBox Übersicht.
Daraus war dann immer ersichtlich wann das Netz mal wieder ausgefallen ist.
Telefonie könnte auch davor abgezweigt werden. Das ist aber aktuell kein Thema.
Ansonsten wäre ein Vigor130 VDSL Modem durchaus vorhanden oder für T-Offline ein Speedport 201
Das wären reine Modems.
Wie gesagt wo der neue Anbieter noch nicht in die Infrastruktur eingebunden war, habe ich einfach die FritzBox ohne DHCP an das Netzwerk gehängt und dann nur mich mal darauf geschaltet.
Seiner Zeit waren auch weniger Nutzer bei dem Anbieter, von daher weiss ich nicht ob das mit dem Trafficproblem auf die steigenden Benutzerzahlen oder auf fehlerhafte Einstellungen zurückzuführen ist.
Damals hatte ich wenn die Gegenseite mitgespielt hat auch meine Downloads mit 5,5-6 Megabyte/s und da komme ich aktuell nicht hin.
Ich habe Wireshark mal installiert und mal kurz gestartet.
Was da drüber fliesst ist eine wahre Pracht und für mich undurchschaubar.
Es wurde mal www.google.de aufgerufen
Wenn ich in dem WirrWarr die Zeichenkette MSS suche so sehe ich 1430 und 1460
312 21.190794 216.58.211.36 192.168.1.20 TCP 66 443 → 52561 [SYN, ACK] Seq=0 Ack=1 Win=42900 Len=0 MSS=1430 SACK_PERM=1 WS=128
309 21.167517 192.168.1.20 216.58.211.36 TCP 66 52561 → 443 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
Daraus war dann immer ersichtlich wann das Netz mal wieder ausgefallen ist.
Telefonie könnte auch davor abgezweigt werden. Das ist aber aktuell kein Thema.
Ansonsten wäre ein Vigor130 VDSL Modem durchaus vorhanden oder für T-Offline ein Speedport 201
Das wären reine Modems.
Wie gesagt wo der neue Anbieter noch nicht in die Infrastruktur eingebunden war, habe ich einfach die FritzBox ohne DHCP an das Netzwerk gehängt und dann nur mich mal darauf geschaltet.
Seiner Zeit waren auch weniger Nutzer bei dem Anbieter, von daher weiss ich nicht ob das mit dem Trafficproblem auf die steigenden Benutzerzahlen oder auf fehlerhafte Einstellungen zurückzuführen ist.
Damals hatte ich wenn die Gegenseite mitgespielt hat auch meine Downloads mit 5,5-6 Megabyte/s und da komme ich aktuell nicht hin.
Ich habe Wireshark mal installiert und mal kurz gestartet.
Was da drüber fliesst ist eine wahre Pracht und für mich undurchschaubar.
Es wurde mal www.google.de aufgerufen
Wenn ich in dem WirrWarr die Zeichenkette MSS suche so sehe ich 1430 und 1460
312 21.190794 216.58.211.36 192.168.1.20 TCP 66 443 → 52561 [SYN, ACK] Seq=0 Ack=1 Win=42900 Len=0 MSS=1430 SACK_PERM=1 WS=128
309 21.167517 192.168.1.20 216.58.211.36 TCP 66 52561 → 443 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
Was da drüber fliesst ist eine wahre Pracht und für mich undurchschaubar.
Wieso ??? Wenn du nur ansatzweise ein klein wenig von IP weisst, was man bei deinem Netzdesign ja annehmen muss, dann kannst du hier doch kinderleicht sehen was da bei dir über die Leitung geht.Besser und übersichtlicher als der Wireshark kann dir das keiner anzeigen...
Wo genau ist denn hier dein Problem ??
Wenn ich in dem WirrWarr die Zeichenkette MSS suche so sehe ich 1430 und 1460
Stimmt ! Das sieht ja aber dann schonmal gut aus !Die LAN MSS sollte aber bei DSL niemals 1452 übersteigen, denn ist das größer besteht wieder die Gefahr der Fragmentierung.
Es sind Spheren, die habe ich bisher nie betreten und dementsprechend bin ich da dumm wie Brot. Dabei wird dem Brot noch unrecht getan.
Ich sehe da auch nur meine IP und die 216er um beim Fall oben zu bleiben.
Nur 2 verschiedene Richtungen.
Raus mit 1460 und rein mit 1430 so verstehe ich das.
Aber ich wüsste jetzt nicht selbstständig, was ich mit der Erkenntnis tun könnte.
Dazu müsste man das tuefergreifend erlernt haben denke ich. Ich habe leider keine IT Ausbildung, sondern für mich ist das ein Hobby.
Ich sehe da auch nur meine IP und die 216er um beim Fall oben zu bleiben.
Nur 2 verschiedene Richtungen.
Raus mit 1460 und rein mit 1430 so verstehe ich das.
Aber ich wüsste jetzt nicht selbstständig, was ich mit der Erkenntnis tun könnte.
Dazu müsste man das tuefergreifend erlernt haben denke ich. Ich habe leider keine IT Ausbildung, sondern für mich ist das ein Hobby.
Sodele ich habge da mal etwas herumprobiert.
Da ich ja früher die 5 Megabyte/s locker hatte und nicht wusste ob es an mir oder am Provider liegt, habe ich mal mit den FritzBoxen probiert.
Vor der PFSense habe ich normal eine 7360 welche, laut diversen Foren ein gutes Modem besitzen soll.
Da hatte ich die langsamen Raten.
Auch das Laptop direkt an die FritzBox brachte keine Verbesserung.
Seiner Zeit hing die 7390 vom Provider davor.
Jetzt mit dieser im wilden Aufbau, schafft die PFSense schonmal über 3 Megabyte/s
Allerdings da ich seiner Zeit die Box ausversehen resettet hatte und eh alles neu drauf bringen musste, habe ich auch auf die aktuelle Firmware geupdatet.
Nicht dass die irgend etwas ausbremst.
Jedenfalls bin ich da gerade etwas wankelmütig, ob ich nicht doch die ModemVariante wieder wählen sollte.
Nur müsste dann, sollte VoIP aktiv werden alles über die PFSense laufen, auich die Telefonie.
Die hätte ich sonst vorher abzwacken können
Da ich ja früher die 5 Megabyte/s locker hatte und nicht wusste ob es an mir oder am Provider liegt, habe ich mal mit den FritzBoxen probiert.
Vor der PFSense habe ich normal eine 7360 welche, laut diversen Foren ein gutes Modem besitzen soll.
Da hatte ich die langsamen Raten.
Auch das Laptop direkt an die FritzBox brachte keine Verbesserung.
Seiner Zeit hing die 7390 vom Provider davor.
Jetzt mit dieser im wilden Aufbau, schafft die PFSense schonmal über 3 Megabyte/s
Allerdings da ich seiner Zeit die Box ausversehen resettet hatte und eh alles neu drauf bringen musste, habe ich auch auf die aktuelle Firmware geupdatet.
Nicht dass die irgend etwas ausbremst.
Jedenfalls bin ich da gerade etwas wankelmütig, ob ich nicht doch die ModemVariante wieder wählen sollte.
Nur müsste dann, sollte VoIP aktiv werden alles über die PFSense laufen, auich die Telefonie.
Die hätte ich sonst vorher abzwacken können
Auch das Laptop direkt an die FritzBox brachte keine Verbesserung.
Das schliesst dann ja alle Fehler auf deiner Seite aus ! Mal unter der Voraussetzung das die FB nicht irgendwie defekt ist ?!Da liegt das Problem ja dann irgendwie auf der Providerseite.
Wie gesagt Providerseitig hatte ich seiner Zeit die 7390 bekommen.
Die hat jetzt die neueste Firmware und schafft nur noch 3Mbit.
Die selbst zugelegte 7360 ist langsam.
Ich muss das mal mit dem Modem testen
Die hat jetzt die neueste Firmware und schafft nur noch 3Mbit.
Die selbst zugelegte 7360 ist langsam.
Ich muss das mal mit dem Modem testen
Wenn du ein reines Modem hast wäre das gut.
Das sieht dann aber nach einem Leitungsproblem beim Provider aus...oder Überbuchung ?!
Das sieht dann aber nach einem Leitungsproblem beim Provider aus...oder Überbuchung ?!
