Messages

1

German - Deutsch / Re: Multiwan -Verbindungsabbrüche

« on: March 21, 2020, 06:42:55 am »

Habe unbound aktiviert und auf meinen internen DNS servern einen forward auf die FW gesetzt.
DNS funktioniert jetzt. Jedoch bauen sich nach wie vor Webseiten sporadisch nicht auf. Ein paar mal "reload" der Webseite, und dann laden die Seiten.

Echt mysteriös.

2

German - Deutsch / Re: Multiwan -Verbindungsabbrüche

« on: March 20, 2020, 09:46:33 am »

Guter Punkt. Hätte ich gleich schreiben können... :-)

Also, im wesentlichen sind es (denke ich) DNS Probleme, vermute ich, die dann zu allerlei nachfolgenden Problemen führen.

Mein DNS Setup:

Im LAN sitzen 2 AD Controller jeweils mit DNS servern. Für externe Domains ist dort ein forward eingerichtet, z.B. auf 8.8.8.8 und 1.1.1.1. Unbound ist auf der FW nicht aktiv.

Jeder WAN link auf OPNsense hat "override DNS by PPPoE" disabled. Default Gateway Switching ist on. Meine Routing Tabelle für DNS sieht so aus:

ipv4   1.1.1.1   <IP von PPPoe assigned DFGW)   UGHS   0   1492   pppoe1   VDSL175       
ipv4   8.8.8.8   <Statische DFGW IP vom ISP>   UGHS   44   1492   pppoe0   VDSL100

Sieht also gut aus. Trotzdem wird sporadisch nicht aufgelöst. Ein traceroute aus dem LAN auf die beiden DNS geht aber, und der traffic läuft über den richtigen gateway.

Habe mittlerweile 2 Gateway groups (eine Failover und einer Loadbalance) eingerichtet.

Bei Webseiten hilft es manchmal nach ein paar Sekunden einen "reload" zu machen, dann wird wieder aufgelöst.
Habe für https mittlerweile eine FW PBR Regel eingefügt, welche https immer über die Failovergruppe sendet, so dass die Webserver immer die gleichen Source IPs sehen, machne mögen es nicht, wenn die SRC wechselt.

Was ich noch nicht probiert habe, ist die LAN DNS server so zu konfigurieren, dass meine FW der DHCP forwarder ist. Auf der FW müsste ich dann noch unbound aktivieren.

3

German - Deutsch / Re: Multiwan -Verbindungsabbrüche

« on: March 20, 2020, 06:51:34 am »

Push... :-)

Hat wirklich niemand eine Idee?

4

German - Deutsch / Re: Portweiterleitung - Ich verstehe es nicht...

« on: March 14, 2020, 06:51:27 am »

Zum Thema "interne IP": NAT kommt vor Filter. Deswegen zeigt die FW Regel auf die interne IP.
Und eigentlich müsstest Du kein "Pass" angeben, sondern wenn Du die Port Forward Regel neu erstellt, müsste er Dir angeben "Create Associated Filter Rule". Dann bekommst Du eine spezifische FW Regel auto erstellt für die spezifische NAT Regel.

5

German - Deutsch / Multiwan -Verbindungsabbrüche

« on: March 14, 2020, 06:27:17 am »

Hallo, mein Setup sieht wie folgt aus:

              WAN                   WAN
                 :                        :
                 : DSL-Provider       : DSL-Provider
                 :                        :
             .---+---.                 .--+--.
         WAN | DSL |           | DSL | WAN2
             '---+---'                 '--+--'
                 |                        |
                |  Stat public IP     |Dyn Public IP
                 +------| OPNsense |------+
                             |       |
                      LAN |       | LAN
                             |       |
                       .-----+------.
                       | LAN-Switch |
                       '-----+------'
                             |
                     ...-----+-----...
                     (Clients/Servers) 10.1.1.0/24 und 192.168.4.0/24

Ich habe zwei Gateways mit Überwachung konfiguriert und die entsprechende Gateway Group angelegt.

Problem ist, wenn ich beide WAN links in das gleiche Tier 1 konfiguriere, dann habe ich Verbindungsabbrüche. Eigentlich sollte doch ein Session Based Load Balancing funktionieren? Konfiguriere ich die beide links in unterschiedliche Tiers, kann ich beide nutzen, z.B. wenn ich für bestimmte Server/Clients/Ports Policy Based Routing konfiguriere.

Unter System -> Settings -> General habe ich "allow default gateway Switching" aktiviert.
Unter Firewall -> Settings -> Advanced habe ich "use sticky connections" aktiviert.

Auf dem LAN Interface gibt es eine PBR Regel: LAN -> any -> pass -> Gateway "WAN links Group"

