noc_aba  Freshman Member

Hi, thanks, I tried your configuration but it didn't work. The only difference, respect to what I did before you answer, is your policy route: incoming tunnel next hop WAN SNAT outgoing-interface I suppose that by tunnel you mean the tunnel between USG110 and USG40, but what I think I need is to SNAT the IP accessing the…

forgot to say I'm on a ATP500 vith fw 5.39 patch1

It happens during the night so nobody is working then. We can't give access to the devices, sorry. The only thing that could be put in relation with the the timeout is that a 2 am the service signatures are updated. regards Paolo

missing console button, vpn wizard, policy control filter, …

thanks, but which are " the new encryption and key exchange methods " regards Paolo

Hello, having the issue on 5.36 (atp800 becomes unresponsive ….) we went back to 5.35, and everything works fine as expected (i.e. as before the upgrade). Of course we are looking forward to a fixed/patched 5.36 so as to address properly the security vulnerability of 5.35. regards Paolo

Hello after upgrde to V.5.36 we have exactly the same issue, as Agor, on a couple of ATP800 in HA. After about 3-4 hours the active ATP800 becomes unresponsive (not even vpn or ssh access) and the only solution is to reboot manually, compelled to be phisically there to do that. Europe zyxel support claims they have not…

To be precise, the deny default rule works only if the destination IP address refers to the atp800 itself. The rule is ignored if the destination IP address (and port) is defined in the NAT section or if is an external IP (ie when internal PC try to access Internet resources)

We have received and installed a new firmware version, that should have fixed the problem. But it didn't. The problem has worsened. Now also the rule we have inserted, just before the default deny rule, is ignored. We had to insert deny rules just after the allow rules. For example after 4 WANtoDMZ allow rules we have…

we have upgraded another couple of atp800 from 4.60 to 4.62 and the same problem occurred; HA is not here anymore and we have to reset the slave and configure HA again. Given this type of problem and given that the atp800 are deployed in a production environment, we can't risk to disrupt service trying debug firmware…

As far as the installation of debug firmware is concerned, we are not at liberty to do that since we are in a full scale deployment and can't do experiment.

Hello we did the upgrade to 4.62. After a couple days the same problem has occurred again and it's still open! Probably after a new security policy rule has been added. So we have activated again the deny-all rule created by us as the last rule before the not-working default deny rule The whole picture is: two ATP800 in…

We are planning to uograde to 4.62 soon.

Well, when I login and atp800 says "there's a new firmware version for download", in this case to fix a couple of vulnerabilities, I assume that it's recommended and safe to upgrade. The problem is: why the configuration of the passive (that was good and running before the upgrade, when the atp800 was active) got damaged…