@Ethan-TP Thanks, solved.

Back to square 1. For whatever reason my ER8411 rebooted middle of a night last week. Since then same errors as before - although nothing changed setup-wise (i.e., the working setup with disabled DPI). iPhones constantly again ask for iCloud account verification (which then does not work - only a spinning wheel is presented), Several Apps run into timeouts or claim to have no internet access, some websites are partly non-functional resp. take a long time to present content, etc. Errors do not appear if devices connect to the internet via a VPN, Apps and websites then run smoothly. All of this was not the case with FW1.2.x.

What I also notice is that each router reboot regularly ends in a "PADI time out" situation (connect via PPPoE). This never happened with FW 1.2.x. No idea if this hangs together, but it's an observation made.

Are any workarounds known?

Thanks!

  @Omada Team - Are there already plans re. another / correcting firmware update? 
Thanks!

I am also having a very unique issue with 1.3.6 which i have narrowed down to VPN>LAN conversion - Conntrack / Session Tracking / NAT / De-encapsulation etc - something is messed up

I have a BirdDog camera on a remote site which is ER605v2 based.  Over its otherwise fully stable and functional site-to-site IPsec VPN, THE MOMENT i load the camera's GUI on any client on my main site, the following happens quickly

- All GUI access to anything on the remote site dies - Gateway / Switch GUIs etc all non responsive

- I can still ping everything on the remote site

- Remote site all SDN devices start with a Heartbeat Missed > Adopting > Adopt Failed loop

- Everything immediately returns to normal after rebooting main site ER8411 - until i load the camera GUI again.....

Full diagnostic data, logs etc already sent to the team

Further Testing:

If i terminate the VPNS to a ER7206 v2 or a ER605 v2 and do a route based injection to and from my main network the following happens when i load the camera gui

- Camera and other GUIs work for approximately 3 minutes ....then....

- All GUI access to anything on the remote site dies - Gateway / Switch GUIs etc all non responsive  ...then after about 5 minutes....

- All GUIs work again

- goto top...infinite loop

So - there seems to be some bug regarding this shared amongst models with all the recent firmwares, but ER8411 is the only one that doesnt recover itself to some degree and is the only model that causes the remote sites to go into the adopting loops.  In my case  the trigger appears to be complex multi-protocol devices (RTSP/ONVIF/HTTP/UDP) over IPsec

-ST

@Omada Team - are there any plans for correcting firmware update? 
 

Looks like people are still having many issues with fw 1.3.6 and the ER8411 V1.0 including me. 
Changing MTU size on clients, disabling IDS/IPS, DPI, DNS Proxy etc. to get the device somehow working is not my understanding how a "flagship business gateway" should work. 

Many thanks! 

  @-CyRaX- 

What about machines with a static IP, i.e. not being serviced by DHCP?

Have network scanners which I had to connect via USB to a machine, as network scanning no more worked after the ER 1.3.6 update of last October.

They have a fixed IP. 

Setup:

• ER8411 v1, firmware 1.3.6
• PPPoE connection, MTU/MRU 1492
• OC200 controller v1.38.1

Symptom: Certain apps fail on first connection attempt with MSS clamping enabled (any value). Retry sometimes succeeds. Apps work fine with MSS clamping disabled.

With MSS clamping DISABLED — working correctlyish:

# First attempt — hits problematic server (MSS 1392), fails as expected
IP 10.0.0.1.xxxxx > SERVER_A.443: [SEW] mss 1460
IP SERVER_A.443 > 10.0.0.1.xxxxx: [S.] mss 1392
IP 10.0.0.1.xxxxx > SERVER_A.443: [R] RST — app rejects low MSS

# Retry — hits correct server, succeeds
IP 10.0.0.1.xxxxx > SERVER_B.443: [SEW] mss 1452
IP SERVER_B.443 > 10.0.0.1.xxxxx: [S.E] mss 1452
# Full TLS handshake completes successfully ✅

With MSS clamping set to 1452 (same with auto) — broken:

# First attempt — same SERVER_A failure as above

# Retry — should work but ER8411 breaks it
IP 10.0.0.1.xxxxx > SERVER_B.443: [SEW] mss 1460  ← Mac advertises 1460
IP SERVER_B.443 > 10.0.0.1.xxxxx: [S.E] mss 1452  ← Server correctly clamps to 1452
IP 10.0.0.1.xxxxx > SERVER_B.443: [.] seq 1:1453   ← Data starts flowing
IP SERVER_B.443 > 10.0.0.1.xxxxx: [.] ack 1453     ← Server ACKs correctly

# Connection stalls for exactly 30 seconds then:
IP 10.0.0.1.xxxxx > SERVER_B.443: [R.] seq 1520    ← RST kills connection ❌

# Third attempt also fails — falls back to SERVER_A which also fails ❌

Root cause identified: ER8411 v1 firmware 1.3.6 MSS clamping incorrectly interferes with already-established connections. The SYN handshake completes with correct MSS 1452 but the ER8411 then stalls the connection mid-transfer, causing macOS to send RST after 30 seconds.

MSS clamping should only modify the SYN/SYN-ACK packets, not interfere with established connections.

Workaround: Disable MSS clamping entirely. Note this may break other applications that require strict PPPoE MSS enforcement.

Expected fix: ER8411 firmware update to correctly implement MSS clamping on PPPoE connections.

Hardware: ER8411 v1 (not v2) Firmware: 1.3.6 Build 20251028 Rel.12399 ISP type: PPPoE MTU: 1492

Workaround:
Set MTU to 1452 on your Mac permanently:

# Temporary test (resets on reboot)
sudo ifconfig en0 mtu 1452

# Permanent fix
# System Settings → Network → your connection → Details → Hardware → MTU → Custom → 1452
By setting the Mac MTU to 1452, packets never exceed the PPPoE MTU limit so no clamping is needed at the router level at all.