Outbound NAT (Hybrid Rules) auto-generiert jeweils auf dem jeweiligen WAN Interface (Also 2x): LAN -> Source Port: any -> Dest: any -> Dest Port: any -> NAT Address: WAN interface Address -> NAT Port: any -> Static Port: No

Trotzdem habe ich die genannten Probleme.

Ich weiß tatsächlich nicht mehr, wo ich noch schauen könnte. Hat jemand eine Idee?

6

German - Deutsch / Re: Wireguard Multiwan

« on: March 07, 2020, 07:35:53 am »

Kann ich bestätigen. Habe in den clients als "peer" einen DDNS Namen zeigend auf die dyn IP des WAN links mit der dynamischen IP gelegt und läuft...

7

German - Deutsch / Re: Wireguard Multiwan

« on: March 06, 2020, 10:43:57 am »

Denke ich habe das Problem schon mal identifiziert, weiss nur nicht, wie ich es lösen kann:

Vielleicht vorab:

Meine Leitungen in den Gateway Groups sind nicht im gleichen Tier, sondern die Leitung mit der Dynamischen IP ist Tier 1, die mit den statischen IPs ist Tier 2. Die Tier 2 Leitung ist nur Backup, bzw. wird nur für inbound services (Server) genutzt. Damit für diesen Traffic für den outbound Weg nicht die Tier 1 Leitung genutzt wird, setze ich mittels Firewall route den Gateway der Tier 2 als Gateway für genau diesen Traffic von den jeweiligen Servern outbound. Klassisches Poilcy Based Routing.

Das WireGuard Paket kommt über das richtige WAN Interface (Tier 2 mit statischen IPs) rein und geht aber über das falsche (Tier 1) raus.

Mir fehlt aber gerade die Phantasie, wie ich für den Wireguard Serice den Traffic über Tier 2 outbound erzwinge?

8

German - Deutsch / Re: Wireguard Multiwan

« on: March 05, 2020, 04:22:14 pm »

SSH auf die Firewall geht ohne Probleme. (any -> this Firewall -> SSH -> allow)

Auch Portforwarding auf Server im LAN geht (inbound NAT: externe statische IP WAN1-> LAN IP / outbound NAT: src IP server -> destination any, NAT source address = gateway address, gateway = wan1 gateway)

Ich sehe auch, dass mein WG Tunnel aufgebaut wird, die Clients senden halt nur TLS handshake requests, die offensichtlich nicht beantwortet werden. Der Wireguard traffic schlägt also sicherlich auf der FW auf.

9

German - Deutsch / Wireguard Multiwan

« on: March 05, 2020, 10:28:22 am »

Hallo,

ich habe ein Problem, dass keine Daten durch den Wireguard Tunnel geroutet werden. Mein Setup sieht so aus:

Code: [Select]


              WAN                      WAN
                 :                        :
                 : DSL-Provider       : DSL-Provider
                 :                        :
             .---+---.                 .--+--.
         WAN | DSL |           | DSL | WAN2
             '---+---'                 '--+--'
                 |                        |
                |  Stat public IP     |Public IP
                 +------| OPNsense |------+
                             |       |
                      LAN |       | LAN
                             |       |
                       .-----+------.
                       | LAN-Switch |
                       '-----+------'
                             |
                     ...-----+-----...
                     (Clients/Servers) 10.1.1.0/24 und 192.168.4.0/24



Ich habe den Wireguard Server aufgesetzt und Clients entsprechend konfiguriert.
Ich hatte Wireguard schon einmal aufgesetzt, als ich nur eine Leitung hatte.

Jetzt mit 2 Leitungen wird mein Tunnel im client log zwar als "Connected" angezeigt, allerdings werden keine Daten geroutet. "TLS handshake initialization started" und diese läuft dann in einen Timeout. Der Tunnel terminiert über den DSLer mit statischer IP Adresse und muss ja darüber auch wieder raus.

Inbound allow Regel UDP auf WG Server Port auf "This Firewall" ist gesetzt, allowed IPs sind testweise jeweils die kompletten /24 Netze aus den beiden LANs und aus dem virtuelle WG Netz.

Ich vermute stark, dass ich irgendwo im outbound NAT noch ein Thema habe, stehe aber auf dem Schlauch.
Kann mir jemand einmal kurz mit den notwendigen Regeln (ggfls. Routen) helfen?

wupperi

10

German - Deutsch / Re: 2x Telekom VDSL / unterschiedliche ISP

« on: February 29, 2020, 07:46:52 am »

Ich glaube ich habe das Problem gefunden, und dokumentiere die Lösung mal für andere:

