squid negotiating ssl error 1416F086 bei transparentem Proxy

m6m6r6

Member
Hi,
ich versuche privat einen transparenten Proxy aufzusetzen zum Beispiel unerwünschte Seiten oder Links zu blocken. Fürs Erste habe ich mich an folgender Anleitung orientiert: https://obsigna.com/articles/1563917142.html. Squid habe ich aus den Ports und auch schon per pkg install squid installiert. Die rc.conf habe ich um den gateway_enable="YES" ergänzt um die IP-Weiterleitung zu ermöglichen.
Nach Anpassung der Konfiguration und dem Starten von Squid lief der http-Verkehr einwandfrei. Allerdings als https-Seiten aufgerufen werden lässt squid den kompletten Speicher volllaufen und die Log-Dateien füllen sich auch. In der cache.log steht:

...
2021/04/20 06:35:38 kid1| ERROR: negotiating TLS on FD 294287: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (1/-1/0)
2021/04/20 06:35:38 kid1| ERROR: negotiating TLS on FD 294295: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (1/-1/0)
2021/04/20 06:35:38 kid1| Error negotiating SSL connection on FD 294300: error:00000001:lib(0):func(0):reason(1) (1/-1)
2021/04/20 06:35:38 kid1| Error negotiating SSL connection on FD 294308: error:00000001:lib(0):func(0):reason(1) (1/-1)
2021/04/20 06:35:39 kid1| ERROR: negotiating TLS on FD 294271: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (1/-1/0)
2021/04/20 06:35:39 kid1| ERROR: negotiating TLS on FD 294279: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (1/-1/0)
...

Auszug aus der squid.conf

acl manager proto cache_object
acl localnet src 192.168.2.0/24
acl port_443 port 443
acl ports_80_443 port 80 443
acl CONNECT method CONNECT

http_access allow localhost manager
http_access deny manager
http_access deny !ports_80_443
http_access deny CONNECT !port_443
http_access deny to_localhost
http_access allow localnet
http_access deny all

http_port localhost:3127
http_port 192.168.2.209:3127
http_port 127.0.0.1:3128 intercept
https_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on cert=/usr/local/etc/squid/proxy-certs/proxy-ca.pem tls-dh=/usr/local/etc/squid/proxy-certs/dhparam.pem

acl step1 at_step SslBump1

ssl_bump peek step1
ssl_bump bump port_443

sslcrtd_program /usr/local/libexec/squid/security_file_certgen -s /usr/local/etc/squid/dyn-certs -M 4MB
sslcrtd_children 4 startup=1 idle=1

refresh_pattern -i (/cgi-bin/|\?|\|.*\|) 0 0% 0
refresh_pattern . 0 20% 4320

tls_outgoing_options cipher=HIGH:!aNULL:!AES128:!SSLv2:!SSLv3:!TLSv1
tls_outgoing_options cafile=/etc/ssl/cert.pem
tls_outgoing_options options=NO_SSLv3

visible_hostname proxy06.local
Die Zertifikate wurden so erzeugt:
openssl req -new -newkey rsa:2048 -sha256 -days 8766 -nodes -x509 -extensions v3_ca -keyout proxy-ca.pem -out proxy-ca.pem
und
openssl dhparam -out dhparam.pem -2 2048

Das System ist auf dem Stand FreeBSD 12.2-RELEASE-p6, squid 4.14, alle Updates installiert.

Das Problem tritt nicht auf wenn der Eintrag unter http(s)_port intercept entfernt wird.


Michael
 
Die rc.conf habe ich um den gateway_enable="YES" ergänzt um die IP-Weiterleitung zu ermöglichen.
Eigentlich brauchst Du das nicht. Weil das ist kein IP-Forwarding. Für den Client ist der Proxy der Endpunkt. Der wiederum baut eine neue Verbindung auf zum angesprochenen (Web)Server.

