Messages

136

18.1 Legacy Series / Re: Bug: Renaming Aliases and NAT

« on: July 18, 2018, 12:43:26 pm »

I've noticed this behaviour too.
But when the rules are reloaded the new name of the alias should appera. Have you tried this?

137

18.1 Legacy Series / Re: /etc/hosts modifications

« on: July 18, 2018, 08:00:24 am »

As far as I know there's no point in the GUI where you can modify the hosts file.

I'm not an Linux expert, but maybe you can do it with a cron job:

echo "127.0.0.1       name.tld" >> /etc/hosts

138

18.1 Legacy Series / Re: Firewall block rule for specific ip addresses

« on: July 18, 2018, 07:42:00 am »

If your NVR is in the same subnet as your IP cams, the easiest way would be to remove the gateway IP address (and maybe DNS) from your IP cams.

Otherwise it depends on how your firewall is configured. Is every IP in your 192.168.1.0 subnet allowed to access the Internet? Than you have to create an deny rule for the group of IPs that are not allowed. The easiest way would be an alias containing those IPs. Move the deny rule before the allowed rule.

You can do this also with one rule. Create an alias (e.g. HTTP_clients) with the IPs, that are allowed to access the Internet. Change your rule from

Source: LAN_net
Destination: Any
Service: HTTP/HTTPS

to

Source: HTTP_clients
Destination: Any
Service: HTTP/HTTPS

You've to add new clients with Internet access to the alias manually then. But it prevents new IoT devices to phone home as soon as you've connected them.

139

18.1 Legacy Series / Re: Block all but allow WAN/internet access

« on: July 18, 2018, 07:25:35 am »

Do you mean outbound NAT rules? Those are set automatically in the default settings, aren't they?

Yes, you're right. In standard OPNsense generate those rules by itself. I missed this point because I've set it to "manual" to have full control over the settings. But I'm not sure how the standard NAT is working. I mean, how recognize the OPNsense which adatper is WAN and which LAN and where he has to do NAT? Maybe you should check if OPNsense has created the necessary rules.

That's where I am struggeling. What do I have to put at "destination" so WAN traffic is allowed? The only option with which I got it working was "any" and that's definitely not what I want. Can you maybe show me a sample rule for HTTPS or any other service?

There's no firewall object for Internet hosts. But you can create an alias with all privat networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), add it as destination in your rule and invert it. That's how I did it. Works fine.

140

18.1 Legacy Series / Re: Block all but allow WAN/internet access

« on: July 17, 2018, 09:37:00 pm »

Hey gladston3,

There's no need for an "block all" rule to block traffic between the LAN ports. The default blocking rule of the firewall will block the traffic between your different subnets if is not explicit allowed by an rule.

To access the Internet you need to configure NAT for each subnet first.

Then you will need some allow rules for each service and subnet you would like to allow.
You can use floating rule to create one rule e.g. for HTTP(S) to WAN for all your LAN interfaces.
Choose the WAN gateway to allow this traffic only for WAN. Otherwise it will also allow HTTP(S) between your subnets.

Don't forget to allow also DNS for the clients. If your OPNsense is your DNS server, allow DNS to the firewall. Otherwise allow DNS to the Internet or only to one server e.g. 8.8.8.8.

Jas
 

141

German - Deutsch / Re: opnsense anfaenger braucht unterstützung

« on: July 17, 2018, 01:38:11 pm »

Hey,

- was bekommt denn der Client für eine IP Adresse zugewiesen?
- Siehst Du die ausgegebenen IP Adressen in der OPNsense unter "DHCP Leases"?
- Kannst Du die NAS vom Client aus anpingen?
- Ist der managed Switch irgendwie konfiguriert (z.B. VLAN oder PVLAN)

Traffic zwischen Clients im selben Subnetz geht eigentlich nicht über das Gateway / OPNsense. Da müsste schon sowas wie PVLAN eingerichtet sein, was per ARP jeglichen Traffic zum Gateway schickt.

Jas

142

German - Deutsch / Re: OpenVPN Firewall-Regeln - welches Interface

