106
18.1 Legacy Series / Re: [RESOLVED] Routing table not used for LAN clients (eg. for remote OpenVPN site)
« on: July 31, 2018, 12:48:06 pm »
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.
107
18.1 Legacy Series / Re: Routing table not used for LAN clients (eg. for remote OpenVPN site)
« on: July 31, 2018, 07:50:22 am »I think I found out the root cause: It might be because of some bug with firewall aliases in OPNsense: an alias fails to be completely expanded (it's an network alias where members are also network aliases), thus the firewall rule that should tell OPNsense to use "gw=default" for this destination does not match and it's then the final "gw=multiwan_gateway_group" that matches, ignoring my routing table.
That sounds like a good explanation for this crazy behaviour.
If the alias is not loading properly please check the system logs first.
Just some hints:
Another user in this forum have or had problems with an GeoIP alias which could not be loaded, and therefore all other following aliases were not loaded too.
Another reason could be the max. table entries for the firewall. If the max. count is reached, no more aliases can be loaded. You can rise the count in the firewall settings ( 'Maximum Table Entries' ).
108
German - Deutsch / Re: OPNsense mit Pi-Hole als DNS Server
« on: July 30, 2018, 09:15:00 pm »
Joh, hast Recht. Ich denke wir dachten beide "Internet" wäre das Ziel, also ein IP Bereich. Aber an der Stelle stehen ja die Services und wenn die kein DNS eingetragen haben, alles gut.
109
German - Deutsch / Re: OPNsense mit Pi-Hole als DNS Server
« on: July 30, 2018, 08:57:22 pm »Die Letzte Regel macht vermutlich die oberen zwei überflüssig, dazwischen musst du blockieren.
Nee, dat passt schon so.
Er will ja alle DNS Anfragen die nicht direkt an die OPNsense gehen auf die OPNsense umleiten, und die Redirect Rule steht ja ganz oben. D.h. die Anfrage wird niemals unten ankommen......naja, sollte niemals unten ankommen.
Nur die direkten Anfragen an die OPNsense sollen durchgelassen werden, was die zweite Regel macht.
Die letzte Regel sollte man auf jeden Fall verfeinern. Ein ANY -> Internet ist nicht gut.
BTW: Wieso nimmt man als Ziel "Firewall" bzw. 127.0.0.1? Der Verkehr bleibt doch eh in dem LAN. Richtg und sauberer wäre es m. E. das Objekt des LAN Adapters zu nehmen, oder?
110
German - Deutsch / Re: OPNsense mit Pi-Hole als DNS Server
« on: July 30, 2018, 08:42:03 pm »
Die Port-Forward Regel zieht nur, wenn jemand versucht einen anderen DNS Server als die der OPNsense anzusprechen. Daher das !LAN address, also alle Ziele außer der IP Adresse des OPNsense LAN Interface. D.h. wenn Du in Deinem Client die OPNsense LAN Interface als DNS Server eingetragen hast, matcht die PortForward Rule nicht. Somit brauchst Du noch eine Regel die den direkten DNS Traffic auf das Interface erlaubt.
So wie Du es jetzt hast sollte es funktionieren....aber sag Du es uns
So wie Du es jetzt hast sollte es funktionieren....aber sag Du es uns
111
German - Deutsch / Re: OPNsense mit Pi-Hole als DNS Server
« on: July 30, 2018, 12:54:25 pm »
Wenn Du den Dienst DNS (53) aus der dritten Regel entfernst und DNS danach nicht mehr funktioniert, zieht die zweite Regel aus irgendeinem Grund nicht.
Kontrollier mal die Redirect-Regel ob da alles korrekt ist (Interface, Destination, etc.).
Ansonsten poste mal einen Screenshot.
Kontrollier mal die Redirect-Regel ob da alles korrekt ist (Interface, Destination, etc.).
Ansonsten poste mal einen Screenshot.
112
German - Deutsch / Re: Disclaimer für OpenVPN Nutzer
« on: July 30, 2018, 09:00:13 am »
Hey Don,
wenn bei Dir die Meldung nicht kommt, könnte es ja vielleicht doch funktionieren.
Schau Dir mal die Regel an, die Du für die OpenVPN User angelegt hast. Dort darf kein Gateway angegeben sein da ansonsten der Verkehr nicht auf die Landing Page umgeleitet wird.
Gruß
Jas
wenn bei Dir die Meldung nicht kommt, könnte es ja vielleicht doch funktionieren.
Schau Dir mal die Regel an, die Du für die OpenVPN User angelegt hast. Dort darf kein Gateway angegeben sein da ansonsten der Verkehr nicht auf die Landing Page umgeleitet wird.
Gruß
Jas
113
18.1 Legacy Series / Re: Port forward & Firewall rule based on source IP via dynamic DNS [no-ip.com]
« on: July 29, 2018, 03:03:39 pm »
Hey,
a host alias should be the appropriate object for your needs. Have you looked into this type of alias? If yes, what`s the error message?
Jas
a host alias should be the appropriate object for your needs. Have you looked into this type of alias? If yes, what`s the error message?
Jas
114
German - Deutsch / Re: OPNsense mit Pi-Hole als DNS Server
« on: July 29, 2018, 12:58:30 pm »Hab mal ein Screenshot meiner Regeln für mein GästeWLAN angefügt.
Ich beziehe mich auf die Regeln im Screenshot.
Wenn ein Client im Gäste LAN einen anderen DNS Server (z.B. 4.4.4.4) manuell eingetragen hat und sich die DNS Anfrage auf den Weg macht, passiert bei dem Regelwerk folgendes:
1. Regel matcht nicht, weil das Ziel nicht die OPNsense ist
2. Regel matcht nicht, weil der Service nicht passt.
3. Regel matcht nicht, weil das Ziel nicht passt (ist ja eine öffentliche IP).
4. Regel matcht, weil alle Services zu allen IP Adressen erlaubt wird.
Somit wird DNS ins Internet erlaubt.
Man könnte jetzt eine eine Regel vor der 4. Regel einführen die da lautet:
Source: Gäste LAN
Destination: *
Service: TCP/UDP 53 (DNS)
Action: Deny
Dann würde die DNS Anfrage in Richtung Internet oder auch in alle anderen Subnetze der OPNsense geblockt. Wichtig ist, dass diese Regel nach der 1. Regel kommt. Ansonsten matcht die neue Regel vor der 1. Regel mit dem Allow. Und dann geht gar kein DNS mehr.
Aber @Raccoon ist schon auf dem richtigen Weg. Einfacher ist es ein Portforwarding für DNS einzurichten, und als Ziel den PiHole einzutragen. Dann kann sich jeder DNS Server eintragen wie er will. Sobald eine DNS Anfrage auf der Firewall erscheint, wird die an den PiHole weitergeleitet. Damit erreicht man das gewünschte Verhalten mit nur einer Regel.
115
18.1 Legacy Series / Re: OpenVPN adapter is registered in Unbound under OPNsense FQDN
« on: July 28, 2018, 04:31:23 pm »
Hey,
if nobody has an idea how to solve this, could somebody confirm this behaviour please (in conjunction with OpenVPN and Unbound DNS)? Before I open a new issue, I'll want to ensure that this is not only a misconfiguration of my OPNsense.
Thank you.
Jas
if nobody has an idea how to solve this, could somebody confirm this behaviour please (in conjunction with OpenVPN and Unbound DNS)? Before I open a new issue, I'll want to ensure that this is not only a misconfiguration of my OPNsense.
Thank you.
Jas
116
German - Deutsch / Re: Disclaimer für OpenVPN Nutzer
« on: July 28, 2018, 03:40:40 pm »
Hey,
schließe mich meinen Vorrednern an: das macht man am Besten einmal in Papierform beim Erstellen bzw. Aushändigen des VPN Zugangs an den Kunden.
Der Kunde klickt die LandingPage eh spätesens nach dem zweiten Mal sofort weg, weil er es bereits gelesen hat nur dann nur noch nervt.
Trotzdem habe ich das mal bei mir probiert. Anscheinend kann das Captive Portal nicht auf eine OpenVPN Verbindung gelegt werden. Sobald ich das Interface dafür auswähle erhalte ich die Meldung "error reloading captive portal template".
Was mir beim Test auch aufgefallen ist: wenn ich der FW Regel die den Traffic nach der LandingPage erlauben soll ein Gateway mitgebe, funktioniert die LandingPage nicht mehr. Der User bekommt dann sofort die komplette Freischaltung.
Jas Man
schließe mich meinen Vorrednern an: das macht man am Besten einmal in Papierform beim Erstellen bzw. Aushändigen des VPN Zugangs an den Kunden.
Der Kunde klickt die LandingPage eh spätesens nach dem zweiten Mal sofort weg, weil er es bereits gelesen hat nur dann nur noch nervt.
Trotzdem habe ich das mal bei mir probiert. Anscheinend kann das Captive Portal nicht auf eine OpenVPN Verbindung gelegt werden. Sobald ich das Interface dafür auswähle erhalte ich die Meldung "error reloading captive portal template".
Was mir beim Test auch aufgefallen ist: wenn ich der FW Regel die den Traffic nach der LandingPage erlauben soll ein Gateway mitgebe, funktioniert die LandingPage nicht mehr. Der User bekommt dann sofort die komplette Freischaltung.
Jas Man
117
German - Deutsch / Re: Aliase werden nicht aufgelöst/geladen
« on: July 28, 2018, 03:29:17 pm »
So auf den ersten Blick hätte ich gesagt "Dreh mal die 'Maximum Table Entries' hoch".
Aber da bist Du ja schon selbst drauf gekommen.
- Hast Du das Problem auch, wenn Du jetzt einen neuen Alias anlegst?
- Ging es vorher und nach einem Update nicht mehr?
- Im Alias selbst für z.B. die vertrauenswürdigen Geräte sind aber alle Hosts weiterhin eingetragen, nur unter pftables siehst Du dann nur einen? Dann könnte man vermuten das irgendwo ein "böses" Zeichen oder so drin steht, und der beim Laden der Aliase irgendwo abbricht. Das sollte dann aber in den System Logs stehen.
Aber da bist Du ja schon selbst drauf gekommen.
- Hast Du das Problem auch, wenn Du jetzt einen neuen Alias anlegst?
- Ging es vorher und nach einem Update nicht mehr?
- Im Alias selbst für z.B. die vertrauenswürdigen Geräte sind aber alle Hosts weiterhin eingetragen, nur unter pftables siehst Du dann nur einen? Dann könnte man vermuten das irgendwo ein "böses" Zeichen oder so drin steht, und der beim Laden der Aliase irgendwo abbricht. Das sollte dann aber in den System Logs stehen.
118
German - Deutsch / Re: Aliase werden nicht aufgelöst/geladen
« on: July 28, 2018, 02:46:11 pm »
Hey,
steht was in den Logs unter System: Log Files: General was auf ein Problem mit den Alias hinweißt? Hast Du vielleicht ein Leerzeichen am Anfang oder Ende der URL? Kannst Du die URLs im Browser aufrufen?
Hab es auch nach der Anleitung eingerichtet und es funktioniert ohne Probleme.
Gruß
Jas
steht was in den Logs unter System: Log Files: General was auf ein Problem mit den Alias hinweißt? Hast Du vielleicht ein Leerzeichen am Anfang oder Ende der URL? Kannst Du die URLs im Browser aufrufen?
Hab es auch nach der Anleitung eingerichtet und es funktioniert ohne Probleme.
Gruß
Jas
119
18.1 Legacy Series / Re: Routing table not used for LAN clients (eg. for remote OpenVPN site)
« on: July 28, 2018, 02:26:25 pm »
The routing table looks fine. If any routing protocol is active which share a route for 192.168.3.x/yy between the providers router and your OPNsense, you should see this route in the table.
- Run a traceroute from the GUI (Interfaces: Diagnostics: Trace Route) on OPNsense_Site1 to LAN_Site3 interface or client with source interface LAN_Site1 (192.168.1.254).
- Is the result fine? Then I guess the problem is not the OPNsense. It must be something in the LAN or the routing table of the clients are misconfigured.
- Runs it to the WAN interface as the traceroute from the clients?
- Run a traceroute from a client of LAN_Site1 to the OpenVPN interface of Site3 (192.168.254.6).
- Is the result fine?
- Runs it to the WAN interface as the traceroute to LAN_3?
- In your first post the traceroute to LAN_2 shows the IP 192.168.254.14. You wrote that this is the OpenVPN interface for Site_1 <-> Site_2 tunnel. But according on your routing table this is the OpenVPN interface for LAN_5. Is this just another subnet on Site_2, or do you have additional tunnels and you only mistaken/obfuscate the IP? I think this is not really important for troubleshooting, but to understand your topology.
- I'm not very familiar with the Multi WAN function, but maybe this is the root of your issue. Can you disable this option or at least the additional lines? Then test again.
- Are you allowing communications between LAN_2 and LAN_3? If yes, can you reach clients from LAN_2 in LAN_3 and vice versa?
- Check your Firewall rules, especially those for LAN_3. Have you defined a gateway which forces 'policy based routing'?
120
German - Deutsch / Re: NAT in Verbindung mit OPNVPN-Client klappt nicht. Hilfe bitte!
« on: July 27, 2018, 07:43:51 am »
Schön das es jetzt geht, aber sauber ist das glaub noch immer nicht.
Natürlich muss der eingehende Weg auch der ausgehende Weg sein. Den sonst sollte die Firewall die ausgehenden Pakete blocken weil er gar keine Session dazu kennt.
Und: wenn Du über Deinen DSLer rausgehst und somit die Source der Pakete die dynamische IP des DSLers ist, geht die Antwort zu diesen Pakten von z.B. OLDMAN ja auch an die dynamische IP Deines DSLers gehen. Sobald das Paket an Deiner OPNsense vorbei sagt die sich "Hey, das bin ich ja selbst", versucht es zu verarbeiten und da keine Session dazu existiert wird es verworfen. Ich denke das ist das eigentliches Problem. Und Du umgehst es jetzt nur, indem Du die Antworten einfach über ein anderes Gateway raus schickst.
Ist aber nur ne Vermutung. Dazu kenne ich den Aufbau nicht gut genug.
Natürlich muss der eingehende Weg auch der ausgehende Weg sein. Den sonst sollte die Firewall die ausgehenden Pakete blocken weil er gar keine Session dazu kennt.
Und: wenn Du über Deinen DSLer rausgehst und somit die Source der Pakete die dynamische IP des DSLers ist, geht die Antwort zu diesen Pakten von z.B. OLDMAN ja auch an die dynamische IP Deines DSLers gehen. Sobald das Paket an Deiner OPNsense vorbei sagt die sich "Hey, das bin ich ja selbst", versucht es zu verarbeiten und da keine Session dazu existiert wird es verworfen. Ich denke das ist das eigentliches Problem. Und Du umgehst es jetzt nur, indem Du die Antworten einfach über ein anderes Gateway raus schickst.
Ist aber nur ne Vermutung. Dazu kenne ich den Aufbau nicht gut genug.