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.

Messages - tblum

Pages: [1] 2

German - Deutsch / Re: IPSec VTI Routing Problem

« on: August 22, 2024, 02:12:51 pm »

Übrigens, ich habe eine "Lösung" gefunden: https://forum.opnsense.org/index.php?topic=38137.msg186778#msg186778
Da scheint es bei der Opnsene noch Nachbesserungsbedarf zu geben. Wenn ich die deaktivierte Route lösche, funktioniert die verbleibende. Kann ich mit leben, muss ich die Route halt bei Bedarf umstellen, aber mir erschließt sich dann nicht der Sinn des "Deaktivieren"-Häkchens. Zumal ich das schon die ganze Zeit als inkonsistent empfunden habe: an den meisten Stellen bedeutet ein Häkchen "aktiv" und hier "inaktiv".

23.7 Legacy Series / Re: Error(?) by adding/disabling of static routes from WebUI

« on: August 22, 2024, 02:09:46 pm »

I can confirm this behavior on 24.4.2 with non-default route. I had two routes to the same target over different gateways, one active (at least that's what I intended), one deactivated. The active route never showed up until I deleted the deactivated one. To be honest, I consider this as a bug, why do we have the option to deactivate a static route if not in this use case?

German - Deutsch / Re: IPSec VTI Routing Problem

« on: August 22, 2024, 12:12:15 pm »

Alles klar, aber danke, dass Ihr reingeguckt habt!

German - Deutsch / Re: IPSec VTI Routing Problem

« on: August 20, 2024, 04:33:21 pm »

Nur um sicher zu gehen: ist meine Frage zu doof oder weiß niemand was?

German - Deutsch / Re: Nach fehlgeschlagenem Upgrade kein Update mehr möglich

« on: August 19, 2024, 11:40:41 am »

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

Und notfalls: hast Du Backups von der Config? Dann bliebe im größten Notfall ja die Neuinstallation. Aber vorher würde ich in der Console die 13 probieren.

German - Deutsch / Re: The HTTP_REFERER "http://192.168.1.20:81/" does not match the predefined setting

« on: August 19, 2024, 11:32:26 am »

Nur so ein Schuss ins Blaue, aber ich denke, Du musst den Port für's Webinterface Deiner Opnsense umstellen, wenn Du sie als Reverseproxy benutzen willst. Sonst machst Du ne Anfrage an 192.168.1.20:443 und das wird dann vom Webinterface bedient. Du willst aber ja, dass das vom nginx bedient wird.

German - Deutsch / Re: IPSec VTI Routing Problem

« on: August 19, 2024, 09:40:26 am »

Übrigens, bevor ich die 192.168.30.1 bzw. 192.168.40.1 in die Konfigurationen der Gateways eingetragen hatte (ich hatte ich das Feld IP Address zunächst leer gelassen), hatte ich folgendes unter "System -> Log Files -> General": ROUTING: not a valid ipsec40 interface gateway address: 'missing'.

German - Deutsch / IPSec VTI Routing Problem

« on: August 19, 2024, 09:37:43 am »

Hi,
ich hab ne Frage zur Konfiguration eines VTI IPSec. Ich habe unter "VPN -> IPSec -> Virtual Tunnel Interfaces" zwei Interfaces angelegt:
1: Reqid: 30, Local address: <WAN1-IP>, Remote address: <Partner-IP>, Tunnel local address: 192.168.30.1 (willkürlich ausgewählt), Tunnel remote address: 192.168.30.2.
2: Reqid: 40, Local address: <WAN2-IP>, Remote address: <Partner-IP>, Tunnel local address: 192.168.40.1 (willkürlich ausgewählt), Tunnel remote address: 192.168.40.2

Also zwei VTIs zur gleichen Gegenstelle, je eine pro WAN-Interface, es werden auch beide Interfaces angelegt.

Unter "System -> Gateways -> Configuration" habe ich zwei Einträge hinzugefügt, bei denen ich jeweils das VTI ausgewählt habe und als IP Adresse habe ich die 192.168.30.1 bzw die 192.168.40.1 eingetragen. Ansonsten ist noch "Disable Gateway Monitoring" angehakt, sonst nichts.
Ich habe unter "System -> Routes -> Configuration" zwei Einträge hinzugefügt: für das Netz, das ich hinter dem Tunnel erreichen will, nennen wir es 10.10.0.0/24 und als Gateway jeweils eines der beiden angelegten. Eine dieser Routen hat immer den Haken bei "Deaktiviert".

Was ich erreichen möchte, ist, dass ich den Tunnel zur Gegenstelle über eines der beiden WAN-Interfaces aufbauen kann. Außerdem möchte ich in der Lage sein, den Tunnel abzubauen und über das andere WAN-Interface wieder aufzubauen. Der Tunnel kommt auch jeweils zustande, aber mit den Routen habe ich ein Problem. Ich bekomme unter "System -> Routes -> Status" keine Route nach 10.10.0.0/24 angezeigt. Und auch ein "route get 10.10.0.100" zeigt mir, dass die über das Defaultgateway geroutet werden.

Ich habe in den Firewall-Regeln für das LAN-Interface zwei Allow-Regeln mit jeweils einem der beiden angelegten Gateways unter "Gateway", von denen jeweils nur eine (ja, die richtige) aktiviert ist. Eigentlich müsste damit ja der Eintrag unter "System -> Routes" obsolet sein, aber ich würde auf jeden Fall erwarten, dass "route get" mir "ipsec30" bzw. "ipsec40" anzeigt. Ein Ping geht natürlich auch nicht durch. Wo liegt mein Fehler?

German - Deutsch / Re: IPSec Failover - Grundsatzfrage zum Verständnis

« on: August 14, 2024, 12:22:26 pm »

Danke, Patrick, das bestätigt in etwas das, was sich mir so erschließt. Schade, dass das nicht irgendwo deutlicher dokumentiert ist, das hätte mir einiges an Zeit erspart. Dann versuche ich mein Glück mal mit einem VTI-Tunnel.

German - Deutsch / [Solved]: IPSec Failover - Grundsatzfrage zum Verständnis

« on: August 12, 2024, 09:40:54 am »

Moin!
Ich schlage mich mittlerweile seit Wochen mit der Einrichtung einer IPSec-Vebindung herum, die den Ausfall eines Providers verkraften würde. Mein Szenario ist auf Seite A eine opnsense im Dual-WAN-Betrieb, am WAN-Interface eine Kabel-Fritzbox, am pppoe0-Interface ein Vigor-130-VDSL-Modem. Auf Seite B eine Opnsense auf einem gehosteten Server mit fixer IP. Für die beiden IP-Adressen auf Seite A habe ich einen dynDNS-Eintrag, den ich auf eine der beiden IPs legen kann. Ich bekomme die Verbindung gut hin, aber wenn ich den dynDNS-Eintrag "umschalte", dann will die Verbindung nicht wieder zustande kommen. Wenn ich das Forum hier durchsuche, bin ich wohl auch nicht der Einzige mit diesem Problem, allerdings gibt es auf die Fragen dazu bisher keine Antworten. Alles, was ich bisher im Internet dazu finden konnte in Anleitungen für andere Firewall-Systeme, waren Lösungen mit VTI-IPSecs. Deswegen nun erstmal meine grundsätzliche Frage: Funktioniert ein Failover für IPSec-Verbindungen über verschiedene Provider generell nur mit VTI-IPSecs? Oder sollte das prinzipiell auch über policy based IPSecs gehen und ich bin nur zu doof?
Falls ersteres der Fall ist, wäre ich sehr dankbar, wenn mir jemand erklären könnte, warum das so ist. Falls letzteres zutrifft, würde ich mehr Informationen zu meiner Konfiguration liefern und wäre sehr froh, wenn mir jemand den Fehler aufzeigen könnte.

Web Proxy Filtering and Caching / Re: Nginx: combine Advanced ACL and IP ACL

« on: November 29, 2023, 07:03:45 am »

Hi, thank you for your reply and sorry for my late reaction, I was out of office for some days and forgot it, then.
So, I don't think that there are includes that are responsible for the behaviour, but maybe, I am missing something, perhaps, you can have a look, too:

Code: [Select]

 # cat /usr/local/etc/nginx/nginx.conf

load_module /usr/local/libexec/nginx/ngx_stream_module.so;
load_module /usr/local/libexec/nginx/ngx_http_naxsi_module.so;
load_module /usr/local/libexec/nginx/ngx_mail_module.so;
load_module /usr/local/libexec/nginx/ngx_http_brotli_filter_module.so;
load_module /usr/local/libexec/nginx/ngx_http_brotli_static_module.so;
load_module /usr/local/libexec/nginx/ngx_http_js_module.so;
load_module /usr/local/libexec/nginx/ngx_http_vhost_traffic_status_module.so;

user www staff;
worker_processes 1;

#error_log  /var/log/nginx/error.log;
error_log  syslog:server=unix:/var/run/log,facility=local6,nohostname warn;

events {
    worker_connections  1024;
}

http {
include       mime.types;



log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';
log_format  main_ext  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" '
                      '"$host" sn="$server_name" '
                      'rt=$request_time '
                      'ua="$upstream_addr" us="$upstream_status" '
                      'ut="$upstream_response_time" ul="$upstream_response_length" '
                      'cs=$upstream_cache_status';
log_format  handshake   '"$http_user_agent" "$ssl_ciphers" "$ssl_curves"';
log_format  anonymized  ':: - $remote_user [$time_local] "$request" '
                  '$status $body_bytes_sent "$http_referer" '
                  '"$http_user_agent" "$http_x_forwarded_for"';

#tcp_nopush     on;
# https intercept detection
js_import /usr/local/opnsense/scripts/nginx/ngx_functions.js;
js_set $tls_intercepted ngx_functions.check_intercept;

# 200M should be big enough for file servers etc.
client_max_body_size 200M;
brotli_static on;
brotli on;
gzip_static on;
gzip on;
server_tokens off;
sendfile Off;
default_type  application/octet-stream;
keepalive_timeout 60;

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

# Map used in location.conf for proxy_ssl_name
map $ssl_server_name $upstream_sni_name {
    default $ssl_server_name;
    '' $host;
}

include http_post/*.conf;

# TODO add when core is ready for allowing nginx to serve the web interface
# include nginx_web.conf;




# UPSTREAM SERVERS
upstream upstream<crypticnumbersandlettersupstream1> {
server myfirstupstream.mydomain.de:8090 weight=1;

}
upstream upstream<crypticnumbersandlettersupstream2> {
server mysecondupstream.mydomain.de:8080 weight=1;

}


include opnsense_http_vhost_plugins/*.conf;

server {

    listen 80;
    listen [::]:80;

    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    ssl_certificate_key /usr/local/etc/nginx/key/opnsense.mydomain.de.key;
    ssl_certificate /usr/local/etc/nginx/key/opnsense.mydomain.de.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_dhparam /usr/local/opnsense/data/OPNsense/Nginx/dh-parameters.4096.rfc7919;
    ssl_ciphers ECDHE-ECDSA-CAMELLIA256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CAMELLIA256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CAMELLIA128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CAMELLIA128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-AES128-SHA256;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_prefer_server_ciphers on;
    ssl_stapling off;

    sendfile On;
    server_name  opnsense.mydomain.de;

    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;
    charset utf-8;
    access_log  /var/log/nginx/opnsense.mydomain.de.access.log main;
    access_log  /var/log/nginx/tls_handshake.log handshake;
    error_log  /var/log/nginx/opnsense.mydomain.de.error.log error;
    satisfy any;
    #include tls.conf;
    error_page 403 /opnsense_error_403.html;
    error_page 404 /opnsense_error_404.html;
    error_page 405 /waf_denied.html;
    error_page 500 501 502 503 504 /opnsense_server_error.html;

    location = /opnsense_error_403.html {
        internal;
        root /usr/local/etc/nginx/views;
    }
    location = /opnsense_error_404.html {
        internal;
        root /usr/local/etc/nginx/views;
    }
    location = /opnsense_server_error.html {
        internal;
        root /usr/local/etc/nginx/views;
    }
    # location to ban the host permanently
    set $naxsi_extensive_log 0;
    location @permanentban {
        access_log /var/log/nginx/permanentban.access.log main;
        internal;
        add_header "Content-Type" "text/plain; charset=UTF-8" always;
        return 403 "You got banned permanently from this server.";
    }
    error_page 418 = @permanentban;
    location = /waf_denied.html {
        root /usr/local/etc/nginx/views;
        access_log /var/log/nginx/waf_denied.access.log main;
    }
    # block based on User Agents - stuff I have found over the years in my server log
    if ($http_user_agent ~* Python-urllib|Nmap|python-requests|libwww-perl|MJ12bot|Jorgee|fasthttp|libwww|Telesphoreo|A6-Indexer|ltx71|okhttp|ZmEu|sqlmap|LMAO/2.0|l9explore|l9tcpid|Masscan|zgrab|Ronin/2.0|Hakai/2.0) {
      return 418;
    }
        if ($http_user_agent ~ "Indy\sLibrary|Morfeus Fucking Scanner|MSIE [0-6]\.\d+")
    {
      return 418;
    }
    if ($http_user_agent ~ ^Mozilla/[\d\.]+$)
    {
      return 418;
    }

    location = /opnsense-report-csp-violation {
      include       fastcgi_params;
      fastcgi_param QUERY_STRING $query_string;
      fastcgi_param SCRIPT_FILENAME /usr/local/opnsense/scripts/nginx/csp_report.php;
      fastcgi_param TLS-Cipher $ssl_cipher;
      fastcgi_param TLS-Protocol $ssl_protocol;
      fastcgi_param TLS-SNI-Host $ssl_server_name;
      fastcgi_param SERVER-UUID "<some-cryptic-numbers-and-letters>";
      fastcgi_intercept_errors on;
      fastcgi_pass  unix:/var/run/php-webgui.socket;
    }
    location /opnsense-auth-request {
      internal;
      fastcgi_pass  unix:/var/run/php-webgui.socket;
      fastcgi_index index.php;
      fastcgi_param TLS-Cipher $ssl_cipher;
      fastcgi_param TLS-Protocol $ssl_protocol;
      fastcgi_param TLS-SNI-Host $ssl_server_name;
      fastcgi_param Original-URI $request_uri;
      fastcgi_param Original-HOST $host;
      fastcgi_param SERVER-UUID "<some-cryptic-numbers-and-letters>";
      fastcgi_param SCRIPT_FILENAME  /usr/local/opnsense/scripts/nginx/ngx_auth.php;
      fastcgi_param AUTH_SERVER "LDAP";
      fastcgi_intercept_errors on;
      include        fastcgi_params;
    }
    if ($scheme != "https") {
        return 302 https://$host$request_uri;
    }
    include <some-cryptic-numbers-and-letters>_pre/*.conf;


location  /myupstream1 {
    BasicRule wl:19;
    DeniedUrl "/waf_denied.html";
        # IP ACL
        allow x1.y1.z1.0/24;
        allow x2.y2.0.0/16;
        allow x3.y3.z3.0/24;
        allow x4.y4.z4.0/24;
        allow x5.y5.z5.0/24;
        allow x6.y6.z6.154/32;
        allow x7.y7.z7.44/32;
        allow x8.y8.z8.0/24;
        deny all;
    satisfy any;
    autoindex off;
    auth_request /opnsense-auth-request;
    http2_push_preload on;
    proxy_set_header Host $host;
    proxy_http_version 1.1;
    proxy_set_header Authorization $http_authorization;
    proxy_pass_header Authorization;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header X-TLS-Cipher $ssl_cipher;
    proxy_set_header X-TLS-Protocol $ssl_protocol;
    proxy_set_header X-TLS-SNI-Host $ssl_server_name;
    # proxy headers for backend server
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-TLS-Client-Intercepted $tls_intercepted;
    proxy_read_timeout 86400s;
    proxy_ignore_client_abort off;
    proxy_request_buffering on;
    proxy_max_temp_file_size 1024m;
    proxy_buffering on;
    proxy_pass http://upstream<yetanotercrypticnumbersandletters>;
    proxy_hide_header X-Powered-By;
    include <some-cryptic-numbers-and-letters>_post/*.conf;
}
location  / {
    BasicRule wl:19;
    DeniedUrl "/waf_denied.html";
    if ($scheme != "https") {
        return 302 https://$host$request_uri;
    }
    root /srv/crm;
    index index.html;
    autoindex off;
    http2_push_preload off;
    include <some-more-cryptic-numbers-and-letters>_post/*.conf;
}
location  /myupstream2 {
    BasicRule wl:19;
    DeniedUrl "/waf_denied.html";
    autoindex off;
    http2_push_preload on;
    proxy_set_header Host $host;
    proxy_set_header X-TLS-Cipher $ssl_cipher;
    proxy_set_header X-TLS-Protocol $ssl_protocol;
    proxy_set_header X-TLS-SNI-Host $ssl_server_name;
    # proxy headers for backend server
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-TLS-Client-Intercepted $tls_intercepted;
    proxy_ignore_client_abort off;
    proxy_request_buffering on;
    proxy_max_temp_file_size 1024m;
    proxy_buffering on;
    proxy_pass http://upstream<stillmorecrypticnumbersandletters>;
    proxy_hide_header X-Powered-By;
    include <third-set-of-cryptic-numbers-and-letters-with-hyphen>_post/*.conf;
}
    include <some-cryptic-numbers-and-letters>_post/*.conf;

}

}
stream {
    # LOG FORMATS
    log_format main '$remote_addr [$time_local] '
                     '$protocol $status $bytes_sent $bytes_received '
                     '$session_time';
    log_format anonymized ':: [$time_local] '
                     '$protocol $status $bytes_sent $bytes_received '
                     '$session_time';

    # UPSTREAM SERVERS
    upstream upstream<crypticnumbersandlettersupstream1> {
        server myupstream1.mydomain.de:8090 weight=1;
    }
    upstream upstream<crypticnumbersandlettersupstream2> {
        server myupstream2.mydomain.de:8080 weight=1;
    }
    upstream upstream<crypticnumbersandlettersupstream3> {
        server w.x.y.z:443 weight=1;
    }

    # upstream maps


    include opnsense_stream_vhost_plugins/*.conf;

}
# mail {
# }

Web Proxy Filtering and Caching / Nginx: combine Advanced ACL and IP ACL

« on: November 10, 2023, 09:28:55 am »

Hi,
I'd like to configure nginx so that authentication against our LDAP will be nessecary only from outside our local networks. I have configures advanced ACL. It work, the user is prompted to login and nginx takes the LDAP credentials. I also configured IP ACL with default action set to "deny" and our IP-ranges to "allow". In the "HTTP-Server"-section of the nginx configuration, I have set the Advanced ACL Backend to LDAP and IP ACL to the configured one. "Satisfy" is configured as "any". In the "Location" I have set Advanced ACL and the IP ACL to the configured one and "Satisfy" to "any". Nevertheless, I have to enter my LDAP credentials, even when I'm connated to our local network. What am I missing?
Best regards
Thomas

23.7 Legacy Series / Re: Upgrade problem

« on: September 28, 2023, 10:42:02 am »

You're right, sorry for the confusion. I searched the forum for sudo-1.9.4... and did not read properly.

23.7 Legacy Series / Re: Upgrade problem

« on: September 27, 2023, 11:58:35 am »

Sorry, I've been too fast. This trick solved my problem:
https://forum.opnsense.org/index.php?topic=36155.msg176078#msg176078

23.7 Legacy Series / Re: Upgrade problem

« on: September 27, 2023, 11:54:48 am »

The same for me. Isn't there a solution? Of course, I did a pkg update -f, I even downloaded the package and put it in place - nothing changes. I remove all cached packages, I deleted the sudo-entry from the database - no success. Is there any possibility to solve this issue?

Pages: [1] 2