Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - jinn

#31
German - Deutsch / Re: HAproxy als Reverse Proxy
April 12, 2018, 06:18:33 PM
Noch kurz, damit es auch komplett ist, die Konfiguration bzgl. redirect von port 80 auf 443, da ich hier noch eine Frage habe:

Public Service:
Kopie von der SSL Konfiguration (Diese hat nur noch 86.167.153.108:443 als Listen Addresses)

folgende Änderungen:
Listen Addresses: 86.167.153.108:80
Enable SSL offloading ( )  -   (nicht aktiviert)
Select Rules (redirect_acme_challenges; rul_http_redirect_to_https)

Condition
con_http_redirect_to_https
Condition type: SSL/TLS connection established
Negate condition (X)

Rules
rul_http_redirect_to_https
Test type: IF (default)
Select conditions: con_http_redirect_to_https
Logical operator: AND (default)
Execute function: http-request redirect
HTTP Redirect: scheme https code 301

Damit komme ich jetzt auch auf den file.domain.com obwohl dieser an irgendwelchen stellen immer wieder auf Port 80 wechselt (die Software dahinter wird sowieso schnellstmöglich ersetzt, daher lohnt sich der aufwand nicht da weiter zu prüfen)


Eine Frage habe ich jetzt allerdings noch, was passiert, wenn mehrere condition treffen?
z.B. redirect_acme_challenges und http_redirect_to_https (anfragen über das letsencrypt plugin kommen bisher immer über port 80 rein)
Bei meinem einzigen Test hat es zwar funktioniert, dass die condition vom Plugin genutzt wird, wie kann ich mir aber sicher sein, dass das immer passiert?

Die Reihenfolge scheint kein Indiz zu sein, da diese nach dem Alphabet sortiert wird.

e: Ein Zertifikat erneuern funktioniert Problemlos wenn beide Regeln aktiv sind. Will ich aber ein Zertifikat für eine neue Domain anfordern erhalte ich Fehlermeldungen.
Erst wenn ich die regel "rel_http_redirect_to_https" aus dem public_services entferne funktioniert es.
#32
German - Deutsch / Re: HAproxy als Reverse Proxy
April 12, 2018, 01:32:05 PM
Quote
Mit deinen Edit komme ich nicht so ganz klar.

Quotee: das wiki funktioniert! beim file springt er immer auf http anstatt https zu nutzen
Das heißt, das es schon mal funktioniert da du zwischen wiki und file anfragen unterscheidest ?
Kann es sein das die WebAnwendung hinter file automatisch auf http umsetzt ?

Genau,

https://wiki.domain.com klappt
https://file.domain.com leitet um auf http://file.domain.com und landet dann natürlich in einem Fehler, woran das liegt weiß ich immer noch nicht - sieht aber eher nach extern aus, da die Anfrage bei HAproxy (laut log) bereits per Port 80 ankommt

