USG110 - unintended DHCP Relay after installing CVE-2020-9054?

USG_User

On weekend we have remotely installed the a.m. vulnerability patch on our USG110. Works fine so far. But directly after USG reboot I didn't get access to my office computer via RDP because a new IP has been assigned, but not from USG DHCP (as ususal) but from our ISP access router which resides in another subnet behind the USG.

Now (Monday morning) I just rebooted my computer manually and all works fine again, including a regular IP assignment from our LAN1 Ethernet IP range.

Also checked the USG settings for the affected interface. Still set to DHCP Server but not DHCP Relay:

Has anybody an idea why the USG has relayed the DHCP request? This happened never before.

Zyxel_Jerry

Hi @USG_User

We haven't heard this kind of symptom before.

Can you share more details of your topology with IP address ?

If it is replicable, can you collect the packet on pc for us ?

USG_User

Hi Jerry,

I will send you a PM with our topology.

Fortunately this behaviour is not replicable until now, but we can't reboot the USG every day to check this, since this is a productive system.

It was a one and only case until now and never experienced before, but we found it worth to report it to you.

USG_User

Yesterday, when we tried to remotely update the USG110 to the last FW 4.35 AAPH.3, it happened again. My remotely operated machine at office lost its IP and got a new IP from ISP ISP internet connection router as already described above in my start thread, although the USG110 LAN1 interface is set up as DHCP server but not as DHCP relay.

Here is my scenario for reproducing the issue:

Conditions:

• Access to USG config GUI is only possible from LAN1 interface. (But updating the FW is mostly only possible on weekend from home since during office hours we cannot reboot the firewall.)
• Home computer is connecting via SecuExtender (current version) SSL VPN to USG and has access to LAN1 zone only
• USG is DHCP server for LAN1 interface, where particular computers are always getting a fix IP address from range 192.168.21.x, but without MAC/IP binding since there are a lot of other machines in LAN1 getting a dynamic IP from DHCP.
• ISP internet access router is not in bridge mode but is working as additional router with different port forwarding rules

Procedure:

• Establishing the SSL VPN tunnel to USG. ISP access router is forwarding the SSL VPN port to USG.
• Starting the office computer via "magic packet" (by activating a script from intranet webserver)
• Waiting a few seconds until the office computer has booted
• Starting a Windows RDP session from home computer to office computer by using the fix IP address for that office pc
• Starting web browser at the office pc and connecting to USG Config GUI over LAN1.
• Uploading the new firmware onto the USG without rebooting
• Rebooting the USG

At the moment of USG reboot the RDP session and the SSL VPN tunnel are getting lost. Now we are waiting for different monitoring scripts running on other machines. They are reporting a lost internet connection and also when the connection is re-established again. As soon as we get the e-mail (rebooting of USG takes always a few minutes) we know USG is alive again and has connected to internet.

Now I re-establish the SSL VPN tunnel. This works so far. But now I try to re-connect to my office pc via RDP again. But a new RDP session or reconnect to the running RDP session is impossible since my computer has suddenly a new IP address from range 192.168.178.x, assigned from the ISP access router. On Monday morning, when I'm back in the office, I restart my computer manually and the well-known fix IP 192.168.21.x will be assigned again from USG and all is in good order again.

For better understanding please find an extract from our topology as follows:

From our point of view a firewall must never forward DHCP requests if not adjusted. It seems during reboot procedure the DHCP service of the USG has an undefinded state where DHCP requests will be forwared.

Of course we could deactivate the DHCP server at the ISP router but we need it for address assignment of other clients in the 192.168.178.0 subnet.

Zyxel_Jerry

Hi @USG_User

Can you share what boot module version is your device current using?

After device reboot, it will show on the console log, can you help to collect the version for us?

USG_User

Hi Jerry,

Thanks for quick reply.

Could you kindly give me some more hints how I could call the Boot Module Version and whether the USG has to be rebooted therefore again?

I've only have some experiences with the webconsole of the USG. But after login I have to type some additional commands to get any infos.

USG_User

Hi Jerry,

Still waiting for any reply in this regard.

Zyxel_Jerry

Hi @USG_User

You can use SSH to the device and type the command below:

Here is the config to check the Boot Module Version

Router> psm

Router(psm)# atsh

USG_User

Thanks Jerry,

Here is the requested information:

BootModule Version : V1.08 | 08/15/2013 10:45:46

USG_User