zum Beispiel unerwünschte Seiten oder Links zu blocken.
Ich kann zwar jetzt ad-hoc nix zu Deinem Problem sagen, aber:
Wenns darum geht ganze Domains zu blocken, könnte ein DNS-basierter Ansatz deutlich einfacher sein.
Generell ist es immer ein wenig heikel TLS-Verbindungen aufzumachen.
 
Leider ist mir Dein Problem nie begegnet, ich betreibe zwar einen Squid Proxy mit TLS Interception, aber nicht im transparenten Modus. So vom hingucken sagt mir das nur, dass Dein Proxy die Serverzertifikate nicht validieren kann, aber das siehst Du ja wahrscheinlich selbst, und warum das so ist, keine Ahnung... Ist ein komplexes Thema, und ich bin froh, dass es funktioniert. :cool:

Aber mal zum Verständnis, einen transparenten Proxy verwendet man doch, um auf den Clients keine Konfiguration vornehmen zu müssen. Wenn Du TLS Interception machst, musst Du auf den Clients aber eh Deine CA installieren, dann kannst Du doch auch den Proxy selbst auf den Clients einstellen und auf den transparenten Modus verzichten?
 
Hi,
ich versuche privat einen transparenten Proxy aufzusetzen zum Beispiel unerwünschte Seiten oder Links zu blocken. Fürs Erste habe ich mich an folgender Anleitung orientiert: https://obsigna.com/articles/1563917142.html. Squid habe ich aus den Ports und auch schon per pkg install squid installiert. Die rc.conf habe ich um den gateway_enable="YES" ergänzt um die IP-Weiterleitung zu ermöglichen.
Nach Anpassung der Konfiguration und dem Starten von Squid lief der http-Verkehr einwandfrei. Allerdings als https-Seiten aufgerufen werden lässt squid den kompletten Speicher volllaufen und die Log-Dateien füllen sich auch. In der cache.log steht:



Auszug aus der squid.conf


Die Zertifikate wurden so erzeugt:

und


Das System ist auf dem Stand FreeBSD 12.2-RELEASE-p6, squid 4.14, alle Updates installiert.

Das Problem tritt nicht auf wenn der Eintrag unter http(s)_port intercept entfernt wird.


Michael
Ist ca_root_nss installiert?

Zum gateway_enable=YES. Wenn die Clients nur über Proxies ins Netz gehen, ist es sogar von Vorteil, das auf NO zu setzen, da sie so keine Verbindung zum Internet aufbauen können. Das ist selten möglich, aber soweit zur Theorie.
 
Danke für die Tips.
Datum und Uhrzeit der Maschine sind korrekt, entsprechen dem Client Rechnern. Ich habe das selbsterzeugte Zertifikat (proxy-ca.pem) auf dem Client installiert und als vertrauenswürdig markiert. ca_root_nss war nicht installiert, ich habe es nachträglich installiert. Leider hat es keine Änderung gebracht. Der Speicher läuft weiterhin voll.

squid_error.jpg


