Messages

1

German - Deutsch / Re: Einzelne SSL Verbindungen bleiben hängen

« on: October 24, 2020, 07:34:00 pm »

Bin dem Problem auf die Schliche gekommen. Es scheint so, als ob die Packet-Hardwarebeschleunigung den Fehler verursacht. Der Fehler tritt nur auf wenn die Hardwarebeschleunigung aktiviert ist.

2

German - Deutsch / Re: OPNneuling....

« on: October 17, 2020, 01:05:58 am »

Die FritzBox blockt unbekannte Netze. D.h. Wenn du die FB aus einem anderen Subnetz erreichen willst, musst du das Netz in der FB unter IP-Routen eintragen.

3

German - Deutsch / Re: Einzelne SSL Verbindungen bleiben hängen

« on: October 17, 2020, 12:55:24 am »

Das wird nicht einfach. Ich würde auch gern NAT der Sense überlassen.
Wie gesagt die WAN IP ist eine Statische-Public-IP und ist in der FB als Exposed-Host angegeben. Da sollte doch die NAT in der FB deaktiviert sein.
Hab auch testweise Firewall und NAT in der Sense mit dem Parameter (Firewall deaktivieren) deaktiviert.

4

German - Deutsch / Re: Einzelne SSL Verbindungen bleiben hängen

« on: October 16, 2020, 09:58:05 pm »

Ja eine Fritz!Box 6591 .

An meinem Netzwerk ist eigentlich nichts spannendes.

OpnSense läuft als VM unter Proxmox.
Der Proxmox Server hat für WAN, LAN und WLAN separate Netzwerkkarten. WAN und WLAN werden nur für OpnSense verwendet, LAN wird mit dem Server und da drauf laufenden VMs geteilt.
Der WAN-Anschluß ist direkt mit der FB verbunen, der Anschluß in der FB unter Zugangsart-Portkonfiguration als Public-IP und Exposed-Host konfiguriert.
Der Fehler tritt sowohl auf einem Windows WLAN-Client als auch Linux VM unter Proxmox auf.
An Firewall-Rollen sollte es auch nicht liegen.

Die Andere OpnSense an denen ich getestet habe laufen auf eigener Hardware.

5

German - Deutsch / Einzelne SSL Verbindungen bleiben hängen

« on: October 16, 2020, 05:31:33 pm »

Hallo alle Zusammen,


hab schon vor längerem festgestellt, dass einzelne Verbindungen hängen bleiben. Das Problem ist relativ gut nachvollziehbar, nur leider scheint es nur in Verbindung von OpnSense und Vodafone-Kabel-Leitung aufzutreten. Eventuell hat es auch noch etwas mit der Statischen-Public-IP zutun. Das komische ist, dass die gleiche Verbindung mit anderem Client funktioniert.

Weiter unten ist ein kleiner Script in node-js, es versucht eigentlich nur ein Login auf xiaomi.com durchzuführen. Der Script bleibt aber immer im Request hängen. Andere node-js Bibliotheken funktionieren auch nicht. Genau die gleiche Aufrufe mit Curl oder Go liefern wie erwartet die Daten. Andere Seiten sind problemlos per node-js erreichbar. Wenn ich die Internetverbindung ohne OpnSense direkt mit der Fritz!Box herstelle funktioniert node-js auch problemlos. Andere Rechner (Linux + Wondows) verhalten sich genau so.
Hab den Script an zwei anderen Internetleitungen mit OpnSense getestet, an einer Leitung trat der Fehler ebenfalls auf, da wird auch Vodofone mit fester IP verwendet. An der zweiter Leitung wird Internet durch 1&1 bertgestellt, da gibt es kein probleme.

D.h. Problem tritt nur in Verbindung node-js + OpnSense + Vodafone-Internet und nur bei bestimmten Seiten.

Code: [Select]