« on: July 17, 2018, 11:32:10 am »

Bei einem tap Adapter hätte ich das Verhalten verstanden. Denn da hast Du ja keinen eigenen IP Adapter auf dem Du Regel anlegen kannst. Ich vermute (ich habe selbst nur tun Adapter) das man bei einem tap Adapter die Regeln dann auf dem darunterliegenden Adapter anlegen muss.

Ich musste auf meinem physik. WAN Adapter nur die eingehenden Ports für den OpenVPN Dienst selbst freigeben. Die Regeln für die OpenVPN Clients habe ich dann auf dem virtuellem OpenVPN Adapter angelegt.

Welches Interface siehst Du denn auf der Firewall, wenn OpenVPN Client Traffic gedropped wird?

143

German - Deutsch / Re: OpenVPN Firewall-Regeln - welches Interface

« on: July 17, 2018, 09:53:10 am »

Hey,

nutzt Du tun oder tap Adapter?

Jas

144

18.1 Legacy Series / Re: Route to remote OpenVPN site not used for LAN clients

« on: July 16, 2018, 09:33:05 pm »

user@machine_at_site_1:~# traceroute 192.168.3.1
traceroute to 192.168.3.1 (192.168.3.1), 30 hops max, 60 byte packets
 1  80.10.x.y (80.10.x.y)  0.127 ms  0.100 ms  0.112 ms
 2  * * *
 3  * * *
[...]

In my opinion it's unusal that the WAN IP address is the first hop that answers to your traceroute, isn't it?
I mean, when you traceroute site 2, you see the IP of your OPNsense 192.168.1.254 as the first hop. That means OPNsense answeres to ICMP requests in generally. So why didn't it when you try to traceroute site 3?

145

18.1 Legacy Series / OpenVPN adapter is registered in Unbound under OPNsense FQDN

« on: July 15, 2018, 01:11:31 pm »

Hi,

I've updated OPNsense to 18.1.12 on Friday and noticed today, that I've a lot of internal traffic that is dropped by the firewall. The source of those dropped packets are clients within my LAN subnet. The destination is always the IP of the OpenVPN server adapter.

After some investigation I found out, that Unbound has two IP addresses for the OPNsense FQDN: the management IP that I've set up for HTTPS and SSH, and the IP for the OpenVPN interface.

Code: [Select]

Name:    jaswall.mgmt.home.arpa
Addresses:  192.168.1.1
          192.168.15.1
Therefore when I access the WebGUI via the FQDN, my client get's somethimes the management IP, and sometimes the OpenVPN adapter IP. The packets to the OpenVPN adapter IP are dropped of course. The OpenVPN adapter is only for routing and DNS for the VPN clients.

When I disable my OpenVPN server, the second IP for the OPNsense FQDN in Unbound is gone.

Code: [Select]

Name:    jaswall.mgmt.home.arpa
Addresses:  192.168.1.1

I'm not sure if this was already before the update. But I've never noticed so many droppes of internal packets in my firewall.

Is there an option where I can disable this behaviour? Or is this an issue?
Thank you.

Jas Man

146

18.1 Legacy Series / Re: OpenDNS Autoupdate?

« on: June 30, 2018, 04:18:47 pm »

Hey,
I'm having the same issue with OPNsense 18.1.10.

My public IP address is located on an DSL modem, because it don't allow PPPoE passthrough. Therefore the WAN interface of my OPNsense has an privat address within the LAN subnet of the DSL modem.

Every time the WAN address has changed, I need to press the "Test/Update" button to update the address in OpenDNS. A reboot of OPNsense don't update the address as well.

Is this a normal behaviour because the public address is not located to the WAN interface of the OPNsense? If yes, can I cron the update process of the OpenDNS plugin?

Thanks.
Jas Man

147

German - Deutsch / Re: Probleme mit DMZ bzw. anderen Subnetze

« on: June 06, 2018, 07:24:19 am »

