Kannst du Knicken, da fehlen dir zu viele Informationen

(Ja, auf Flughäfen erzeugt der ganze Technik-Haufen und die vielen bunten Kabel manchmal für erhöhten Blutdruck)

Auja, das kann ich mir vorstellen ;) Gerade die Security mag so elektronische Sachen in Koffern so gar nicht … :)

Hallo und danke für die Antwort

ja das stimmt das muss ich mir mal anschauen

aber das Webseiten Redirect hab ich im Squidguard eingerichtet und funktioniert ja auch
halt nur für HTTP Seiten und nicht für HTTPS Seiten

ich melde mich nochmal wenn es geklappt hat oder nicht

danke nochmal

MfG
Tim

Also nur von einer "Aussenstelle" der Firma mit der "Zentrale"?

Nein, es wird so ohne weiteres nie funktionieren, nicht ohne spezielle Voraussetzungen die da bspw. eine Art Multiplexer wäre. Du bräuchtest dann theoretisch zwei Anschlüsse vom gleichen Provider plus die Sicherheit, dass die in der gleichen Schaltstelle liegen etc. um dann da ansetzen zu können. Dann geht das Richtung Kanalbündelung bei ISDN.

Was Loadbalancing macht ist ja (je nach Konfiguration bspw.) ein RoundRobin der Verbindungen um so die Gesamtleistung zu verbessern. Somit kannst du natürlich bspw. - einen entsprechenden Downloadmanager vorausgesetzt - beide Leitungen für einen Teil des Downloads nutzen -> volle Geschwindigkeit. Beim Browsen werden bei echtem Round Robin dann auch alle Assets der Seite über die Leitungen verteilt - ergo auch hier leichte Verbesserung. Ein tatsächlich echtes verdoppeln oder verdreifachen durch mehr WAN Anschlüsse wird das aber nicht werden.

Viprinet "mogelt" da auch nur. Mit eigener Technik und mit erzwungener Gegenstelle. Du baust mit deinem Multichannel Router eine Verbindung zu deren Gegenstelle in einem RZ auf, dass eben entsprechend dick angebunden ist. Da deine einzelnen Channels von deinem Viprinet Router zu einem zweiten bei denen im RZ gebaut wird, können die dann eben eigens proprietär ein optimiertes Loadbalancing machen (ich mutmaße einfach mal in der Art wie Proxies/Caches das machen: indem der Request bei dir abgepuffert wird und dann der Request in Teilrequests zerlegt wird die wieder über jede Einzelstrecke geschickt werden). Das funktioniert aber eben nur zu deren Endpunkt im RZ und nicht nur durch anschließen von mehr WANs einfach ins Internet. Ohne passende Gegenstelle geht da nichts. Und dazu muss man dann dem Hersteller trauen, dass er einen nicht belauscht ;)

Zudem stimmt es auch nicht zu 100% was deren Details aussagen. Zitat von der Vipri Seite war sowas wie "Bei Loadbalancing von 1x16 und 2x6Mbps hätte man maximal 16Mbps". Das stimmt so aber nicht - siehe oben. Bei echter RoundRobin Konfiguration und entsprechende Unterstütung der Anwendung vorausgesetzt geht da auch 28Mbps. :)

Grüße

Hallo Bordi,

danke für deinen Beitrag. "Müssen" ist ja immer so eine Sache. Eigentlich funktioniert ja alles perfekt.
Der Gedanke war einfach nur, auf ein Gerät zu verzichten. Hätte den mistigen Asus Router (läuft nur als AP) gern ausgemustert.
Wenn es recht einfach gewesen wäre, die pfSense um Wlan zu erweitern, hätte ich das wohl auch gemacht.
So bleibt es nun doch so, wie es ist.
Danke trotzdem für die Beteiligung.

Liebe Grüsse

Ich habe alles nochmal neu gemacht und folgendes rausgefunden: wenn die Gateways einzeln genutzt werden, funktionieren alle, obwohl unter Status->Gateways alle als Offline angezeigt werden.
Bei allen Gatewayslässt sich die Monitor IP anpingen.
Wenn ich die Gateway Group wieder erstelle, funktioniert das Internet zwar, aber ich denke, dass nur ein Gateway aktiv ist. Wenn man im Browser seine öffentliche IP agzeigen lässt und zig mal einen Reload macht, ändert sich die IP nicht und die Internetgeschwindigkeit ist auch nicht schneller.
Jemand ne Idee?

Ich werde mich mal daran trauen.

Freut uns trotzdem zu hören, auch wenn es schade ist, dass das Board wohl der Verursacher war. Immerhin scheint man hier dazugelernt und das Board einer Revision unterzogen zu haben - deren Ergebnis du schlußendlich erhalten hast. Hoffentlich ist das dann auch das Ende für diese Fehler :)

Ich habe es lösen können. Sorry wenn das alles ein bisschen Wirr war.

Ich habe folgendes gemacht:

Unter "Virtual IPs" habe ich der pfsense-FW ein Standbein in dem Netz der TK-Anlage gegeben.

Anschließend habe ich eine Outbound-NAT-Regel erstellt (müsste glaube ich ein Source-NAT sein!?)…

Normales LAN: 192.168.100.0/24
TK-Netz: 172.1.2.0/24
Standbein der pfsense: 172.1.2.120/24

Die Regel sah dann so aus...

LAN  192.168.100.0/24 * 172.1.2.0/24 * 172.1.2.120 * Random Port

Somit kommen alle Anfragen von den Clients aus dem normalen LAN über die IP der pfsense. Hatte erst Befürchtungen das die TK-Software mir einen Strich durch die Rechnung macht und für jeden CLient eine seperate IP verlangt, dem war aber nicht so. Habe es schon überall getestet, läuft wunderbar.