var request = require('request');
var options = {
  'method': 'GET',
  'url': 'https://account.xiaomi.com/pass/serviceLogin?sid=xiaomiio&_json=true',
  'headers': {
    'Content-Type': 'application/x-www-form-urlencoded',
    'User-Agent': 'Android-7.1.1-1.0.0-ONEPLUS A3010-136-9D28921C354D7 APP/xiaomi.smarthome APPV/62830',
    'Cookie': 'sdkVersion=accountsdk-18.8.15; userId=abc@abc.de; deviceId=taivtx; pass_trace=GBZqboswliVT5OUf+T0IZilucW1hziEHBi3SbwmdMo6+q8nCtEbuhheXzmCuFImSx5FVVJNiAMgAbQ2qtM4BMA==; pass_ua=web; uLocale=de_DE; JSESSIONID=aaakeq0WViSAReR74QMux'
  }
};
request(options, function (error, response) {
  if (error) throw new Error(error);
  console.log(response.body);
});

     

6

German - Deutsch / Re: OPNsense braucht immer wieder einen Neustart

« on: June 27, 2017, 10:54:44 pm »

clog und nicht tail ist das Tool der Dinge

OK, dieses mal war der Fehler vor dem Bildschirm

Hab jetzt bei der zweiten OPN die feste IP für das WAN-Netz eingetragen und es hat tatsächlich einiges verbessert. Hatte zwar drauf noch einmal das Problem gehabt, dass eingehende Verbindungen nicht funktioniert haben. Da habe ich aber Verdacht, dass Die Fritzbox unberechtigterweise Fallback auf UMTS-Verbindung durchgeführt hat und das mobile Netz keine eingehenden Verbindungen erlaubt.

Wollte darauf hin auch bei der ersten OPN die IP fest eintragen (In dem Fall ist es von Unitymedia zugewiesene  statische IP), gestern Abend hatte auch scheinbar alles funktioniert. OPN neu gestartet - geht. Fritzbox neu gestartet - geht, heute Früh - geht nichts mehr (Internet aus dem LAN ging nicht, LAN über OVPN nicht erreichbar) . Auf die OPN kam ich aber über OVPN noch drauf, konnte die Einstellung rückgängig machen, der erste Neustart hat nichts gebracht, nach dem zweiten hat alles wieder funktioniert.
Dachte „war bestimmt ein Zufall, versuche ich heute Abend noch einmal“. Wieder feste IP eingetragen - schein zu funktionieren, erster Neustart - geht nur teilweise (LAN aus dem OVPN erreichbar, LAN to LAN zu der zweiten OPN aber nicht), zweiter Neustart - bin ausgesperrt.
Habe ähnliche Konfiguration (Unitymedia mit statischer IP und Fritzbox 6360) bei mir zuhause am laufen. OPNsense läuft als VM auf einer QNAP-Nas, die statische IP ist seit zweit Tagen auch fest eingetragen, habe aber keinerlei Probleme.

Sind es timing Probleme? Ist Jetway JBC390F541AA-19-B zu schnell für die OPNsense?
Wieso funktioniert es bei der zweiten mit der festen IP aber nicht mit der dynamischen, obwohl die dynamische scheinbar richtig zugewiesen wird?
Wieso kann ich feste IP von Unitymedia nicht in die erste OPN eintragen? Bei mir zuhause läuft es doch auch.
Wieso braucht die OPN mehrere Neustarts um die Einstellungen zu übernehmen?
Fragen über Fragen.

Eigentlich wollte ich den Thread ursprünglich „OPNsense will mich ärgern“ nennen ;-)

Ergänzung:
Ein Problem habe ich auf der Installation bei mir zuhause.
Wenn ich aus dem internen LAN mit der Dyndns-Adresse auf den internen Webserver zugreife, bekomme ich nach einiger Zeit folgende Meldung:
"Eine potentielle DNS-Rebind-Attacke wurde festgestellt. Versuchen Sie auf den Router mittels der IP-Adresse anstelle des Hostnamens zuzugreifen. "
Dagege hilft nur ein Neustart von dem Client.

7

German - Deutsch / Re: OPNsense braucht immer wieder einen Neustart

« on: June 25, 2017, 12:07:45 pm »

