1
German - Deutsch / Re: VPN/Roadwarrior-Zugriff auf lokalen DNS-Server
« on: December 28, 2019, 09:20:28 am »
Hm. Keine Ahnung, was passiert ist, aber jetzt funktioniert's... 
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.
Pages: [1]
2
German - Deutsch / [Gelöst] VPN/Roadwarrior-Zugriff auf lokalen DNS-Server
« on: December 27, 2019, 11:55:20 pm »
Hallo,
ich bin neu hier und jüngst von IPFire zu OPNsense umgestiegen. Zu 99% läuft alles wie zuvor, jedoch habe ich noch Schwierigkeiten bei der VPN/Roadwarrior-Konfiguration.
Mein Heimnetz ist 192.168.1.0/24, die LAN-Schnittstelle ist 192.168.1.1. Auf 192.168.1.2 lauscht ein Pi-Hole als DNS-Server. Der wird per DHCP an alle Clients übergeben, und via LAN-Regel darf nur Pi-Hole DNS-Anfragen ins Internet senden - alle anderen DNS-Anfragen werden von der default deny rule geblockt. So weit, so gut.
Um den Pi-Hole auch mobil mit dem Handy nutzen zu können, hab ich nach dieser Anleitung einen Roadwarrior erstellt. Damit ich in fremden WLANs keine Problrme mit geblockten Ports bekomme, hab ich statt 1194 hingegen Port 443 genommen (ich betreibe keine Server). Im Clientexport hab ich meine Dyndns-Adresse übergeben, die wiederum in der Fritzbox konfiguriert ist, die Firewall ist Exposed Host. Eine WAN-Regel erlaubt eingehende Pakete auf Zielport 443 der WAN-Adresse. Eine OpenVPN-Regel erlaubt eingehende Pakete vom Tunnel-Netzwerk, Ziel und Ports stehen auf "jeglich".
Das klappt alles prima, solang ich mich mit dem Roadwarrior in fremden Netzen (z.B. Mobilfunk oder WLAN) befinde. In den Logs kann ich ja sehen, dass die VPN-Verbindung über Port 443 aufgebaut wird und die DNS-Anfragen dann aus dem Tunnel-Netzwerk an 192.168.1.2 gehen.
Bin ich hingegen mit dem Handy im heimischen (W)LAN, klappt die DNS-Auflösung nicht mehr. In den Logs sehe ich DNS-Anfragen von meinem (Android-Handy) an den Google-DNS 8.8.8.8 - und die werden natürlich abgelehnt (siehe oben). Bei deaktiviertem VPN-Client gehen die DNS-Anfragen wunschgemäß an 192.168.1.2.
Irgendwas habe ich wohl noch vergessen. Aber was?
ich bin neu hier und jüngst von IPFire zu OPNsense umgestiegen. Zu 99% läuft alles wie zuvor, jedoch habe ich noch Schwierigkeiten bei der VPN/Roadwarrior-Konfiguration.
Mein Heimnetz ist 192.168.1.0/24, die LAN-Schnittstelle ist 192.168.1.1. Auf 192.168.1.2 lauscht ein Pi-Hole als DNS-Server. Der wird per DHCP an alle Clients übergeben, und via LAN-Regel darf nur Pi-Hole DNS-Anfragen ins Internet senden - alle anderen DNS-Anfragen werden von der default deny rule geblockt. So weit, so gut.
Um den Pi-Hole auch mobil mit dem Handy nutzen zu können, hab ich nach dieser Anleitung einen Roadwarrior erstellt. Damit ich in fremden WLANs keine Problrme mit geblockten Ports bekomme, hab ich statt 1194 hingegen Port 443 genommen (ich betreibe keine Server). Im Clientexport hab ich meine Dyndns-Adresse übergeben, die wiederum in der Fritzbox konfiguriert ist, die Firewall ist Exposed Host. Eine WAN-Regel erlaubt eingehende Pakete auf Zielport 443 der WAN-Adresse. Eine OpenVPN-Regel erlaubt eingehende Pakete vom Tunnel-Netzwerk, Ziel und Ports stehen auf "jeglich".
Das klappt alles prima, solang ich mich mit dem Roadwarrior in fremden Netzen (z.B. Mobilfunk oder WLAN) befinde. In den Logs kann ich ja sehen, dass die VPN-Verbindung über Port 443 aufgebaut wird und die DNS-Anfragen dann aus dem Tunnel-Netzwerk an 192.168.1.2 gehen.
Bin ich hingegen mit dem Handy im heimischen (W)LAN, klappt die DNS-Auflösung nicht mehr. In den Logs sehe ich DNS-Anfragen von meinem (Android-Handy) an den Google-DNS 8.8.8.8 - und die werden natürlich abgelehnt (siehe oben). Bei deaktiviertem VPN-Client gehen die DNS-Anfragen wunschgemäß an 192.168.1.2.
Irgendwas habe ich wohl noch vergessen. Aber was?
3
German - Deutsch / Re: Default Deny Route blockt LAN-WlAn-Bridge
« on: May 16, 2018, 07:49:20 pm »
Zwischenzeitlich bin ich dann noch auf weitere Probleme in Zusammenhang mit Google Chromecast gestoßen. Ich wäre nicht verwundert, wenn das alles dieselbe Ursache hat, aber ehrlich gesagt, ist mir die Fehlersuche dann doch zu aufwändig.
Ich bleib dann bei IPFire. Was jetzt keine pauschale Ablehnung gegenüber OPNSense sein soll. Ist sicher ein tolles Produkt, aber die "Kosten-Nutzen-Rechnung" geht für mich nicht auf. Never change a running system.
Danke für die Hilfe.
Ich bleib dann bei IPFire. Was jetzt keine pauschale Ablehnung gegenüber OPNSense sein soll. Ist sicher ein tolles Produkt, aber die "Kosten-Nutzen-Rechnung" geht für mich nicht auf. Never change a running system.
Danke für die Hilfe.
4
German - Deutsch / Re: Default Deny Route blockt LAN-WlAn-Bridge
« on: May 13, 2018, 07:28:18 pm »
Erst einmal danke für die Antwort.
Steht auf "Alle", und das GUI rät mir auch, dies nicht zu ändern.
Ja, jetzt wird's interessant...
WLAN-Clients ohne Reservierung werden als LAN-Lease angezeigt. Klicke ich (immer noch unter DHCP->Leases) auf das Plus-Zeichen neben dem Client und vergebe eine IP außerhalb meiner DHCP Range, bekomme ich eine Fehlermeldung, dass die IP nicht außerhalb der DHCP-Rang liegen darf... Gehe ich hingegen zu DHCP->INTERN und vergebe dort eine IP-Reservierung, kann ich auch eine IP außerhalb der Range angeben. Die reservierten(!) Clients werden dann in den Leases der INTERN Bridge zugeordnet.
Dank des von dir nachträglich erwähnten Flags in den Tunables wird hier zumindest die Brücke INTERN angezeigt. Auch, wenn ich die allow rule deaktiviere, aber dann greift die deny all rule immer noch - aber jetzt immerhin mit richtigem Interface.
Ja, damit klappt's. Aber das ist ja nach meinem Verständnis nicht so wirklich Sinn der Sache, oder?
Der Datenverkehr wird mit USER_RULE und anschließend mit "Let out anything from firewall host itself" protokolliert.
Keine Ahnung, ich weiß keine öffentliche IP.
Ja, eben, das ist ja mein Problem. Dafür hab ich ja die Bridge, damit zwischen allen WLAN und LAN Cliennts im gleichen Subnetz keine Regeln greifen. So ist zumindest meine Absicht...
Quote
Welches Interface hast Du denn unter "System: Settings: Administration -> Listen Interfaces" für den WebGUI Access angegeben, wenn Du sowohl aus dem LAN als auch WLAN dran kommst? Wenn dort die Bridge drin steht, ordnet die Sense den Traffic zumindestens hier korrekt zu.
Steht auf "Alle", und das GUI rät mir auch, dies nicht zu ändern.
Quote
Welcher Adapter wird unter den DHCPv4 Leases bei den beiden Clients angezeigt? LAN bzw. WLAN oder bei beiden die Bridge?
Ja, jetzt wird's interessant...
WLAN-Clients ohne Reservierung werden als LAN-Lease angezeigt. Klicke ich (immer noch unter DHCP->Leases) auf das Plus-Zeichen neben dem Client und vergebe eine IP außerhalb meiner DHCP Range, bekomme ich eine Fehlermeldung, dass die IP nicht außerhalb der DHCP-Rang liegen darf... Gehe ich hingegen zu DHCP->INTERN und vergebe dort eine IP-Reservierung, kann ich auch eine IP außerhalb der Range angeben. Die reservierten(!) Clients werden dann in den Leases der INTERN Bridge zugeordnet.
Quote
Aktvier doch mal das Logging in der Allow Rule um zu schauen, ob bei erlaubten Paketen über das LAN Interface die Bridge oder das LAN Interface angezeigt wird. Wenn dort das LAN Interface angezeigt wird, ist es korrekt das bei den geblockten Paketen über WLAN das WLAN Interface und nicht die Bridge angezeigt wird.
Dank des von dir nachträglich erwähnten Flags in den Tunables wird hier zumindest die Brücke INTERN angezeigt. Auch, wenn ich die allow rule deaktiviere, aber dann greift die deny all rule immer noch - aber jetzt immerhin mit richtigem Interface.
Quote
Richte eine temp. Any-Any Rule auf der Bridge ein um auszuschließen, dass die Regeln aus irgendeinem Grund nicht matchen.
Ja, damit klappt's. Aber das ist ja nach meinem Verständnis nicht so wirklich Sinn der Sache, oder?
Der Datenverkehr wird mit USER_RULE und anschließend mit "Let out anything from firewall host itself" protokolliert.
Quote
Funktioniert HTTP(s) über das Tablet wenn Du die IPs direkt ansprichst?
Keine Ahnung, ich weiß keine öffentliche IP.
Quote
Und dann eine Frage die sich mir gerade stellt: wieso zieht hier überhaupt die Firewall Rule? Pi-Hole und Tablet sind doch im selben Subnetz?
Ja, eben, das ist ja mein Problem. Dafür hab ich ja die Bridge, damit zwischen allen WLAN und LAN Cliennts im gleichen Subnetz keine Regeln greifen. So ist zumindest meine Absicht...
5
18.1 Legacy Series / default deny rout blocking LAN+WLAN bridge
« on: May 12, 2018, 11:57:32 am »
This is a translation of my post https://forum.opnsense.org/index.php?topic=8675.msg38536 to increase the chance of support.
Hello everybody,
I'm the new guy. And I'm trying to switch from IPfire to OPNsense. One reason, among others, is the ability to configure network bridges via GUI in OPNsense.
I attempt to combine LAN and WIFI (WLAN) interfaces to a bridge, so I can use the bridge für DHCP, firewall rules etc. My config so far:
Interfaces
-----------
LAN
- enabled
- no IPv4 address
WLAN
- enabled
- Access Point Mode
- no IPv4 address
INTERN
- Bridge: LAN+WLAN
- IP-address 192.168.1.1/24
Assignments
- INTERN: bridge0 (LAN+WLAN)
- LAN: re0
- WAN: re1
- WLAN: run0_wlan1
DHCPv4
---------
INTERN
- enable
- Subnet 192.168.1.0/24
- Range 192.168.1.200 bis 192.168.1.250
LAN
- DHCPv4 was disabled during initial configuration, but suddenly disappeared totally from the DHCP section in the main menu. Thinking about it, I guess because I disabled the static IP adress lateron, maybe?
Static Mappings
- Notebook, cable:
-- IP 192.168.1.10
-- DNS 192.168.1.2+192.168.1.2 (Pi-Hole, local DNS-Server w/ static IP)
-- Gateway 192.168.1.1
- Tablet, WLAN
-- IP 192.168.1.20
-- rest same as Notebook
FIREWALL RULES
-------------------
INTERN
1) TCPv4, Source INTERN net, SourcePort *, Dest *, DestPort 80+443, GW *
2) UDPv4, Source INTERN net, SourcePort *, Dest *, DestPort 53, GW *
LAN
none, just Anti-Lockout Rule
WLAN
none
Now the problem:
Using the Notebook, I can access the internet with no problems.
Using the WIFI-Tablet, I can not. IP-Address, GW and DNS are correctly supplied by the DHCP Server. I can access the FW using IP 192.168.1.1, which is the static IP Address of the INTERN bridge (see above)
Trying to access other destinations, live view log reads as follows:
Interface WLAN - Source 192.168.1.20 - Dest 192.168.1.2:53 - Default Deny Route
Basically, I got the idea: The tablet 192.168.1.20 is trying to access the DNS-Server 192.168.1.2 via the interface WLAN, which has no rules defined, therefore being blocked by default deny rule.
But why does the tablet use the WLAN interface an not the INTERN bridge? That's why I created the bridge in the first place, so that all clients are in the same subnet, can communicate to each other freely, and I can define rules for both LAN+WLAN at the same time by using the INTERN bridge. Which would be pointless if I had to define rules for WLAN interface as well.
Hello everybody,
I'm the new guy. And I'm trying to switch from IPfire to OPNsense. One reason, among others, is the ability to configure network bridges via GUI in OPNsense.
I attempt to combine LAN and WIFI (WLAN) interfaces to a bridge, so I can use the bridge für DHCP, firewall rules etc. My config so far:
Interfaces
-----------
LAN
- enabled
- no IPv4 address
WLAN
- enabled
- Access Point Mode
- no IPv4 address
INTERN
- Bridge: LAN+WLAN
- IP-address 192.168.1.1/24
Assignments
- INTERN: bridge0 (LAN+WLAN)
- LAN: re0
- WAN: re1
- WLAN: run0_wlan1
DHCPv4
---------
INTERN
- enable
- Subnet 192.168.1.0/24
- Range 192.168.1.200 bis 192.168.1.250
LAN
- DHCPv4 was disabled during initial configuration, but suddenly disappeared totally from the DHCP section in the main menu. Thinking about it, I guess because I disabled the static IP adress lateron, maybe?
Static Mappings
- Notebook, cable:
-- IP 192.168.1.10
-- DNS 192.168.1.2+192.168.1.2 (Pi-Hole, local DNS-Server w/ static IP)
-- Gateway 192.168.1.1
- Tablet, WLAN
-- IP 192.168.1.20
-- rest same as Notebook
FIREWALL RULES
-------------------
INTERN
1) TCPv4, Source INTERN net, SourcePort *, Dest *, DestPort 80+443, GW *
2) UDPv4, Source INTERN net, SourcePort *, Dest *, DestPort 53, GW *
LAN
none, just Anti-Lockout Rule
WLAN
none
Now the problem:
Using the Notebook, I can access the internet with no problems.
Using the WIFI-Tablet, I can not. IP-Address, GW and DNS are correctly supplied by the DHCP Server. I can access the FW using IP 192.168.1.1, which is the static IP Address of the INTERN bridge (see above)
Trying to access other destinations, live view log reads as follows:
Interface WLAN - Source 192.168.1.20 - Dest 192.168.1.2:53 - Default Deny Route
Basically, I got the idea: The tablet 192.168.1.20 is trying to access the DNS-Server 192.168.1.2 via the interface WLAN, which has no rules defined, therefore being blocked by default deny rule.
But why does the tablet use the WLAN interface an not the INTERN bridge? That's why I created the bridge in the first place, so that all clients are in the same subnet, can communicate to each other freely, and I can define rules for both LAN+WLAN at the same time by using the INTERN bridge. Which would be pointless if I had to define rules for WLAN interface as well.
6
German - Deutsch / Default Deny Route blockt LAN-WlAn-Bridge
« on: May 12, 2018, 11:30:56 am »
Hallo zusammen,
ich bin neu hier. Und spiele mit der Absicht, von IPfire auf OPNsense umzusteigen. Unter anderem, weil man in OPNsense Netzwerkbrücken per GUI konfigurieren kann.
Meine Absicht ist, die LAN- und WLAN-Schnittstelle als gemeinsame Brücke ansprechen zu können. Meine Config sieht so aus:
Interfaces
-----------
LAN
- enabled
- keine IPv4 Adresse
WLAN
- enabled
- Access Point Mode
- keine IPv4 Adresse
INTERN
- Bridge: LAN+WLAN
- IP-Adresse 192.168.1.1/24
Assignments
- INTERN: bridge0 (LAN+WLAN)
- LAN: re0
- WAN: re1
- WLAN: run0_wlan1
DHCPv4
---------
INTERN
- enable
- Subnet 192.168.1.0/24
- Range 192.168.1.200 bis 192.168.1.250
LAN
- hatte ich während der Einrichtung nachträglich deaktiviert, taucht aber im Menü mittlerweile gar nicht mehr auf. Hö???
Static Mappings
- Notebook, verkabelt:
-- IP 192.168.1.10
-- DNS 192.168.1.2+192.168.1.2 (Pi-Hole, lokaler DNS-Server mit fester IP)
-- Gateway 192.168.1.1
- Tablet, WLAN
-- IP 192.168.1.20
-- Rest wie Notebook
FIREWALL RULES
-------------------
INTERN
1) TCPv4, Source INTERN net, SourcePort *, Dest *, DestPort 80+443, GW *
2) UDPv4, Source INTERN net, SourcePort *, Dest *, DestPort 53, GW *
LAN
nichts, nur die Anti-Lockout Rule
WLAN
nichts
Nun das Problem:
Mit dem Notebook, per LAN-Kabel angeschlossen, komme ich problemlos ins Internet.
Mit dem WLAN-Tablet jedoch nicht. Es erhält die richtige IP-Adresse, auch GW und DNS werden richtig zugewiesen. Auf die FW-GUI kann ich mit dem Tablet über die Adresse 192.168.1.1 (siehe oben, statische Adresse der INTERN-Brücke) zugreifen.
Bei anderen Zielen meldet mir das LOG-File jedoch:
Interface WLAN - Source 192.168.1.20 - Dest 192.168.1.2:53 - Default Deny Route
Die Theorie ist klar: Das Tablet 192.168.1.20 versucht auf den per DHCP zugewiesenen DNS-Server 192.168.1.2 zuzugreifen - und verwendet dafür das Interface WLAN, welches keine Regeln definiert hat, so dass die default deny rule greift.
Aber warum wird hier das WLAN Interface angesprochen, und nicht die Netzwerkbrücke INTERN? Denn genau dazu habe ich ja die Brücke erstellt, damit sich alle Clients im gleichen Subnet befinden und ich hierfür Regeln erstelle, die gleichermaßen für LAN und WLAN gelten?
ich bin neu hier. Und spiele mit der Absicht, von IPfire auf OPNsense umzusteigen. Unter anderem, weil man in OPNsense Netzwerkbrücken per GUI konfigurieren kann.
Meine Absicht ist, die LAN- und WLAN-Schnittstelle als gemeinsame Brücke ansprechen zu können. Meine Config sieht so aus:
Interfaces
-----------
LAN
- enabled
- keine IPv4 Adresse
WLAN
- enabled
- Access Point Mode
- keine IPv4 Adresse
INTERN
- Bridge: LAN+WLAN
- IP-Adresse 192.168.1.1/24
Assignments
- INTERN: bridge0 (LAN+WLAN)
- LAN: re0
- WAN: re1
- WLAN: run0_wlan1
DHCPv4
---------
INTERN
- enable
- Subnet 192.168.1.0/24
- Range 192.168.1.200 bis 192.168.1.250
LAN
- hatte ich während der Einrichtung nachträglich deaktiviert, taucht aber im Menü mittlerweile gar nicht mehr auf. Hö???
Static Mappings
- Notebook, verkabelt:
-- IP 192.168.1.10
-- DNS 192.168.1.2+192.168.1.2 (Pi-Hole, lokaler DNS-Server mit fester IP)
-- Gateway 192.168.1.1
- Tablet, WLAN
-- IP 192.168.1.20
-- Rest wie Notebook
FIREWALL RULES
-------------------
INTERN
1) TCPv4, Source INTERN net, SourcePort *, Dest *, DestPort 80+443, GW *
2) UDPv4, Source INTERN net, SourcePort *, Dest *, DestPort 53, GW *
LAN
nichts, nur die Anti-Lockout Rule
WLAN
nichts
Nun das Problem:
Mit dem Notebook, per LAN-Kabel angeschlossen, komme ich problemlos ins Internet.
Mit dem WLAN-Tablet jedoch nicht. Es erhält die richtige IP-Adresse, auch GW und DNS werden richtig zugewiesen. Auf die FW-GUI kann ich mit dem Tablet über die Adresse 192.168.1.1 (siehe oben, statische Adresse der INTERN-Brücke) zugreifen.
Bei anderen Zielen meldet mir das LOG-File jedoch:
Interface WLAN - Source 192.168.1.20 - Dest 192.168.1.2:53 - Default Deny Route
Die Theorie ist klar: Das Tablet 192.168.1.20 versucht auf den per DHCP zugewiesenen DNS-Server 192.168.1.2 zuzugreifen - und verwendet dafür das Interface WLAN, welches keine Regeln definiert hat, so dass die default deny rule greift.
Aber warum wird hier das WLAN Interface angesprochen, und nicht die Netzwerkbrücke INTERN? Denn genau dazu habe ich ja die Brücke erstellt, damit sich alle Clients im gleichen Subnet befinden und ich hierfür Regeln erstelle, die gleichermaßen für LAN und WLAN gelten?
Pages: [1]