Messages

@superwinni2

Danke für deine Hilfe.

Habe jetzt das frontend auf 0.0.0.0:80 geändert und die NAT rule entfernt.

Jetzt sehe ich im haproxy log die aufrufe. Wenn ich http://domain eingebe komme ich auch auf die Seite. https leider nicht.

was wäre jetzt der richtige weg? im client nginx die ssl keys löschen und dann auf der sense ssl für haproxy zu erstellen?

Bzw. warum gibt er nur das HTTp durch aber nicht das HTTps vom client?

Ich sehe aber nie eine Anfrage im log von haproxy.

Ich habe noch wie in einem Vorschlag:

die beiden rules eingetragen :

WAN   TCP   *   *   WAN address   443 (HTTPS)   127.0.0.1   443 (HTTPS)

IPv4 TCP   *   *   127.0.0.1   443 (HTTPS)   *      NAT

gefunden :

# Frontend: mattermost_frontend ()
frontend mattermost_frontend
    bind 127.0.0.1:80 name 127.0.0.1:80
    mode http
    option http-keep-alive
    default_backend Mattermost_back
    # tuning options
    timeout client 30s

    # logging options
    # ACL: Mattermost_ACL
    acl acl_5ce7bccb5fd722.63607215 path_beg -i /*

    # ACTION: Mattermost_aktion
    use_backend Mattermost_back if acl_5ce7bccb5fd722.63607215

# Backend: Mattermost_back ()
backend Mattermost_back
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    http-reuse never
    server Mattermost 192.168.1.20:443 ssl verify none

Die config ist momentan ohne Letsencrypt , auf dem client läuft nginx mit ssl

Wenn ich probiere die Seite aufzurufen kommt :

SSL hat einen Eintrag erhalten, der die maximal erlaubte Länge überschritten hat. Fehlercode: SSL_ERROR_RX_RECORD_TOO_LONG

habe es noch einmal eingestellt aber läuft leider nicht.

wo befindet sich (pfad) die config datei zum auslesen?

Danke superwinni2,

ich stelle es erneut ein und poste dann meine config.

okay ,

probiere ich noch mal:

https://forum.opnsense.org/index.php?topic=12126.0
diese Howto habe ich als Vorlage genommen.

Kann ich dann die config auslesen um sie hier zu posten?

Hallo,

erstmal schön zu lesen, das am ende alles funktioniert.

Ich habe jetzt 3x probiert nach diversen Anleitungen Haproxy mit letsecrypt aufzusetzten,scheietere aber bisher immer.

Ich möchte am Ende 3 instanzen einbinden und mit ssl ansichern.

Hat jemand mal von seiner config ein paar Bilder? Mein Beispiel wäre zb ein Nextcloud.


Anfrage nextcloud.example.com ----> Opnsense-haproxy ---> nimmt entgegen ----> Weiterleitung auf den Client (192.168.1.2) Port 80.

Beim letsencrypt plugin stand immer pending. Hatte aber gesehen das er es über port 444 probiert hat. (hatte die opnsense Gui https auf den Port gelegt wie es in der Anleitung geschrieben stand).

Derzeit habe ich alle plugins wieder heruntergeworfen. Ich würde mich freuen, wenn mir jemand einen Anstoß geben kann.

Danke

Ich glaube damit habe ich es . ist gerade ein erster Test, aber mir fallen gerade keine grauen Haare mehr aus :).
Mein Client PC mit der 249 geht jetzt alles durch den Tunnel und der Rest läuft durch den normalen LAN.

ich teste das gerade mal!


Nachtrag: es funktioniert alles so wie ich es möchte. Mit verfeinern der Rules werde ich mich die Tage beschäftigen.

Ich werde Morgen dazu eine Dokumentation machen, eventuell hilft das anderen.

Grüße und gn8

@mimugmail


schau mal :),

das ist doch wenn ich es richtig verstehe , genau das was ich machen möchte oder?

https://forum.opnsense.org/index.php?topic=10444.0

Da hattest Du sogar mitgewirkt.

 
Die beiden Default Rules setzte r ja nur wenn man den haken bei disable Route nicht setzt. Dann geht aber wieder alles darüber und wenn ein weiterer vpn zugang kommt, geht das Routing nicht.

Deswegen war meine Frage wie ich eine zweite rule auf 0.0.0.0 setzten kann.

es kommt dann ja später noch zb ein wg1 interface dazu, wenn ich jeweils den haken nicht setzte würde dann alles nicht mehr gehen, weil sie dann alle die default rule setzten wollen.

und noch die Firewall Rules:

 Habe jetzt mal alles auf Screenshots dokumentiert.


was mir auffält sind die deny Sachen der Firewal.

192.168.178.249:50169   185.33.223.203:443   tcp   Default deny rule

Müsste das dann nicht pass und force GW sein?

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.168.178.1      UGS         em0
127.0.0.1          link#3             UH          lo0
172.16.1.0/28      wg0                US          wg0
172.16.1.6         link#6             UH          wg0
192.168.178.0/24   link#1             U           em0
192.168.178.252    link#1             UHS         lo0

Internet6:
Destination                       Gateway                       Flags     Netif Expire
::1                               link#3                        UH          lo0
fe80::%em0/64                     link#1                        U           em0
fe80::20c:29ff:fec3:7f5d%em0      link#1                        UHS         lo0
fe80::%lo0/64                     link#3                        U           lo0
fe80::1%lo0                       link#3                        UHS         lo0

  Ping ich vom Client die 172.16.1.1 an kommt der reply:

  14:47:02.754293 IP 172.16.1.6 > 172.16.1.1: ICMP echo request, id 59199, seq 21, length 40
  14:47:02.779317 IP 172.16.1.1 > 172.16.1.6: ICMP echo reply, id 59199, seq 21, length 40


  Ping ich zb 8.8.8.8 an geht er nicht in den Tunnel sondern über das normale Interface:

    14:49:50.973632 IP (tos 0x0, ttl 127, id 48911, offset 0, flags [none], proto ICMP (1), length 60)
    192.168.178.249 > 8.8.8.8: ICMP echo request, id 1, seq 32, length 40
    14:49:50.998196 IP (tos 0x0, ttl 52, id 0, offset 0, flags [none], proto ICMP (1), length 60)
    8.8.8.8 > 192.168.178.249: ICMP echo reply, id 1, seq 32, length 40


 

Das sind die Route wenn beim wg interface disable drin ist damit er nicht die default überschreibt:

default            192.168.178.1      UGS         em0
localhost          link#3                   UH          lo0
172.16.1.6       link#6                   UH          wg0
192.168.178.0/24   link#1             U           em0
r1                         link#1             UHS         lo0


Die Regel auf der WAN (habe ja kein LAN) Schnittstelle habe ich dann so gesetzt:

IPv4 *   192.168.178.249   *   *   *   WireCloud_DHCP

Ich muss doch noch eine Route für das wg setzten oder verstehe ich das falsch?

Beim Test hatte ich :

172.16.1.0/28      wg0                US          wg0 gesetzt

und mal eine feste ip nach draußen, die gingen dann auch durch den Tunnel.