Hab die IP zwar immer noch nicht eingetragen, habe aber einen weiteren Fehler.

Um die Probleme mit der Zwangstrennung zu umgehen, führe ich an der zweiten OPN morgens um 6:15Uhr schon seit Tagen automatischen Neustart durch. Kurz nach dem gestrigen Neustart hört allerdings die Protokollierung in der /var/log/system.log auf. Über die Web-GUI kann ich unter System -> Protokolldatei die Logeinträge weiterhin sehen.
Sieht für mich so aus, als ob da irgendwelche Sonderzeichen mitprotokolliert wurden


Ausgabe mit tail

Code: [Select]

Jun 24 06:16:26 OPNsense kernel: ovpnc5: link state changed to UP
Jun 24 06:16:26 OPNsense configd.py: [f4d19b8c-9132-46bc-8a80-8f2560693961] rc.newwanip starting ovpnc5
Jun 24 06:16:27 OPNsense configd.py: generate template container OPNsense/Sample
Jun 24 06:16:28 OPNsense configd.py: generate template container OPNsense/Sample/sub1
Jun 24 06:16:28 OPNsensCLOGÔ¦ìÍroot@OPNsense:~ #
Ausgabe mit vi

Code: [Select]

Jun 24 06:16:26 OPNsense kernel: ovpnc5: link state changed to UP
Jun 24 06:16:26 OPNsense configd.py: [f4d19b8c-9132-46bc-8a80-8f2560693961] rc.newwanip starting ovpnc5
Jun 24 06:16:27 OPNsense configd.py: generate template container OPNsense/Sample
Jun 24 06:16:28 OPNsense configd.py: generate template container OPNsense/Sample/sub1
Jun 24 06:16:28 OPNsensCLOG^A^@^@^@\xd4\xa6^B^@\xec\xcd^G^@^@^@^@^@

Web-GUI

Code: [Select]

Jun 24 06:16:28 configd.py: generate template container OPNsense/WebGui
Jun 24 06:16:28 configd.py: generate template container OPNsense/Syslog
Jun 24 06:16:28 configd.py: generate template container OPNsense/Sample/sub2
Jun 24 06:16:28 configd.py: generate template container OPNsense/Sample/sub1
Jun 24 06:16:27 configd.py: generate template container OPNsense/Sample
Jun 24 06:16:26 configd.py: [f4d19b8c-9132-46bc-8a80-8f2560693961] rc.newwanip starting ovpnc5
Jun 24 06:16:26 kernel: ovpnc5: link state changed to UP


Code: [Select]

root@OPNsense:~ # fsck_ufs /dev/gpt/rootfs
** /dev/gpt/rootfs (NO WRITE)
** Last Mounted on /mnt
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
34571 files, 280000 used, 11627140 free (3204 frags, 1452992 blocks, 0.0% fragmentation)

8

German - Deutsch / Re: OPNsense braucht immer wieder einen Neustart

« on: June 24, 2017, 11:23:22 am »

Vielen Dank für die Antwort.

Hatte ich schon vor, muss ich aber machen wenn ich vor Ort bin. Sonst sperre ich mich noch aus :-).

9

German - Deutsch / OPNsense braucht immer wieder einen Neustart

« on: June 23, 2017, 10:49:18 pm »

Hallo zusammen,

hab zwei OPNsense an unterschiedlichen Standorten im Einsatz die ähnlichen Fehler aufweise. In beide Fällen wird eine FritzBox für die Internet Verbindung verwendet. Nach einem Neustart der FritzBox oder auch oft nach der Zwangstrennung durch den Provider funktioniert die Internetverbindung nicht mehr richtig, was sich unterschiedlich auswirken kann:
- mal scheinen nur die eingehenden Verbindungen nicht zu funktionieren (kein Port-Forwarding).
- ein anderes mal, kommt man aus dem LAN nicht ins Internet.
Nach einem Neustart von OPNsense scheint alles zu funktionieren. Musste aber auch schon zweimal neustarten.