Der Proxy muss nicht im "transparent" sein, ich kann den Proxy auch im Client manuell eintragen. Ich möchte nur URLs (https://www.example.com/dieseurlblockieren) filtern.
 
Kannst Du mal versuchen, mit openssl als Client eine TLS-Verbindung zu einem https-Server auszubauen?
Da vielleicht auch mal mit der TLS Version rumspielen?
Mich irritieren die Meldungen ala:
Code:
Error negotiating SSL connection on FD ...
Error: negotiating TLS on ...
 
So, ich habe mal ein bisschen rumexperimentiert und glaube das Problem konnte eingegrenzt werden konnte. Es scheint an Ich habe ein neues Zertifikat mit
openssl x509 -in proxy-ca.pem -outform PEM -out mySquidCA.crt
erzeugt.

Eine Verbindung vom Proxyserver zu heise.de (openssl s_client -connect heise.de:443) gab folgende Ausgabe:

---
SSL handshake has read 3099 bytes and written 405 bytes
Verification: OK
---
---
SSL handshake has read 3099 bytes and written 405 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2


Eine Verbindung vom Proxyserver zu heise.de (openssl s_client -connect heise.de:443 -CAfile mySquidCA.crt) gab folgende Ausgabe:

---
SSL handshake has read 3099 bytes and written 405 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2


Eine Verbindung vom Proxyserver zu heise.de (openssl s_client -connect heise.de:443 -CAfile mySquidCA.crt -ssl3) gab folgende Ausgabe:
---
SSL handshake has read 7 bytes and written 58 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : SSLv3
Kann es am Zertifikat liegen?
 
Ich bin nicht der openssl Spezi, aber ich würde meinen -CAfile ist das Zertifikat, mit dem Du das Server-Zertifikat prüfst. Da müsstest Du das CA-Zertifkat nehmen, mit dem das heise.de Zertifikat unterzeichnet wurde. Wenn Du den Schalter weg lässt, klappt die Überprüfung ja.
 
Kann es am Zertifikat liegen?
Die letzten beiden s_client-Aufrufe unterscheiden sich nur durch "-ssl3". Der erste klappt, der zweite (mit -ssl3) klappt nicht.
Also liegt es nicht am Zertifikat, sondern an ssl3. SSLv3 wird nicht mehr unterstützt!

Ebenso CAfile: dieser Parameter ist hier irrelevant, das siehst du daran, dass es keinen Unterschied bei der Ausgabe der beiden ersten Kommandos gibt.

Du musst weitersuchen, ich empfehle grundsätzlich erstmal einen minimalen Testfall:
Eine konkrete URL auf dem Client hinter dem Proxy aufrufen, dann auf dem Proxy den Fehler extrahieren, mit maximalem Loglevel.

Rob
 
Ich habe die squid.conf um den Parameter debug_options all ergänzt.

Beim Aufruf von curl -v https://www.meer.de/ -o index.html bekomme ich folgendes angezeigt:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 212.162.15.211:443...
  • TCP_NODELAY set
  • Connected to www.meer.de (212.162.15.211) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
0 0 0 0 0 0 0 0 --:--:-- 0:00:11 --:--:-- 0^C

Wenn ich den Proxy nicht als Gateway nutze und
https_port 127.0.0.1:3129 intercept ssl-bump generate-host-certificates=on cert=/usr/local/etc/squid/proxy-certs/proxy-ca.pem tls-dh=/usr/local/etc/squid/proxy-certs/mySquidCA.crt
durch
http_port 3130 ssl-bump generate-host-certificates=on cert=/usr/local/etc/squid/proxy-certs/proxy-ca.pem tls-dh=/usr/local/etc/squid/proxy-certs/mySquidCA.pem
ersetze halte ich bei Aufruf von curl -v -x 192.168.2.209:3130 https://www.meer.de/ -o index.html folgende Ausgabe:
Trying 192.168.2.209:3130...
* TCP_NODELAY set
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 192.168.2.209 (192.168.2.209) port 3130 (#0)
CONNECT www.meer.de:443 HTTP/1.1
Host: www.meer.de:443
User-Agent: curl/7.68.0
Proxy-Connection: Keep-Alive
< HTTP/1.1 200 Connection established
<
  • Proxy replied 200 to CONNECT request
  • CONNECT phase completed!
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
  • CONNECT phase completed!
  • CONNECT phase completed!
0 0 0 0 0 0 0 0 --:--:-- 0:00:10 --:--:-- 0* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.meer.de:443
0 0 0 0 0 0 0 0 --:--:-- 0:00:10 --:--:-- 0
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.meer.de:443

Ich habe nach kurzer Zeit curl abgebrochen, da squid wieder den Speicher volllaufen ließ.

In der access.log stehen viele dieser Einträge:
....
1619198745.365 707 192.168.2.209 NONE/200 0 CONNECT 212.162.15.211:443 - ORIGINAL_DST/212.162.15.211 -
1619198745.369 711 192.168.2.209 NONE/200 0 CONNECT 212.162.15.211:443 - ORIGINAL_DST/212.162.15.211 -
1619198745.369 711 192.168.2.209 NONE/200 0 CONNECT 212.162.15.211:443 - ORIGINAL_DST/212.162.15.211 -
Ich habe das Gefühl das die Verbindung ohne "intercept" ein Stück weiter aufgebaut werden kann.
 
Danke für die Tips.
Datum und Uhrzeit der Maschine sind korrekt, entsprechen dem Client Rechnern. Ich habe das selbsterzeugte Zertifikat (proxy-ca.pem) auf dem Client installiert und als vertrauenswürdig markiert. ca_root_nss war nicht installiert, ich habe es nachträglich installiert. Leider hat es keine Änderung gebracht. Der Speicher läuft weiterhin voll.

Anhang anzeigen 4279

Der Proxy muss nicht im "transparent" sein, ich kann den Proxy auch im Client manuell eintragen. Ich möchte nur URLs (https://www.example.com/dieseurlblockieren) filtern.
Dem Screenshot zufolge hast Du den Server nach der Installation von security/ca_root_nss nicht neu gestartet. ca_root_nss muß in der Tat installiert sein, und das steht auch so in der von Dir verlinkten Anleitung (die übrigens von mir ist).

Bildschirmfoto 2021-04-23 um 17.30.51.png


Bitte einfach einmal neu starten, und nochmal versuchen.

Ausserdem ist die CONNECT-Methode beim transparenten Proxy falsch. Hast Du Dein Squid als Proxy bei den Client-Computern eingetragen? Das kann man machen, aber dann müßte das eigentlich nach ca_root_nss und Neustart funktionieren.

Wenn Du tatsächlich einen transparenten Proxy betreiben willst, dann überprüfe einmal genau, ob die Einrichtung des Squid-Cert-Daemons vollständig gelungen ist, und zwar mit besonderem Augenmerk auf die Zugriffsberechtigungen:

Auf meinem Server funktioniert Squid exakt so wie in der Anleitung beschrieben:
Bildschirmfoto 2021-04-23 um 17.55.10.png


Wenn Du aber sowieso nur bestimmte Domains blockieren willst, dann ist Squid die Kanonenkugel mit der Du Spatzen (Domains) abzuschießen gedenkst. Dafür sind eigentlich meine void-zones-tools besser geeignet:
 
Deine Anleitung hat mir beim Einrichten geholfen, andere Anleitungen waren nicht so verständlich.
Ich habe die Tage nochmal eine VM (FreeBSD 12.2) aufgesetzt und mich Schritt für Schritt an deine Anleitung gehalten. Bei der squid.conf habe ich folgende Parameter engepasst, da der Proxyserver sonst eine Verbindung ablehnte:

http_port 3127
http_port 3127
http_port 3128 intercept
https_port 3129 intercept ssl-bump generate-host-certificates=on cert=/usr/local/etc/squid/proxy-certs/proxy-ca.pem tls-dh=/usr/local/etc/squid/proxy-certs/dhparam.pem
Anschliessend habe ich die neuen Zertifikate beim client (Lubuntu 20.04) per sudo dpkg-reconfigure ca-certificates importiert. Der Proxyserver wurde nicht als Gateway konfiguriert.
Zum Testen habe ich dann per curl eine Verbinsung aufgebaut:

curl -x 192.168.2.35:3127 https://www.heise.de -I
HTTP/2 200
server: nginx
date: Tue, 27 Apr 2021 08:24:08 GMT
content-type: text/html; charset=UTF-8
last-modified: Tue, 27 Apr 2021 08:24:08 GMT
age: 28
strict-transport-security: max-age=15768000
x-frame-options: DENY
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
vary: X-Export-Format, X-Export-Agent, Accept-Encoding
cache-control: no-store
accept-ranges: bytes
content-length: 679662
curl -x 192.168.2.35:3128 https://www.heise.de -I
HTTP/1.1 409 Conflict
Server: squid/4.14
Mime-Version: 1.0
Date: Tue, 27 Apr 2021 08:25:22 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 3741
X-Squid-Error: ERR_CONFLICT_HOST 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from fbproxy02.local
Via: 1.1 fbproxy02.local (squid/4.14)
Connection: keep-alive
curl -x 192.168.2.35:3129 https://www.heise.de -I
curl: (56) Proxy CONNECT aborted
Im cache.log steht folgendes:
2021/04/27 10:27:32 kid1| SECURITY ALERT: Host header forgery detected on local=192.168.2.35:3128 remote=192.168.2.106:37598 FD 21 flags=33 (intercepted port does not match 443)
2021/04/27 10:27:32 kid1| SECURITY ALERT: By user agent: curl/7.68.0
2021/04/27 10:27:32 kid1| SECURITY ALERT: on URL: www.heise.de:443
2021/04/27 10:27:32 kid1| kick abandoning local=192.168.2.35:3128 remote=192.168.2.106:37598 FD 21 flags=33
Unter access.log steht:
1619512050.486 72 192.168.2.106 TCP_TUNNEL/200 4059 CONNECT www.heise.de:443 - HIER_DIRECT/193.99.144.85 -
1619512052.190 0 192.168.2.106 NONE/409 4083 CONNECT www.heise.de:443 - HIER_NONE/- text/html
1619512054.991 0 192.168.2.106 TCP_DENIED_ABORTED/200 0 CONNECT 192.168.2.35:3129 - HIER_NONE/- -

Einen DNS-Filter habe ich bereits im Einsatz (PiHole und unbound). Mit squid beschäftige ich mich damit ich betimmte Links blocken kann bzw. wenn ich unterwegs bin die Möglichkeit habe durch Cachen von Webseiten auf meinem mobilen Hotspot den Datenverbrauch zu reduzieren.
Squid braucht dafür nicht unbedingt transparent zu arbeiten, wenn ich squid bei den Clients eintragen muss ist es kein Problem.
 
Mit der -x-Option funktioniert das bei mir so (natürlich) auch nicht. Dafür ist ein transparenter Proxy auch gar nicht gedacht. Der soll einfach so seinen Dienst im Hintergrund ganz unsichtbar (transparent halt) verrichten:

Mit Proxy:
curl https://www.heise.de -I
Code:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 27 Apr 2021 21:23:06 GMT
Content-Type: text/html; charset=UTF-8
Last-Modified: Tue, 27 Apr 2021 21:23:06 GMT
Age: 3
Strict-Transport-Security: max-age=15768000
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Vary: X-Export-Format, X-Export-Agent, Accept-Encoding
Cache-Control: no-store
Accept-Ranges: bytes
Content-Length: 678922
X-Cache: MISS from server.obsigna.com
Via: 1.1 server.obsigna.com (squid/4.14)
Connection: keep-alive

Ohne Proxy:
curl https://www.heise.de -I
Code:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 27 Apr 2021 21:32:49 GMT
Content-Type: text/html; charset=UTF-8
Last-Modified: Tue, 27 Apr 2021 21:32:49 GMT
Age: 24
Strict-Transport-Security: max-age=15768000
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Vary: X-Export-Format, X-Export-Agent, Accept-Encoding
Cache-Control: no-store
Accept-Ranges: bytes
Content-Length: 679144
Connection: keep-alive

Zwischen mit und ohne Proxy schalte ich um, indem ich die IP-Adresse des Clients ändere. Denn in der Firewall des Gateways steht:
Code:
# Transparent HTTP(S) Proxy - Squid
/sbin/ipfw -q add 80 fwd 127.0.0.1,3128 tcp from 192.168.0.3,192.168.0.7,192.168.0.8,192.168.0.9,192.168.0.15 to not me 80
/sbin/ipfw -q add 81 fwd 127.0.0.1,3129 tcp from 192.168.0.3,192.168.0.7,192.168.0.8,192.168.0.9,192.168.0.15 to not me 443

Das bedeutet bei allen Clients deren IP in den fwd-Firewall-Regeln gelistet sind geht der 80/443-Traffic über den Proxy, bei allen anderen nicht.
 
So, nun läuft es endlich. Wenn ich das ganze Netzwerk angebe:

ipfw -q add 80 fwd 127.0.0.1,3128 tcp from 192.168.2.0/24 to not me 80
ipfw -q add 81 fwd 127.0.0.1,3129 tcp from 192.168.2.0/24 to not me 443
lässt squid den Speicher volllaufen. Bei Eingabe von einzelnen IP-Adressen tritt das Problem nicht auf:
z.B.
ipfw -q add 80 fwd 127.0.0.1,3128 tcp from 192.168.2.2, 192.168.2.3 to not me 80
ipfw -q add 81 fwd 127.0.0.1,3129 tcp from 192.168.2.2, 192.168.2.3 to not me 443
Aber ich werde es ähnlich wie du machen das ich nur die Clients eintrage die den Proxy nutzen sollen. Deine Tipps haben mir geholfen das Problem zu lösen, danke schön dafür.
 
Ich denke ich habe das Problem gefunden. Das Problem tritt auf wenn ich den Adressbereich 192.168.2.0/24 angebe. Der Proxy hat die Adresse 192.168.2.35. Wenn ich stattdessen 192.168.2.64/27 bei ipfw angebe und die Clients diesen Bereich nutzen lasse läuft Squid (nun seit einigen Stunden) stabil.
Kann es daran liegen das der Proxy im Adressbereich 192.168.2.0/24 liegt und ein "Loop" erzeugt?
 
Ähm wenn ich das richtig verstehe schickst du den ausgehenden Traffic des Proxys mit der Config direkt wieder zum Proxy zurück?
 
Kann es daran liegen das der Proxy im Adressbereich 192.168.2.0/24 liegt und ein "Loop" erzeugt?
Könnte gut sein
Auf jeden Fall würde ich da Deine IPFW-Konfiguration als potentiell problematisch einschätzen.
Ich würde also vorher gucken, ob das "from me" kommt und dann mit einem skipto die entsprechenden Regeln überspringen.

Also in etwa so:
Code:
ipfw -q add 79 skipto 82 tcp from me to not me 80,443
ipfw -q add 80 fwd 127.0.0.1,3128 tcp from 192.168.2.0/24 to not me 80
ipfw -q add 81 fwd 127.0.0.1,3129 tcp from 192.168.2.0/24 to not me 443

Für Details, siehe Manpage: ipfw(8)
Für Fragen: Direkt wieder hier im Forum :-)
 
Zuletzt bearbeitet:
Ja, ich war mir auch nicht 100% sicher mit der ipfw Konfiguration. Der Tipp mit skipto hat geklappt. Der Proxy läuft nun stabil und mit mehreren Clients. Ich denke sinnvoller den Proxy aus dem Client-Netz (192.168.2.0/24) zu nehmen oder nur ein Teilnetz zu nehmen, dann könnte ich mir die skipto-Regel sparen.
Mit ipfw werd ich mich intensiver einlesen.

Danke für die Hilfe, es ist echt klasse die Unterstützung hier Forum!
 
Das mit dem skipto war ja auch nur ein Beispiel. Ich weiß ja nicht, wie Deine sonstigen Firewall-Regeln aussehen.
Möglicherweise hast Du auch noch Regeln, die sich explizit um me kümmern.
Aber wenn insbesondere wenn nach Deinen o.g. Forward-Regeln nix mehr kommt was für me relevant ist, kann man auch einfach ein
ipfw -q add 79 allow tcp from me to not me 80,443
machen.
Ein allow führt halt dazu das das Paket akzeptiert wird und weitere Regeln nicht mehr abgearbeitet werden (wie auch deny und fwd "terminierend" sind).
 
Weitere Firewall-Regeln habe ich nicht erstellt. Alles weitere regelt (noch?) die fritzbox. Es ist auf jedenfall ein interesanntes Thema mit dem ich mich näher beschäftigen werde.
 
Zurück
Oben