Topics

I have two pppoe WAN interfaces, WAN (pppoe0) and WAN2(pppoe1), only the first of which is in active use.

Thus, only WAN ist active under System->Gateways->Single. The other interface is a standby fallback, although it is online most of the time.

Whenever pppoe1 gets a new IP, /usr/local/etc/rc.newwanip gets called, which I can see by these log entries:

Code Select Expand


Apr 26 09:38:35 OPNsense.mgsoft opnsense[77773]: /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'pppoe1'
Apr 26 09:38:35 OPNsense.mgsoft opnsense[77773]: /usr/local/etc/rc.newwanip: On (IP address: 87.158.128.89) (interface: WAN2[opt11]) (real interface: pppoe1).
Apr 26 09:38:35 OPNsense.mgsoft opnsense[88206]: /usr/local/etc/rc.newwanipv6: IPv6 renewal is starting on 'pppoe1'
Apr 26 09:38:35 OPNsense.mgsoft opnsense[88206]: /usr/local/etc/rc.newwanipv6: On (IP address: ) (interface: WAN2[opt11]) (real interface: pppoe1).
Apr 26 09:38:35 OPNsense.mgsoft opnsense[88206]: /usr/local/etc/rc.newwanipv6: Failed to detect IP for WAN2[opt11]
Apr 26 09:38:35 OPNsense.mgsoft opnsense[77773]: /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'opt11'
Apr 26 09:38:35 OPNsense.mgsoft opnsense[77773]: /usr/local/etc/rc.newwanip: ROUTING: IPv4 default gateway set to wan
Apr 26 09:38:35 OPNsense.mgsoft opnsense[77773]: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv4 default route
Apr 26 09:38:35 OPNsense.mgsoft opnsense[77773]: /usr/local/etc/rc.newwanip: ROUTING: IPv6 default gateway set to wan
Apr 26 09:38:35 OPNsense.mgsoft opnsense[77773]: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv6 default route
Apr 26 09:38:35 OPNsense.mgsoft opnsense[77773]: /usr/local/etc/rc.newwanip: The WAN_DHCP6 monitor address is empty, skipping.
Apr 26 09:38:35 OPNsense.mgsoft opnsense[77773]: /usr/local/etc/rc.newwanip: The WAN_PPPOE monitor address is empty, skipping.
Apr 26 09:38:35 OPNsense.mgsoft opnsense[77773]: /usr/local/etc/rc.newwanip: The WAN2_GW monitor address is empty, skipping.
Apr 26 09:38:35 OPNsense.mgsoft opnsense[77773]: /usr/local/etc/rc.newwanip: The WAN2_PPPOE monitor address is empty, skipping.
Apr 26 09:38:36 OPNsense.mgsoft opnsense[77773]: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface WAN2.


I this situation, there seems to be a problem when the new default route gets set: Every open TCP connection is reset and gets disconnected. This should never happen when these interfaces are disabled on the gateway page - not even if they were active, but lower in priority than existing gateways.

It seems like the route is always deleted and then created again, even if it does not really change.

Whenever I test access on https://opnsense/diag_authentication.php and enter a wrong password (or combination of TOTP and password), I get this error:

Fatal error: Uncaught Error: Call to undefined method OPNsense\Auth\Local::getLastAuthErrors() in /usr/local/www/diag_authentication.php:76 Stack trace: #0 {main} thrown in /usr/local/www/diag_authentication.php on line 76


It seems like the function getLastAuthErrors() is not defined in /usr/local/opnsense/mvc/app/library/OPNsense/Auth/Local.php, only in /usr/local/opnsense/mvc/app/library/OPNsense/Auth/LDAP.php - thus, it cannot be called in the general case.

This error is a little uncomforting, because I do not dare to activate TOTP-based authentication before I can be sure that it works...

I fiddled around with the IDS and never got an alert going, only to find out that the rules tab seems broken.

The rules loaded from the download tab are not enabled per default and if you enable them, the GUI reflects their setting incorrectly: when a rule is enabled, it does not change state visibly, but after you hit "apply" and reload the page, you can see that they are indeed toggled.

I saw this with Opera and Firefox, most likely this is true for any browser.

[seemed]

Today I fought with a mean catch in DHCP: I tried migrating from the Edgerouter 4 and switched one VLAN after another to OpnSense.

I found that the "Response delay" setting in DHCP zones to be a nice feature in order to be able to have the old router come first as long as it is present but have OpnSense take over once it is gone.

This seemed to work, but after the final switch, I found that some VLAN devices did not get any IP reservations despite everything looked fine.

After much trial and error, I found these log entries:

Code Select Expand


Mar 13 16:38:28 OPNsense dhcpd[34310]: DHCPDISCOVER from 00:1d:63:15:73:9f via ixl3_vlan107: configured min-secs value (2) is greater than secs field (0).  message dropped.
Mar 13 16:38:31 OPNsense dhcpd[34310]: DHCPDISCOVER from 00:1d:63:15:73:9f via ixl3_vlan107: configured min-secs value (2) is greater than secs field (0).  message dropped.
Mar 13 16:38:35 OPNsense dhcpd[34310]: DHCPDISCOVER from 00:1d:63:15:73:9f via ixl3_vlan107: configured min-secs value (2) is greater than secs field (0).  message dropped.


Effectively, when you set a response delay, you render the DHCP zone invalid without knowing.

Hi,

I have a setup where my LAN is on a bridge on two physical 10Gbe interfaces because I need both a connection to my switch and one more computer (basically I want to use one 10Gbe interface like a switch port).

So far, this works fine.

However, since I also need a VLAN for a separated IoT network, I tried to establish a VLAN on the LAN bridge. I know how to do this for normal interfaces and it works fine for those.

However, I found that the resulting interface looks strange and does not work:

Code Select Expand


bridge0_vlan107: flags=8003<UP,BROADCAST,MULTICAST> metric 0 mtu 1500
        ether [b]00:00:00:00:00:00[/b]
        inet6 fe80::3eec:efff:fe6c:36da%bridge0_vlan107 prefixlen 64 tentative scopeid 0x11
        inet 192.168.107.2 netmask 0xffffff00 broadcast 192.168.107.255
        groups: vlan
        vlan: [b]0[/b] vlanpcp: 0 parent interface: <none>
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>


The IP works, the network does not:

Code Select Expand


# ping 192.168.107.2
PING 192.168.107.2 (192.168.107.2): 56 data bytes
64 bytes from 192.168.107.2: icmp_seq=0 ttl=64 time=0.103 ms
64 bytes from 192.168.107.2: icmp_seq=1 ttl=64 time=0.066 ms
^C
--- 192.168.107.2 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss

# ping 192.168.107.1
PING 192.168.107.1 (192.168.107.1): 56 data bytes
ping: sendto: Network is down
ping: sendto: Network is down
^C
--- 192.168.107.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss


Note that bridge0_vlan107 has a blank MAC (ether 00:00:00:00:00:00) and no VLAN (0). I think it should inherit the MAC from bridge0 (which seems synthetic, i.e. not one of the interface MACs). Even if I specify that MAC in the webui, it is still not set. I can set it from the command line, though.

For me it seems that both MAC and VLAN are not set correctly for VLANs on bridge interfaces, is that a bug or am I doing something wrong?