1
23.1 Legacy Series / Re: Kernel panic and boot loop when setting a vlan's parent to itself
« on: April 19, 2023, 10:30:34 pm »
Done.
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
23.1 Legacy Series / Kernel panic and boot loop when setting a vlan's parent to itself
« on: April 19, 2023, 10:08:39 pm »
Hi all,
during a lab session my students created a new VLAN with parent set to LAN. Then they modified the VLAN settings and chose the VLAN itself as the VLAN's parent. When clicking "Apply" OPNsense crashes immediately with a kernel panic and reboots after some time.
Since the configuration has been saved, OPNsense now crashes on each subsequent reboot causing a boot loop and making OPNsense unusable. I had to boot into single user mode and replace the configuration with a known good one to be able to get it back up and running.
This is on a Deciso DEC2685 running OPNsense 23.1.5_2-amd64.
Thanks
Arno
P.S.: I know that this setting doesn't make sense and probably not a lot of people tried that before, but since my students ran into it, it makes sense to me to report this issue.
during a lab session my students created a new VLAN with parent set to LAN. Then they modified the VLAN settings and chose the VLAN itself as the VLAN's parent. When clicking "Apply" OPNsense crashes immediately with a kernel panic and reboots after some time.
Since the configuration has been saved, OPNsense now crashes on each subsequent reboot causing a boot loop and making OPNsense unusable. I had to boot into single user mode and replace the configuration with a known good one to be able to get it back up and running.
This is on a Deciso DEC2685 running OPNsense 23.1.5_2-amd64.
Thanks
Arno
P.S.: I know that this setting doesn't make sense and probably not a lot of people tried that before, but since my students ran into it, it makes sense to me to report this issue.
3
23.1 Legacy Series / Re: Firewall: Diagnostics: Aliases / add address / remove address works for 30 secon
« on: April 19, 2023, 09:55:38 pm »
I am not sure, if I understand your question correctly, but you can create aliases in "Firewall" > "Aliases". When you do it there, they should stick.
The IP address disappears, because the aliases tables are recreated periodically from what has been configured for an alias.
The IP address disappears, because the aliases tables are recreated periodically from what has been configured for an alias.
4
23.1 Legacy Series / Re: Protectli F2C OPT1 Netgear AP not seeing internet
« on: April 18, 2023, 06:40:29 am »
Did you set up firewall rules for the WiFi network? Only the first network (LAN) gets default rules to allow all.
Only some rules are created automatically on additional interfaces, like rules for DHCP. If you want this network to be able to access the internet, you have to create some rules manually. Also take a look what has been configured for NAT. Can't tell whether this is needed, since the interesting part of the addresses have been redacted.
Only some rules are created automatically on additional interfaces, like rules for DHCP. If you want this network to be able to access the internet, you have to create some rules manually. Also take a look what has been configured for NAT. Can't tell whether this is needed, since the interesting part of the addresses have been redacted.
5
23.1 Legacy Series / Re: Network alias not working
« on: April 12, 2023, 07:36:44 pm »
We were running OPNsense 23.1.5. I just updated to OPNsense 23.1.5_4 and now the alias seems to be restored shortly after clicking the flush button.
Thanks for the help! :-)
Thanks for the help! :-)
6
23.1 Legacy Series / [Solved] Network alias not working
« on: April 11, 2023, 11:13:50 am »
Hi all,
today we ran into the situation that a firewall rule didn't work. The rule uses a network alias called "localnetworks" for network 10.197.216.0/21 as destination. Traffic to this network should be rejected, but the rule never matched.
The configuration of the alias looked ok to me. The alias was enabled.
When looking at "Firewall" - "Diagnostics" - "Aliases" and choosing the alias "localnetworks" from the dropdown there is no entry in the table. The table is empty.
What fixed it for us: Disable the alias, click "Apply", enable the alias again, click "Apply". Now the table is the Diagnostic area is populated again and the rule matches.
So far, so good.
Now when I click "Flush" in the diagnostic area, the network "10.197.216.0/21" is removed from the table. After this, the table stays empty. Looking at the documentation, this table should be repopulated immediately (cf. the Warning at the end of this section https://docs.opnsense.org/manual/aliases.html#hosts).
Is this the expected behavior here, i.e. should the table be left empty? If so, clicking flush has serious implications regarding the firewall rules.
Thanks
Arno
today we ran into the situation that a firewall rule didn't work. The rule uses a network alias called "localnetworks" for network 10.197.216.0/21 as destination. Traffic to this network should be rejected, but the rule never matched.
The configuration of the alias looked ok to me. The alias was enabled.
When looking at "Firewall" - "Diagnostics" - "Aliases" and choosing the alias "localnetworks" from the dropdown there is no entry in the table. The table is empty.
What fixed it for us: Disable the alias, click "Apply", enable the alias again, click "Apply". Now the table is the Diagnostic area is populated again and the rule matches.
So far, so good.
Now when I click "Flush" in the diagnostic area, the network "10.197.216.0/21" is removed from the table. After this, the table stays empty. Looking at the documentation, this table should be repopulated immediately (cf. the Warning at the end of this section https://docs.opnsense.org/manual/aliases.html#hosts).
Is this the expected behavior here, i.e. should the table be left empty? If so, clicking flush has serious implications regarding the firewall rules.
Thanks
Arno
7
23.1 Legacy Series / Unbound recommended configuration for reverse lookup for private IPv4 addresses?
« on: February 23, 2023, 10:29:14 pm »
Hi all,
we are running OPNsense as a router for a smaller network inside another larger network. The inner network contains hosts with private IPv4 addresses only. The outer network contains subnets with public IPv4 addresses and also subnets with private IPv4 addresses. The hosts all have DNS entries in the larger network's DNS.
To be able to resolve the hostnames with the private IPv4 addresses in the outer network from within the inner network, we configured Unbound to forward queries to the outer network's DNS servers and we also disabled the DNS Rebind Check. This works for forward lookups. So far so good.
Though, with this setup reverse lookups for hosts in the outer network with private IPv4 addresses don't work because Unbound does not forward these queries to the upstream DNS servers in the outer network. This is expected and documented behavior. To work around this, we added "unblock-lan-zones: yes" to the "server" clause with a template as described in the OPNsense documentation. This seems to work - until now we haven't seen unwanted side effects.
Now the question is: is this a sensible configuration? Or should we refrain from this approach and take a different route? I would love to hear your recommendations.
Thanks
Arno
we are running OPNsense as a router for a smaller network inside another larger network. The inner network contains hosts with private IPv4 addresses only. The outer network contains subnets with public IPv4 addresses and also subnets with private IPv4 addresses. The hosts all have DNS entries in the larger network's DNS.
To be able to resolve the hostnames with the private IPv4 addresses in the outer network from within the inner network, we configured Unbound to forward queries to the outer network's DNS servers and we also disabled the DNS Rebind Check. This works for forward lookups. So far so good.
Though, with this setup reverse lookups for hosts in the outer network with private IPv4 addresses don't work because Unbound does not forward these queries to the upstream DNS servers in the outer network. This is expected and documented behavior. To work around this, we added "unblock-lan-zones: yes" to the "server" clause with a template as described in the OPNsense documentation. This seems to work - until now we haven't seen unwanted side effects.
Now the question is: is this a sensible configuration? Or should we refrain from this approach and take a different route? I would love to hear your recommendations.
Thanks
Arno
8
22.1 Legacy Series / Re: Disable/tune sshlockout
« on: July 05, 2022, 06:37:16 pm »
Hi Franco,
I edited /usr/local/opnsense/service/templates/OPNsense/Syslog/syslog-ng-lockout.conf like this:
After reloading syslog-ng from the Dashboard this change is reflected in /usr/local/etc/syslog-ng.conf.d/syslog-ng-lockout.conf.
If I understand the code in /usr/local/opnsense/scripts/syslog/lockout_handler correctly, my changes result in the following behaviour:
A few tests show that, this works for me. I just wanted to clarify that I got this right. One thing to notice: there is a fixed value of two seconds set in lockout_handler, for which log entries are considered to belong to the same login attempt. Therefore, a lot of login attempts in quick succession might fall through the gap (if I understand the code correctly).
Is this on purpose to keep the entry in the list forever?
I will submit a ticket to make this configurable form the GUI for a future release. :-)
Thanks
Arno
I edited /usr/local/opnsense/service/templates/OPNsense/Syslog/syslog-ng-lockout.conf like this:
Code: [Select]
filter f_local_lockout_auth {
facility(auth);
};
destination d_local_lockout_auth {
program("/usr/local/opnsense/scripts/syslog/lockout_handler --attempts 12 --grace_period 60");
};
log {
source(s_all);
filter(f_local_lockout_auth);
destination(d_local_lockout_auth);
};After reloading syslog-ng from the Dashboard this change is reflected in /usr/local/etc/syslog-ng.conf.d/syslog-ng-lockout.conf.
If I understand the code in /usr/local/opnsense/scripts/syslog/lockout_handler correctly, my changes result in the following behaviour:
- After 12 consecutive failed login attempts from a specific host during a period of 60 seconds, this host is added to the sshlockout table.
- The host will stay in this table until the router is being rebooted or the entry is being removed from the table manually, e.g. by issuing pfctl -t sshlockout -T delete a.b.c.d.
- When the host doesn't try to login for 60 seconds, it is being removed from the internal dicts and the counter is being reset, although it is not being removed from the table.
A few tests show that, this works for me. I just wanted to clarify that I got this right. One thing to notice: there is a fixed value of two seconds set in lockout_handler, for which log entries are considered to belong to the same login attempt. Therefore, a lot of login attempts in quick succession might fall through the gap (if I understand the code correctly).
Is this on purpose to keep the entry in the list forever?
I will submit a ticket to make this configurable form the GUI for a future release. :-)
Thanks
Arno
9
22.1 Legacy Series / Re: Disable/tune sshlockout
« on: July 05, 2022, 05:33:15 pm »
Hi Franco,
yeah, I just figured, that anti-lockout is different than sshlockout. :-)
Just for the record: I tried Vilhonator's suggestions and OPNsense would still add the machine to the sshlockout table. Since this table is used in a floating rule, which cannot be disabled from the GUI, the lockout is still enforced.
I will try to edit the syslog-ng-lockout.conf and report back.
Thanks
Arno
yeah, I just figured, that anti-lockout is different than sshlockout. :-)
Just for the record: I tried Vilhonator's suggestions and OPNsense would still add the machine to the sshlockout table. Since this table is used in a floating rule, which cannot be disabled from the GUI, the lockout is still enforced.
I will try to edit the syslog-ng-lockout.conf and report back.
Thanks
Arno
10
22.1 Legacy Series / Re: Disable/tune sshlockout
« on: July 05, 2022, 02:09:27 pm »
Thanks, will take a look at it. :-)
11
22.1 Legacy Series / Disable/tune sshlockout
« on: July 04, 2022, 06:10:51 pm »
Hi all,
I am teaching networking technologies for media networks at a university of applied sciences in Germany, where I heavily rely on OPNsense as the main router distribution for teaching and for our internal media networks.
Students can use OPNsense in our lab networks for their practical exercises. Now, it sometimes happens that students repeatedly enter the wrong user credentials for the Web GUI and the sshlockout kicks in. The only way to circumvent the 60 minute lockout is to restart the router which seems to clear the sshlockout table (or to connect from a different IP address and carry on with their tasks from this other machine).
Is there a way to either disable the lockout functionality for the lab routers or to tune the number of failed login attempts to a much higher value?
Any hint is much appreciated!
Thanks
Arno
I am teaching networking technologies for media networks at a university of applied sciences in Germany, where I heavily rely on OPNsense as the main router distribution for teaching and for our internal media networks.
Students can use OPNsense in our lab networks for their practical exercises. Now, it sometimes happens that students repeatedly enter the wrong user credentials for the Web GUI and the sshlockout kicks in. The only way to circumvent the 60 minute lockout is to restart the router which seems to clear the sshlockout table (or to connect from a different IP address and carry on with their tasks from this other machine).
Is there a way to either disable the lockout functionality for the lab routers or to tune the number of failed login attempts to a much higher value?
Any hint is much appreciated!
Thanks
Arno
12
German - Deutsch / Re: Telekom VoIP hinter Opnsense
« on: November 22, 2016, 09:53:57 am »
Die Telekom benutzt anscheinend Symmetric RTP (http://www.voip-info.org/wiki/view/RTP+Symmetric). Hierbei schickt der VoIP-Server von der Telekom die RTP-Pakete auf den gleichen Port von dem sie vom Telefon zur Telekom gekommen sind. Da das Telefon ein RTP-Paket selber rausschickt, ist der UPD-Port dann offen und kann genutzt werden, bis der Timeout für die UPD-Session zuschlägt. Den Port kann man aber offen halten, indem man das Telefon öfter ein NAT-Refresh schicken lässt.
Bei mir auf dem VoIP-Telefon (Gigaset SL450A GO) habe ich das STUN deaktiviert und die NAT-Refreshzeit auf 20 Sekunden gesetzt. Das funktioniert so ohne weitere Konfiguration auf der pfSense mit ein- und ausgehenden Anrufen.
Bei mir auf dem VoIP-Telefon (Gigaset SL450A GO) habe ich das STUN deaktiviert und die NAT-Refreshzeit auf 20 Sekunden gesetzt. Das funktioniert so ohne weitere Konfiguration auf der pfSense mit ein- und ausgehenden Anrufen.
Pages: [1]