Quote
QuoteEin weiteres Problem bei der Konfiguration seh ich jetzt allerdings im letsencrypt plugin, dieses verlangt ja pro domain einen service (ggf kann es ja jetzt auch mit wildcard arbeiten, was passiert aber, wenn wir auch unterschiedliche Domains pro IP nutzen? (können wir glücklicherweise umgehen, dennoch wäre das in der Zukunft vlt ein Problem)
Verstehe die Frage nicht so ganz. Alle deine Zertifikate, für welche Domain auch immer, kommen auf den Frontend Server drauf. Mit einer IP kannst Du verschiedene Domains mit Zertifikaten laufen lassen.
Oder was meist du genau ?

Mein Fehler, habe bisher nicht wahr genommen, dass man pro Frontend Server mehrere Zertifikate nutzen kann und dieser dann das richtige nutzt
Auch bei dem LetsEncrypt Plugin bin ich weiter nachdem ich mir das mal genauer angesehen habe, die Freigabe von extern klappt zwar noch nicht, da bin ich aber dran.

Vielen dank bisher! Ich versuche jetzt erstmal die bisherigen Probleme zu beheben und kümmer mich am schluss dann noch um das redirect auf Port 443. Hatte dazu auch schon 1-2 Beiträge im Forum gefunden.


e: liegt vermutlich am Server dahinter, https://file.domain.com/ leitet weiter zu http://file.domain.com/accounts/login/?next=/

https://file.domain.com/accounts/login/?next=/ direkt klappt aber sofort

Nach dem einloggen geht es dann weiter nach http://file.domain.com/ und die Verbindung ist wieder weg. Mit https://file.domain.com/ komm ich dann aber rein >_<
#33
German - Deutsch / Re: HAproxy als Reverse Proxy
April 12, 2018, 09:11:34 AM
Leider klappt es immer noch nicht :(

Ich habe bei der Condition auch mit "SNI TLS extension matches" getestet, leider hat auch das nicht funktioniert.

Im HAProxy Log bekomme ich nur folgenden Eintrag:
haproxy[69631]: Connect from 1.2.3.4:3514 to 86.167.153.108:443 (publicservice/HTTP)

Ich habe die Condition zum testen mal auf darauf geändert, dass die Source IP abgefragt wird und hier die externe IP vom Smartphone aus dem Telekom Netz eingetragen. Auch jetzt sehe ich im Log keinen anderen Eintrag.
Anscheinend wird die Regel in gar keiner Form abgefragt?
e: mein Fehler, der Haken bei SSL Offload war nicht gesetzt, jetzt wird es soweit aufgelöst, dass ich bei beiden Domains "/accounts/login?next=/" erhalte, also grundsätzlich die file-regel genommen wird (noch ist die match-ip condition aktiv, also kein problem) - im Log bekomme ich jetzt diesen Fehler:

1.2.3.4:4286 [12/Apr/2018:09:22:09.501] publicservice/86.167.153.108:80: SSL handshake failure

e: das wiki funktioniert! beim file springt er immer auf http anstatt https zu nutzen


Ein weiteres Problem bei der Konfiguration seh ich jetzt allerdings im letsencrypt plugin, dieses verlangt ja pro domain einen service (ggf kann es ja jetzt auch mit wildcard arbeiten, was passiert aber, wenn wir auch unterschiedliche Domains pro IP nutzen? (können wir glücklicherweise umgehen, dennoch wäre das in der Zukunft vlt ein Problem)
#34
German - Deutsch / HAproxy als Reverse Proxy
April 11, 2018, 05:51:36 PM
ich habe mich jetzt schon durch einige Beiträge hier im Forum und Netz geschlagen, leider habe ich aber meine Lösung noch nicht gefunden, daher versuche ich es nochmal mit einem eigenen Thread.

Folgende Ausgangslage: OPNSense 18.1.6 (LibreSSL)

WAN Netz: 86.167.153.104/29
.105 & .106 sind durch die Telekom blockiert, somit bleiben mir aktuell folgende IP Adressen:
86.167.153.107 (Zugang ins Internet funktioniert bereits)
86.167.153.108 (hierüber sollen zwei Websites erreicht werden, https://file.domain.com und https://wiki.domain.com)
86.167.153.109 (vorerst nicht benötigt)
86.167.153.110 (vorerst nicht benötigt)
(ich nutze bewusst nicht pro domain eine IP, da es sich hier um ein LAB handelt und wir später auch mehrere Domains pro IP haben)


Zugriff soll so ablaufen

Zugriff per Browser auf 86.167.153.108 per HTTPS (HTTP redirect HTTPS) -> OPNsense -> HAProxy -> Server (Port 80)


Folgendermaßen habe ich versucht den Zugriff einzurichten:
Firewall - Rules - WAN
Source *
Port *
Destination 86.167.153.108/29
Port 443

Source *
Port *
Destination 86.167.153.108/29
Port 80

Firewall - Virtual IPs - Settings
Virtual IP address 86.167.153.108/29
Interface WAN
Type IP Alias

HAProxy
Real Servers
Name file
FQDN or IP file.locale.lan
Port 80

Name wiki
FQDN or IP wiki.locale.lan
Port 80

Backend Servers
Enabled (x)
Mode: HTTP (Layer 7)
Servers: file
Rules: file-rule

Enabled (x)
Mode: HTTP (Layer 7)
Servers: wiki
Rules: wiki-rule

Public Services
Enabled (x)
Listen Addresses: file.domain.com:443 file.domain.com:80 86.167.153.108:443 86.167.153.108:80
Type: HTTP/HTTPS (SSL offloading)
Default Backend Pool: file
SSL Certificate: *.domain.com (gekauftes Wildcard Zertifikat)
Select Rules: file-rule

Enabled (x)
Listen Addresses: wiki.domain.com:443 wiki.domain.com:80 86.167.153.108:443 86.167.153.108:80
Type: HTTP/HTTPS (SSL offloading)
Default Backend Pool: wiki
SSL Certificate: *.domain.com (gekauftes Wildcard Zertifikat)
Select Rules: wiki-rule


Rules & Checks
Condition
Name: file-condition
Condition type: Host starts with
Host Prefix: file

Name: wiki-condition
Condition type: Host starts with
Host Prefix: wiki

Rules
Name: file-rule
Test type: IF
Select condition: file-condition
Execute function: Use specified Backend Pool
Use backend pool: file

Name: wiki-rule
Test type: IF
Select condition: wiki-condition
Execute function: Use specified Backend Pool
Use backend pool: wiki

Im Log erhalte ich nur folgende Mitteilung
haproxy[95545]: Connect from 1.2.3.4:21630 to 86.167.153.108:443 (wiki.domain.com/HTTP)
#35
18.1 Legacy Series / [SOLVED]squid blocks update
April 09, 2018, 05:23:30 PM
Hello guys,

fresh install of OPNsense last friday, now i wanna update to 18.1.6 but squid isnt able to reinstall:

[1/37] Fetching squid-3.5.27_3.txz: .......... done
pkg-static: cached package squid-3.5.27_3: size mismatch, fetching from remote
[2/37] Fetching squid-3.5.27_3.txz: .......... done
pkg-static: cached package squid-3.5.27_3: size mismatch, cannot continue


I tried "pkg update -f" and upgrade but it didnt help


fixed by changing Firmware Mirror from dns-root.de to (default)
#36
German - Deutsch / Re: OPNsense MultiWAN
April 05, 2018, 04:56:32 PM
Da kann ich nur raten, da ich noch nicht so lange im Betrieb bin. Ich vermute aber, dass es daran lag, dass unterschiedliche Geräte die unterschiedlichen Netzte genutzt haben (TMG, Watchguard und in der Vergangenheit ggf. noch was älteres)
Routing auf eine IP wäre auch kein Problem, laut der Telekom. Da wir aber aktuell mit der OPNsense das 3. Netz nutzen war das für mich bisher aber eine gute Lösung, da ich so nicht noch einen Router intern für das Routing konfigurieren musste.

VHID habe ich quasi nur übernommen, das sind die zwei IPs die von der Telekom für das Failover genutzt werden und daher nicht von uns genutzt werden können (würde beim Routing natürlich wegfallen).

Aktuell sehe ich also momentan folgende Wege:

Aktuelle Konfiguration beibehalten und pro Netz 1 NIC verwenden
Routing von Netz 2 und 3 auf IP in Netz 1 und nur 1 NIC für alle verwenden und mehr IPs zur Verfügung stehen zu haben

zumindest wirken beide Konfigurationen sauber, wovon die 2. natürlich den Charme der weiteren IP Adressen hat.
Der Plan wäre also aktuell folgender: Testsystem mit 3. Netz aufbauen
Konfiguration von TMG (Netz2) und Watchguard (Netz1) in OPNsense abbilden
Netz 3 Routing auf Netz1 umstellen lassen -> Nach Testphase Netz2 auf Netz1 routen lassen

Vielen dank für die ausführliche Unterstützung von allen hier!
#37
German - Deutsch / Re: OPNsense MultiWAN
April 05, 2018, 03:09:51 PM
Die Netze sind alle gleich Aufgebaut:
(Es sind natürlich 3 IPs pro Netz, nicht 4 wie ich bisher falsch gesagt habe)
Bei Netz 1 habe ich jetzt die erste VHID mit der ersten IP getauscht, um es einfacher zu machen. Real ist aber die 86.167.49.90 die erste IP und 86.167.49.92 gehört zur VHID


 
   
   
   
   
   
   
   
   
Netz86.167.49.88/2986.167.153.104/2976.216.133.200/29
GW86.167.49.8986.167.153.10576.216.133.201
VHID86.167.49.9086.167.153.10676.216.133.202
VHID86.167.49.9186.167.153.10776.216.133.203
IP86.167.49.9286.167.153.10876.216.133.204
IP86.167.49.9386.167.153.10976.216.133.205
IP86.167.49.9486.167.153.11076.216.133.206
BC86.167.49.9586.167.153.11176.216.133.207
#38
German - Deutsch / Re: OPNsense MultiWAN
April 05, 2018, 02:21:28 PM
Nein, wir haben 3 Netze, der Screenshot zeigt nur den Beispiel von dem einem Netz, dass am TMG genutzt wird.

Insgesamt sind es aber 3 /29er Netze die wir haben:

86.167.49.88/29
86.167.153.104/29
76.216.133.200/29
(andere IPs aber quasi dieses Schema)

IP 1 aus Netz 1 (86.167.49.90) nutzen wir für den externen Ausgang
Die 4 IP Adressen für Netz 2 nutzen wir für den Eingang auf z.B. gehostete Systeme

Netz 3 wurde bisher nicht verwendet und dient daher aktuell nur zum Testen an der OPNsense.
In Zukunft sollen aber alle 3 Netze an der OPNsense verwendet werden. Die gleiche IP soll für extern genutzt werden, die gleichen externen IPs auf die gleichen internen gemappt. Die freien IPs werden dann für zukünftige externe Zugänge (weiteres Hosting, ...) genutzt.
In dem Fall werde ich also ein Netz jeweils einem NIC zuordnen, wenn das die einfachste Lösung ist.

MultiWAN war auch der falsche Ausdruck, wir haben zwar zwei Verbindungen, davon ist eine allerdings nur eine aktiv. Die zweite Leitung wird als Failover verwendet, sollte die erste ausfallen, das Routing wird dann automatisch gewechselt. Bei Verfügbarkeit der Hauptleitung geht es dann wieder zurück
#39
German - Deutsch / Re: OPNsense MultiWAN
April 05, 2018, 01:38:00 PM
>Allein aus den CARP Gründen sollte die 2. Maschine so identisch wie möglich sein (gerade bei den NICs). Aber auch rein logisch dimensioniert man ja Appliances so, dass sie groß genug sind mit Luft nach oben. Da sollte man dann schon das Gleiche nehmen, denn im Ausfall-Falle will man dann ja nicht auf dem Zahnfleisch rumkugeln bis der Master wieder läuft. Wir hatten in der Vergangenheit verschiedene Maschinen - das war ein einziger Graus und ich kann nur jedem produktiv davon abraten.

Ich würde hier bis auf zwei Komponenten (Pentium anstatt Xeon und 4/8GB anstatt 16) ändern. Mainboard und PCI-E NIC würden identisch bleiben.


>> Nun stellt sich mir aber die Frage, ob wir alle 3 Netze an einem NIC nutzen können? Wie wäre hier die sinnvollste Lösung?

>Nutzen sicherlich, aber wie ist "an einem NIC" gemeint?
Wie bekommt ihr die 3 /29er Netze denn von der Telekom? Geroutet?

Genau, derzeit sind an den Netzwerkkarten im TMG und in der Watchguard jeweils ein Netz direkt am NIC eingetragen, sprich die IP ist eine externe, das Gateway die Gateway IP aus dem jeweiligen /29-Netz. Die anderen 3 Adressen können werden dann als Alternative IP (Watchguard) bzw "IP addresses" eingetragen (attachment)



>> Für den Zugang nach innen muss ich vermutlich 1:1 NAT nutzen, wenn ich das richtig gelesen habe?

>Die Antwort darauf hängt an der Frage darüber: wie bekommt ihr die Netze von der Teleokom auf eure Kiste momentan (also den TMG vermutlich)?

(attachment)

>> Derzeit haben wir eines der Netze an die Test OPNsense angebunden, wenn wir raus gehen erhalten wir aber nicht immer die gleiche IP Adresse sondern unterschiedliche aus dem jeweiligen Netz.

>Schau mal dazu im Forum, es gab da eine Diskussion dazu und einen patch von Franco, den du dazu einspielen kannst. Künftig gibts das nicht mehr wie mimu schon sagt mit dem nächsten Release. Hat auch IMHO keinen Grund/Vorteil dass das überhaupt reinkam, sondern wie in deinem Fall eher Probleme.

Danke, euch beiden für die Info, dann hoffe ich vorerst auf einen schnellen Release, der neue Server soll kommende Woche kommen, ansonsten werde ich den Patch nutzen

Gruß
#40
German - Deutsch / OPNsense MultiWAN
April 04, 2018, 07:07:34 PM
Hallo zusammen,

aus einem kleinen Testprojekt soll nun doch ein Liveprojekt werden -> OPNsense soll die aktuelle Firewalllösungen ablösen

Wir besitzen bei der Telekom 3 IP Netze mit /29-Gateway, die wir so auch auf der OPNsense nutzen wollen. Derzeit wird ein Netz von der Watchguard für den Zugang nach außen und ein Netz auf dem TMG für den Zugang nach innen (die Lösung habe ich bei Arbeitsbeginn so "übernommen" - daher kann ich nicht beantworten, warum man sich für so eine Lösung entschieden hat)

Nun stellt sich mir aber die Frage, ob wir alle 3 Netze an einem NIC nutzen können? Wie wäre hier die sinnvollste Lösung?
Derzeit haben wir eines der Netze an die Test OPNsense angebunden, wenn wir raus gehen erhalten wir aber nicht immer die gleiche IP Adresse sondern unterschiedliche aus dem jeweiligen Netz.
Für den Zugang nach innen muss ich vermutlich 1:1 NAT nutzen, wenn ich das richtig gelesen habe? Zumindest arbeitet auch der TMG mit diesem Prinzip, hier wird nur angegeben von welcher externen IP die Anfrage kommt und an welchen Server diese dann übermittelt wird.
Wäre es hier sinnvoller/einfacher die Konfiguration komplett in der OPNsense zu machen und zwischen den beiden Geräten der Telekom (failover) nur einen unmanaged Switch (aktuelle Lösung) zu klemmen, oder das NAT in einem Switch zu konfigurieren?


In Zukunft soll dann auch noch eine zweite OPNsense als Failover dazu kommen. Ist es hier nötig die komplett gleiche Hardware zu nehmen? Wir haben uns jetzt für die "viel zu große Lösung" entschieden, 16GB RAM, XEON-1230, 2x 240GB SSD, damit wir auch gar keine Performanceprobleme bekommen, da die ersten Dienste am besten sofort über die neue Firewall laufen sollen.
Für das Failoversystem würde ich aber, wenn es keine Probleme geben würde, die Minimallösung nehmen: 4GB Ram, Intel Pentium G4600