Danke trotzdem.

Gruß

Hat denn niemand eine Idee? :(

#Quick (and dirty?)
#Squid General Settings -> Advanced Features -> Custom ACLS

acl no_redirect dstdomain site1.de site2.de
redirector_access deny no_redirect

Verhindert dass die Domains site1.de und site2.de über den squidguard laufen. Funktioniert am heimischen pfSense zumindest mal. (Getestet mit bild.de :-) )

Hi,

Danke für den Tipp!

Die Interfaces gehen laut GUI down und auch wieder up. Die GWs sind jedoch trotzdem nicht erreichbar.

Ein Ping liefert nur:

PING 192.168.18.254 (192.168.18.254): 56 data bytes ping: sendto: Invalid argument ...

Im Systemlog:

Jun 16 20:01:04 kernel arpresolve: can't allocate llinfo for 192.168.18.254 on re2_vlan3

Sofort nach einem "Save & Apply" in der GUI der WAN-Interfaces läuft alles wie geschmiert. Keine Ahnung was beim Aktivieren des "Save" oder "Apply" Buttons ausgelöst wird, aber scheinbar wird es bei einem  Reboot nicht ausgelöst.

Im Systemlog findet sich dann folgendes:

Jun 16 20:09:13 xinetd 16906 Reconfigured: new=0 old=1 dropped=0 (services) Jun 16 20:09:13 xinetd 16906 readjusting service 6969-udp Jun 16 20:09:13 xinetd 16906 Swapping defaults Jun 16 20:09:13 xinetd 16906 Starting reconfiguration Jun 16 20:09:12 php-fpm 70446 /interfaces.php: Creating rrd update script Jun 16 20:09:12 check_reload_status Reloading filter Jun 16 20:09:12 php-fpm 70446 /interfaces.php: Removing static route for monitor 8.8.4.4 and adding a new route through 192.168.18.254 Jun 16 20:09:12 php-fpm 70446 /interfaces.php: Removing static route for monitor 8.8.8.8 and adding a new route through 192.168.8.254 Jun 16 20:09:11 php-fpm 73673 /rc.dyndns.update: MONITOR: AndomTecGW is down, omitting from routing group Loadbalance Jun 16 20:09:11 php-fpm 73673 /rc.dyndns.update: MONITOR: AndomTecGW is down, omitting from routing group Loadbalance Jun 16 20:09:10 check_reload_status updating dyndns opt3 Jun 16 20:09:10 php-fpm 70446 /interfaces.php: The command '/usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid re0 re1' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.3.3-P1 Copyright 2004-2016 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Config file: /etc/dhcpd.conf Database file: /var/db/dhcpd.leases PID file: /var/run/dhcpd.pid Wrote 0 deleted host decls to leases file. Wrote 0 new dynamic host decls to leases file. Wrote 9 leases to leases file. Listening on BPF/re1/00:0d:b9:40:03:b9/192.168.0.0/24 Sending on BPF/re1/00:0d:b9:40:03:b9/192.168.0.0/24 Listening on BPF/re0/00:0d:b9:40:03:b8/172.16.11.0/24 Sending on BPF/re0/00:0d:b9:40:03:b8/172.16.11.0/24 Can't bind to dhcp address: Address already in use Please make sure there is no other dhcp server running and that there's no entry for dhcp or bootp in /etc/inetd.conf. Also make sure you a Jun 16 20:09:09 php-fpm 70446 /interfaces.php: MONITOR: AndomTecGW is down, omitting from routing group Loadbalance Jun 16 20:09:09 php-fpm 70446 /interfaces.php: MONITOR: AndomTecGW is down, omitting from routing group Loadbalance Jun 16 20:09:07 check_reload_status Restarting ipsec tunnels Jun 16 20:09:07 kernel arpresolve: can't allocate llinfo for 192.168.18.254 on re2_vlan3

Spannend ist das "…Can't bind to dhcp address: Address already in use..."

sg Martin

@yay:

Allnet ALL126AS2

Das kann IMHO kein Vectoring, dafür gibt es ein neueres Gerät. Wir benutzen selbst ein ALL126AS2 in der Firma, da haben wir jedoch nur max. 25/5 wegen Leitungslänge.
Erstaunlicher Weise ist die gegenüber liegende Straßenseite gerade gevectored worden und bekommt 100/40.  :-(

Moin,

habe es mit der 3. Option gelöst, weil sich $netter_Kollege krank gemeldet hat und somit das normale Tagesgeschäft auch noch bei mir landete  :'(
Somit musste ich jederzeit mit einer Unterbrechung rechnen …
Lt. Nagios läuft alles werde jetzt mal prüfen gehen.

Renovierung eines Büros eines etwas höheren Sesselpubsers: Ausräumen, Fußbodenbelag erneuern, Malerarbeiten und dann die relativ umfangreichen Elektroarbeiten ... is klaar

-teddy

Hallo JeGr

Danke dir für die Infos!
Ich werde das sogleich mal Testen!

Grüsse

Versuchs mal hiermit

https://nguvu.org/pfsense/pfSense-proxy-configuration/index.html

Oder evtl den Haken rausnehmen?

guard.JPG
guard.JPG_thumb

Nur wenn du auf der IP, auf die das ganze umgeleitet wird, wieder mit einem Redirect/Rewrite den Request umschreibst. Dann ja, ohne Probleme möglich.

Hi,

offensichtlich hast du es gerade nicht so gemacht wie in der Beschreibung! Mehr kann man dazu nicht sagen.

Gruß
Matthias