OPNsense Forum
International Forums => German - Deutsch => Topic started by: christianroeser on November 12, 2015, 07:10:38 pm
-
Hallo,
ich habe heute versucht mit der Version 15.7.18 ein port forwarding für HTTP einzurichten. Opnsense sitzt hinter einem VDSL Router, daher habe ich die beiden entsprechenden Optionen zum herausfiltern der lokalen Netze auf der WAN Schnittstelle deaktiviert. Ich habe zuerst das forwarding innerhalb Opnsense eingerichtet und wollte dies testen.
Internet<---->VDSL Router<-- Class C Netz -->Opnsense<--Class B Netz--->HTTP Server
Zum Test habe ich mich mit einem Rechner in das gleiche Netz wie Router und Opnsense gehangen und habe die Adresse der WAN Schnittstelle von Opnsense im Browser eingegeben. Es passierte nichts. Nach herumspielen mit diversen Optionen habe ich auf dem Rechner und dem HTTP Server Wireshark installiert. Ich konnte sehen das SYN-Pakete beim Client abgehen und am Server ankommen. Jedoch kam die SYN/ACK-Pakete des Servers nie am Client an. Opnsense war natürlich als Default Gateway eingetragen. Im Log der Firewall konnte zumindest ich nichts auffälliges sehen.
Habe danach den Rechner mit pfsense neu aufgesetzt und es lief innerhalb weniger Minuten. :(
Irgendjemand eine Idee?
Gruß
Christian
-
Schade dass du das direkt mit PFSense wieder umsetzt.
so adhoc würde ich fragen nach
- Rules
- Destination geprüft?
- Source geprüft?
- Welche Ports und war TCP freigegeben
Gruß
Andreas
-
Hallo Andreas,
kein Problem, die Kisten sind ja schnell aufgesetzt.
Habe die Ursache des Problems mittlerweile auch gefunden. :) Allerdings kann ich keine Erklärung für die Ursache liefern. ???
Gleicher Aufbau wie in meinem ersten Post, wieder Wireshark angeschmissen - jedoch diesmal keinen Filter im Programm gesetzt sondern mal den gesamten Wust an Daten beobachtet. Dabei sind mir ICMP Redirect Pakete vom VDSL Router aufgefallen. Diese tauchten unmittelbar nach den SYN/ACK-Paketen auf.
Also habe ich unter OPNSense mal das Gateway auf den WAN-Schnittstelle (den VDSL Router) entfernt und siehe da - es funktioniert. Anschließend das Gateway wieder eingetragen, Port Forwarding am Router zu OPNSense eingetragen (was für ein Murks :( ) und auch das funktioniert.
Also hat OPNSense die ausgehenden Pakete nicht an meinen Client (der im gleichen Netz wie WAN-Schnittstelle und Router hängt) sondern an den VDSL-Router geschickt? Wenn ja - Bug oder so gewollt?
Gruß
Christian
-
Ich halts ja eh schon für schlecht nen VDSL Router vor der OPNSENSE zu fahren.
kannst das nicht als modem nutzen?
also in der DMZ musstest du ein port forwarding machen?
das halte ich aber auch für merkwürdig... da sollte das doch ohne gehen...
-
Christian,
ist bei deinem VDSL Router NAT aktiviert?
-
Das klingt nach einem kleinen Bug im Code. Mit welcher pfSense Version funktionierte dies?
Um welchen Port geht es denn? Und wenn es um Port 80 oder 443 geht, ist das Webinterface auf der OPNsense verschoben auf Alternativ-Ports, z.b. 8080 und 8443?
-
Hallo,
der Router ist leider ein Speedport 5501, wurde von der Telekom gestellt. Soweit mir bekannt lässt er sich nicht als Modem konfigurieren. Erschwerend kommt noch hinzu das es ja ein IP-Anschluss ist und daher ein ISDN-Telefon an dem Ding hängt.
Ja, der Router macht ein NAT.
Hatte es mit der aktuellen Version 2.2.5 von pfsense ausprobiert. Es handelt sich um HTTPS, also Port 443. Beim ersten Test mit OPNSense hatte ich das Webinterface auf einen anderen Port umgelegt. Für den Test mit pfsense und dem zweiten Test mit OPNSense wurden keine Änderungen an den Ports vorgenommen.
Gruß
Christian
-
OK.. ich kram das mal raus, da ich über den gleichen Fehler gestolpert bin.
1. Wenn man beim Einrichten DHCP für WAN angibt, setzt opnsense das Gateway zwar richtig, behandelt es aber offenbar als upstream gateway. Das hat zur Folge, daß Pakete, die auf WAN eintreffen, nicht an die MAC des Absenders zurückgeschickt werden, sondern an die MAC des nächsten Gateways.
Das ist aber falsch, wenn der Absender im "lokalen WAN" sitzt.
2. Stellt man auf statische IP um und vergibt kein Gateway - geht es.
3. Stellt man nun (wie ich) dann unter Interfaces/WAN ein Gateway ein - was da gar nicht hingehört, da dort nur Upstream Gateways hin sollen - geht es wieder nicht. Entfernt man das Gateway dann - geht es wieder.
4. Dummerweise quittiert aber System/Gateways jeden Versuch dort etwas zu ändern bei mir mit einem PHP-Fehler.. ^^
Fatal error: Call to undefined function calculate_ipv6_lenght() in /usr/local/etc/inc/services.inc on line 1060
Man endet dann ein einem Punkt, wo das System zwar eine default route hat (netstat -r zeigt sie an), aber die GUI nichts davon sieht und man weder surfen kann noch port forwarding funktioniert :D
Edit: port forwarding geht doch, aber Gateways ist leer und Clients haben keinen Internetzugriff
-
Das klingt nach 16.7-RC, erstmal weg mit dem Fehler und dann nochmal probieren.
# opnsense-patch c221e3a8c
Danke für den Report. :)
Grüße,
Franco
-
Naja, es ist 16.1.19 stable. Weiß auch immer noch nicht, warum opnsense das Gateway so seltsam behandelt, bin mit pf noch nicht so per Du wie mit iptables... Mit Wireshark etc. kann man schön sehen, wie die Pakete an die falsche MAC gesendet werden. Wahrscheinlich fällt so was nur selten auf, da man i.d.R. ja nicht Pakete an das lokale WAN-Subnetz schickt. Oder der Fehler tritt nur auf, wenn die WAN-IP im Bereich der privaten Netz liegt.
-
Oh, hier der Fix für 16.1.19:
# opnsense-patch 429f0a477a
Grüße
Franco