Die beiden Modems (im Bridge Mode, nicht Router Mode) hatten beide noch einen Management Link, welcher mit meinem LAN verbunden war. Sobald ich die LAN links entfernt habe, liefen die PPoE Anmeldungen korrekt auf dem jeweiligen Modem.

Es sieht so aus, als wären die PPPoE Pakete (auch) übers LAN versandt worden, und entsprechend einfach vom erstbesten Modem beantwortet worden, welches dann die entsprechende PPPoE session aufgebaut hat.

11

German - Deutsch / 2x Telekom VDSL / unterschiedliche ISP

« on: February 28, 2020, 10:50:42 am »

Hallo,

ich habe folgendes Setup mit 2 WAN links.

OPNsense 20.1.1-amd64

Internet -----> VDSL175 (Telekom mit t-online login) via ISP1 ------> Vigor165 bridging ----> cat6 -----> OPNSense ibg4 pppoe0

Internet -----> VDSL100 (Telekom Vorleistungsprodukt) via ISP2 -------> anderer Vigor165 briding ----> cat6 -----> OPNsense igb5 pppoe1

Gateways sind entsprechend eingerichtet, ebenso eine Gateway Group, beide Gateways in Tier 1.

Ich habe jetzt das Problem, dass die PPPoE Dialer völlig unvorhersehbar nach einem reboot entweder:

a) gar keine PPPoE Session aufbauen
b) nur einer von beiden eine Session aufbaut
c) und völlig komisch, die PPPoE dialer "springen", d.h. auf einmal ist mein PPPoE Login vom ibg4 pppoe0 auf dem Anschluss, der auf igb5 und pppoe1 konfiguriert ist. D.h. ich bekomme eine IP von ISP1 auf dem Anschluss von ISP2


Auf ISP1 (T-Online) habe ich über den Telekom Kundencenter konfiguriert, dass Username und Login ausgewertet werden.

Interessanterweise wird mir auch bspw igb5/pppoe1 als "up" angezeigt, obwohl das Interface igb5 down ist, wenn ich bspw. aus dem VDSL Modem, welches an igb5 angeschlossen ist das cat6 Kabel ziehe. Also das physikalische Interface erkennt down, aber der dialer erkennt up (kriegt dann aber keine IP Adresse)

Sieht irgendwie so aus, als wären die dialer nicht "hart" an das physikalische Interface gebunden?

Komme an dieser Stelle gerade nicht mehr weiter.
Hat jemand eine Idee?

12

German - Deutsch / Port Weiterleitung in IPSEC Tunnel

« on: December 27, 2019, 01:28:29 pm »

Hallo in die Runde,

der Engländer sagt, "banging my head against the wall"... :-)
Ich kriege folgende Herausforderung nicht hin:

Ich habe zwei OPNsense Firewalls.

FW-A: (Beim hoster, virtuelle OPNsense auf Esxi)
-> hat extern ein statisches /28 IPv4 Netz.
-> LAN Netz (A)
-> DMZ Netz (A)

Die öffentlichen, statischen IP Adressen sind als virtuelle IPs auf das externe Interface gebunden.

FW-B (Bei mir zu Hause, auf physikalischer HW)
-> extern DynDNS
-> LAN Netz (B)

Zwischen den beiden läuft ein gerouteter IPSEC Tunnel mit Gateways.
Ping zwischen LAN(A) und LAN(B), bzw LAN(B) und DMZ(A) geht. Tunnel geht also und routing durch den Tunnel passt. Regeln für das IPSEC interface sind beidseitig any any allow.

Jetzt sollen aber services die im LAN(B) bei mir zu Hause stehen, aus dem Internet erreicht werden.
Ich habe also eine Portweiterleitung auf der FW(A) eingerichtet:

Quelle (any) --- Ziel (öffentliche statische IP Adresse, Port 80 bspw) ---> Weiterleitung auf (private LAN(B) Server adresse, Zielport 80)
FW Regel automatisch erstellen lassen.

D.h. nach meinem Verständnis:
Die Anfrage schlägt als Ziel auf der öffentlichen IP der FW(A) auf, Ziel wird genattet auf die private Adresse im LAN(B) und durch den Tunnel transportiert.

Ich bekomme aber - egal was ich mache - keine Verbindung hin.
In der Liveansicht sehe ich, dass Pakete (public Quell-IP -> private server IP) durchgelassen.

Ich vermute, dass Problem ist, dass das Antwortpaket meines Server im LAN(B) an die ursprüngliche anfragende öffentliche IP Adresse geht, und quasi durch meine FW(B) zu Hause ins Internet will. Das wäre dann asymmetrisch und in der FW(B) sollte es geblockt werden, wegen fehlendem state... 

Ist mein Verdacht richtig? Wie kann ich das lösen?
Danke vorab für Eure Hilfe.


wupperi