Messages

So just to confirm the 13.1 base beta:
# opnsense-update -bkzr 22.7.b
# opnsense-shell reboot

appears to have solved my vlan issues on the i225, I assume there's some updates in the igc driver which have resolved things.

I look forward to the official 22.7 release!

I just lost a few hours troubleshooting a failed migration to a similar 4xi225-V box (an aliexpress N5105 special).

I have multiple VLANs on my LAN interface and don't have (full) connectivity on those interfaces. Notably I did appear to have ICMP and ARP connectivity to the switch, but DHCP and WEB UI didn't work. I didn't do any network captures but it smells like IP offload is broken in the igc driver. I think you've come to the same conclusion given your driver updates seem to improve things.

Doing an interface re-config back to a non-VLAN interface worked fine.

If I get some more time I'll try the 22.7 prerelease to confirm.

[This leads to 2 issues:]

I have two issues that I'd like to solve and have some ideas of how we might solve them. Any feedback on alternative workarounds or how we could progress these ideas would be welcome.

My ISP (Aussie Broadband, in Australia) is a retail service provider that wholesales the Australia NBN network. This NBN network uses many last mile technologies, including VDSL2 (FTTN), DOCSISxx (NFC) and FTTP amongst others. Some of these last mile technologies, specifically the DSL and DOCSIS based tech use fairly unreliable copper links and as such many, including myself suffer from frequent physical layer issues.

Unfortunately due to the nature of the network (the mixed technologies), the provider doesn't have insight into drop outs (e.g. loss of DSL sync). They also use IPoE rather than use a PPPoE tunnel. This means they effectively see a layer 2 service to each of their customers (often fairly lossy due to the drop outs) regardless of last mile technology.

I use a VDSL2 modem bridged to my x86 opnsense box like many others and the VDSL2 sync drops are not seen by opnsense.

When the ISP provided modem is in place, the DSL sync drop out causes the modem to restart the interface and re-DHCP. The ISP uses their DHCP logs to infer when the physical link might be dropping.

This leads to 2 issues:

1.  When I have the opnsense box in place and I have such drop outs, the ISP does not believe me and are unable to escalate the fault. For _very_ unreliable connections, the wholesaler does raise a fault, but this is for something very severe (don't quote me on this), something like 10 drops in 24 hrs. This forces me to swop back in the ISP provided modem, often for weeks on end. This limits the complexity of my network, as I need it to be compatible with migration back to the ISP modem.

2. During some outages, the ISP will bounce the DSLAM port without expiring the DHCP lease, relying on the modem to re-DHCP. With opnsense being the DHCP client, this doesn't happen and I have to manually renew the lease.

A few solutions come to mind:

1. Replacing the VDSL2 modem and opnsense box with an all-in-one device that has a real VDSL2 interface so can handle the loss of sync more intelligently. Cisco etc comes to mind. I don't want to do this, as I like opnsense.

2. Somehow instruct the opnsense box to re-DHCP when the modem loses sync/regains sync.
a) Gateway pinger timeout could infer loss of sync, though the timing isn't as good as the sync coming back up. DHCP could be repeatedly retried, this would solve problems 1 + 2 as long as the gateway pinger interval is sufficiently short to detect a sync down/up event.
b) Watching syslog messages from the modem, when a sync up log message is logged, then re-DHCP.

In terms of performance 2b would be best as it only attempts the DHCP when the link is actually back up but is very hard to setup and/or generalise for other users/modems.

Proposal
My proposal would be to add an option to the gateway pinger, that for a DHCP interface (or perhaps even PPPoE) intefaces that when the pinger times out, that it would repeatedly attempt DHCP until a DHCP renewal can be processed or perhaps easier to implement might be to down/up the interface during such an event.

Hopefully this would serve to improve reliability for those behind a wide variety of bridged modems and connection types and allow me to embrace opnsense in my network!