Anhand Deines Screenshots (https://cloud.froechtenicht.de/index.php/s/JTmmkYXpXa98Gk2):

Regel 1: Erlaubt den Zugriff aus allen Netzen auf die Management Oberfläche der OPNsense über die IP des LAN Adapters.
Regel 2:  Erlaubt den Zugriff aus dem OpenVPN Netz in alle Subnetze des LANs / hinter dem LAN Adapter
Regel 3: Erlaubt Zugriff aus dem LAN Netz auf Standard Services (DNS, NTP, DHCP) über die IP des LAN Adapters.
Regel 4: Verbietet den Zugriff aus dem LAN Netz in alle anderen lokalen Subnetze
Regel 5: Erlaub den Zugriff aus dem LAN Netz in alle anderen Netze (auch Extern)

Bei einem eingehenden Paket arbeitet die Firewall die Regel nacheinander ab, bis eine Regel passt/matcht. Sobald eine passt werden die nachfolgenden Regeln nicht mehr verarbeitet. Passt keine Regel, wird das Paket durch die Default-Deny-Rule abgelehnt.
Nehmen wir als Beispiel mal eine DNS Anfrage aus Deinem LAN zur OPNsense. Die Regel 1 und 2 passen hier nicht. Das Paket rutscht bis zur Regel 3 durch und hier passt es. Es wird gemäß der Regel die Aktion "Allow" ausgeführt. Fertig. Die nachfolgenden Regeln werden nicht mehr beachtet.
Wenn Du z.B. als Regel 4 eine identische Regel wie Regel 3 nur mit der Aktion "Deny" hättest, würde DNS weiterhin erlaubt da die "Allow" Regel vor der "Deny" Regel steht.

148

German - Deutsch / Re: Probleme mit DMZ bzw. anderen Subnetze

« on: June 05, 2018, 09:13:59 pm »

Schön das es jetzt geht. Verstehe aber immer noch nicht warum die von mir vorgeschlagenen Regeln nicht funzten.

...
Am Einfachsten ist die Regelverarbeitung, wenn man auf Kniffe wie "!<alias>" verzichtet, denn das kann an anderen Stellen wieder seltsame Nebeneffekte haben.
...

Ich nutze für alle meine Regeln, die Zugriff auf Dienste im Internet erlauben sollen, als Destination !LAN_Netze. Damit möchte ich einfach sicherstellen, dass eine Regel nicht doch den Zugriff in ein anderes LAN Subnetz ermöglicht, weil sie an einer falschen Stelle der Reihenfolge steht. Ab einer gewissen Anzahl von Regeln wird es (zumindestens für mich) leicht unübersichtlich.
Aber beides funktioniert, man spart sich nur die ein oder andere Regel.

149

German - Deutsch / Re: Probleme mit DMZ bzw. anderen Subnetze

« on: June 05, 2018, 09:25:20 am »

Im Regelwerk ist standardmässig eine "let out anything from firewall host itself" Regel drin.
Du kannst die effektive Regeltabelle unter "Firewall -> Diagnostics -> pfTop -> View Type: Label" ansehen.
...

Yep, das meinte ich. Danke.

Also wir können nun defintiv sagen, dass das Pingtool von der Sense nichts taugt.
...

Mit der o.g. Option sollte der Ping auch nicht mehr funktionieren.

...
Meine Freundin ist von der Nachtschicht gekommen und es geht nichts. Kein Internet keine Hue Steuerung nichts.
Also funktionieren die Regeln wie oben in meinen Screenshots... aber es geht nichts raus.

Habe jetzt auf dem LAN Interface nur die eine Regel "Default allow LAN to any rule" wieder aktiv, damit es läuft...

Das zeigt das die Regeln ziehen und im Standard alles geblockt wird. M.E. ist alles gut. Das Problem liegt im Regelwerk.

150

German - Deutsch / Re: Probleme mit DMZ bzw. anderen Subnetze

« on: June 05, 2018, 07:16:41 am »

Sieht eigentlich alles gut aus. Ich überlege gerade ob es eine Option gibt, die die Firewall Interfaces generell erlaubt, egal welche Regeln sonst existieren.

Was ist denn, wenn Du alle Regeln deaktivierst? Kommst Du dann noch raus ins Internet?