I've edited my post too late I guess but there's a screenshot there, I posted some settings that are least to catch your eye, I altered the settings to match yours like PhyR on rather than off like on my ECI, and QoS off since QoS can only be done on the router or between the router and modem [not on the actual modem when it's in Modem-only as opposed to Modem-Router mode].
UPnP can be off with 0 side effects because the router has the firewall set to WAN>LAN block. [upnp also got a port stuck open once on my b10a, but that's in case it wasn't redundant].
Since bridge mode can't tick igmp snooping on the WAN page I think you should set it to off in the LAN page. I think.
There are cases that the firewall being on [should it be on? hm..] prevented static routes from working/being set. so there's that.
Edit: But for bridge mode it is not relevant, since it's router thing. But there's a page about adding it from the CLI when the GUI doesn't work [an example that in special cases you use commands instead of gui]:
https://support.aa.net.uk/VMG1312-B10A:_Static_RoutesWhile at it there's another bug that if in router mode the WAN interface is deactivated, the next time it's re-activated the "Add as Default Gateway" box needs to also be re-ticked.
PPPoE Session-ID caching bug (In Bridge mode)
Issue Description
Last year we had an problem with Huawei FTTC modems, the standard ones that Openreach supply The bug appears to be that the modem manages to "blacklist" some UDP packets after a PPP restart. Typically this affects VPN tunnels. The short term fix is to unplugged and plugged back in!
We now have what looks to be the same fault on the ZyXELs - both on ADSL and VDSL.
When a PPPoE session finishes and a new one starts, ethernet frames containing IP packets with the same source and destination IP and port combination that were used in the previous session are received with the PPPoE Session-ID from the earlier session.
This affects long running sessions using protocols which use the same source port for all communications. This includes IPsec and (in some circumstances) SIP.
Our understanding of this, having talked to Huawei last year to get a very similar bug fixed is that the problem is with the packet accelerator feature in the Broadcom chipset. It is caching frame headers including the PPPoE Session-ID, but not checking if the Session-ID is the same when searching for the entry in the cache for subsequent packets. Unplugging the ethernet cable from the VMG1312 momentarily resolves the problem - that action must trigger a cache flush in the Broadcom chipset.
Possible fixes would be to either not store the Session-ID in the packet accelerator cache at all, or to check the Session-ID in addition to the IP and ports when searching the cache. A workaround would be to disable the packet accelerator.
(Side note for other ISPs looking at this: This does not affect lines that have dynamic WAN addresses, which none of our service do.)
https://support.aa.net.uk/images/7/7b/VMG1312-Menus-Admin.png