Beide laufen je auf einem Jetway JBC390F541AA-19-B.  Einer der Beiden hängt an einem Bridged-Anschluss einer Kabel-Fritzbox und erhält feste Public-IP, hier besteht zumindest das Problem mit der Zwangstrennung nicht. Der andere ist in der FritzBox als Exposed-Host konfiguriert, hier muss die Fritzbox die Internetverbindung aufbauen, die Public-IP ist in dem Fall dynamisch. Die WAN-Schnittstelle der zweiten OPNsense bekommt ihre IP dynamisch von der FritzBox zugewiesen und ist immer 192.168.178.2 .
Vor der Umstellung wurden an beiden Standorten IP-COPs  mit anderer Hardware aber mit gleichen FritzBoxen eingesetzt, da gab es die Probleme nicht.

Hier wurde die FritBox neugestartet. Die Verbindung scheint kurzzeitig aufgebaut zu werden und wird anschließend getrennt.

Code: [Select]

Jun 23 10:18:33 OPNsense kernel: igb2: link state changed to DOWN
Jun 23 10:18:33 OPNsense configd.py: [ad675730-7aa5-443f-a3a7-5ec7622c73ad] Linkup stopping igb2
Jun 23 10:18:34 OPNsense opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
Jun 23 10:18:34 OPNsense opnsense: /usr/local/etc/rc.linkup: Clearing states to old gateway 192.168.178.1.
Jun 23 10:18:40 OPNsense kernel: igb2: link state changed to UP
Jun 23 10:18:40 OPNsense configd.py: [2fd25cb0-8c1c-48c8-b56e-457395120470] Linkup starting igb2
Jun 23 10:18:41 OPNsense opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet attached event for wan
Jun 23 10:18:41 OPNsense opnsense: /usr/local/etc/rc.linkup: HOTPLUG: Configuring interface wan
Jun 23 10:18:50 OPNsense kernel: igb2: link state changed to DOWN
Jun 23 10:19:24 OPNsense kernel: igb2: link state changed to UP
Jun 23 10:19:25 OPNsense opnsense: /usr/local/etc/rc.newwanip: rc.newwanip: Informational is starting igb2.
Jun 23 10:19:25 OPNsense opnsense: /usr/local/etc/rc.newwanip: rc.newwanip: on (IP address: 192.168.178.2) (interface: WAN[wan]) (real interface: igb2).
Jun 23 10:19:26 OPNsense opnsense: /usr/local/etc/rc.newwanip: ROUTING: setting IPv4 default route to 192.168.178.1
Jun 23 10:19:26 OPNsense opnsense: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface WAN.
Jun 23 10:19:26 OPNsense kernel: ovpns2: link state changed to DOWN
Jun 23 10:19:26 OPNsense configd.py: [01363251-4431-4435-871d-5ad513d1574e] Reloading filter
Jun 23 10:19:29 OPNsense configd.py: [90faa0f8-bc01-4c3f-a618-74341e8dac50] Reloading filter
Jun 23 10:19:29 OPNsense kernel: ovpns2: link state changed to UP
Jun 23 10:19:29 OPNsense configd.py: [af0b07bd-d538-4a76-9f8c-e769c09f7004] rc.newwanip starting ovpns2
Jun 23 10:19:29 OPNsense opnsense: /usr/local/etc/rc.newwanip: rc.newwanip: Informational is starting ovpns2.
Jun 23 10:19:30 OPNsense opnsense: /usr/local/etc/rc.newwanip: Interface is empty, nothing to do.
Jun 23 10:19:32 OPNsense kernel: ovpns3: link state changed to DOWN
Jun 23 10:19:32 OPNsense configd.py: [8eb47ac0-7a05-4070-a582-24f22e1dab25] Reloading filter
Jun 23 10:19:35 OPNsense configd.py: [03b61e19-bde5-45e8-a817-e7ab5aa051a2] Reloading filter
Jun 23 10:19:35 OPNsense kernel: ovpns3: link state changed to UP
Jun 23 10:19:35 OPNsense configd.py: [23fa9307-40b7-41f6-a85c-fccbf699dcc1] rc.newwanip starting ovpns3
Jun 23 10:19:35 OPNsense opnsense: /usr/local/etc/rc.newwanip: rc.newwanip: Informational is starting ovpns3.
Jun 23 10:19:36 OPNsense opnsense: /usr/local/etc/rc.newwanip: Interface is empty, nothing to do.
Jun 23 10:20:25 OPNsense configd.py: [8df6107d-124d-4912-969c-6e7f87573f01] returned exit status -11
Jun 23 10:20:25 OPNsense kernel: pid 73067 (php), uid 0: exited on signal 11 (core dumped)
Jun 23 10:20:40 OPNsense configd_ctl.py: error in configd communication  Traceback (most recent call last):   File "/usr/local/opnsense/service/configd_ctl.py", line 65, in exec_config_cmd     line = sock.recv(65536) timeout:
timed out
Jun 23 10:20:41 OPNsense configd.py: [faceebff-770a-4c6b-8436-b5cbbdd98f51] Linkup stopping igb2
Jun 23 10:20:41 OPNsense opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan
Jun 23 10:20:41 OPNsense opnsense: /usr/local/etc/rc.linkup: The command '/sbin/dhclient -c /var/etc/dhclient_wan.conf igb2 > /tmp/igb2_output 2> /tmp/igb2_error_output' returned exit code '15', the output was ''
Jun 23 10:20:41 OPNsense opnsense: /usr/local/etc/rc.linkup: ROUTING: setting IPv4 default route to 192.168.178.1
Jun 23 10:20:41 OPNsense opnsense: /usr/local/etc/rc.linkup: The command '/sbin/route delete -inet 'default'' returned exit code '1', the output was 'route: route has not been found delete net default fib 0: not in table'
Jun 23 10:20:41 OPNsense opnsense: /usr/local/etc/rc.linkup: The command '/sbin/route add -inet 'default' '192.168.178.1'' returned exit code '1', the output was 'route: writing to routing socket: Network is unreachable add ne
t default: gateway 192.168.178.1 fib 0: Network is unreachable'
Jun 23 10:20:41 OPNsense opnsense: /usr/local/etc/rc.linkup: Clearing states to old gateway 192.168.178.1.
Jun 23 10:20:41 OPNsense configd.py: [ea32e2a2-565b-499d-9f0a-26823cffaf70] Linkup starting igb2
Jun 23 10:20:41 OPNsense opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet attached event for wan
Jun 23 10:20:41 OPNsense opnsense: /usr/local/etc/rc.linkup: HOTPLUG: Configuring interface wan
Jun 23 10:20:41 OPNsense opnsense: /usr/local/etc/rc.linkup: The command '/sbin/dhclient -c /var/etc/dhclient_wan.conf igb2 > /tmp/igb2_output 2> /tmp/igb2_error_output' returned exit code '1', the output was ''
Jun 23 10:20:47 OPNsense configd.py: [3d7db1a3-18ce-45aa-9b9e-1780eef9005f] updating rfc2136 wan
Jun 23 10:20:47 OPNsense configd.py: [374f6426-77f9-48c2-9e1d-21dfe30cc7df] updating rfc2136 wan
Jun 23 10:20:48 OPNsense configd.py: unable to sendback response [OK ] for [interface][linkup][['start', 'igb2']] {2fd25cb0-8c1c-48c8-b56e-457395120470}, message was Traceback (most recent call last):   File "/usr/local/opnsen
se/service/modules/processhandler.py", line 202, in run     self.connection.sendall('%s\n' % result)   File "/usr/local/lib/python2.7/socket.py", line 228, in meth     return getattr(self._sock,name)(*args) error: [Errno 32] B
roken pipe
Jun 23 10:22:25 OPNsense kernel: [HBSD SEGVGUARD] [php (52240)] Suspension expired.
Jun 23 10:22:25 OPNsense kernel: -> pid: 52240 ppid: 47368 p_pax: 0x450<SEGVGUARD,ASLR,DISALLOWMAP32BIT>