VPN Tunnel Blocked Due to IP Being Blacklisted, Adding IP to Allow List Doesn't Fix It

NEP

Hello,

On Monday we had an issue with our main Public IP getting on the Spamhaus blacklist. The underlying issue was resolved on Tuesday and the IP was removed from the blacklist.

Fast forward to Thursday and one of our site-to-site IPSec VPNs stopped working. Oddly enough, the interface shows a green globe like the connection is established. This can even be seen in the logs on the local side. The IKE entries appear to indicate a successful connection.

I didn't put two and two together (because it was days later) but it runs on that same IP that was blocked. After figuring out that the IP was blocked by the remote site (not visible on local where I am) by "Scanners, high" I added the IP to the IP Reputation Allow List. Doing so did not immediately fix the issue. Jumped back to the General tab and toggled IP Blocking off and on. This fixed the issue immediately.

Went to bed thinking this was fixed only for it to be down again on Friday. The same issue can be seen in the logs... "Warn IP Reputation Malicious connection:Scanners ACCESS BLOCK". I toggled it again at 8:44AM and everything started working. Then at 1:45PM I received a text saying it was down. I can't say when it failed in the night, but based on the prior occurrence I'm expecting that come 6:45PM it is going to be down again.

My question is, why is this happening? From what I've read the "Allow List" is supposed to trump whatever may be in the list. Also, why does simply toggling "IP Blocking" off and on fix the issue? That makes no sense given that no other changes are made. This makes it seems like it takes "hours" for the blocking to start back up, which I find hard to believe. To me it seems like a bug but I cannot say for sure.

In case it matters, this is an ATP200 running the latest 5.43(ABFW.0) firmware. It was updated this past weekend. Naturally, it also has an active UTM subscription.

Thanks for your help!

PeterUK

Would seem like a bug

the off/on likely fixes it to reset the cache list and I'm thinking the bug it the Reputation updates and show the IP as bad even if the Allow List should allow it.

NEP

Thanks Peter. As an update, the connection has not dropped since the initial two times. Maybe I just didn't click Apply when adding the IP to the Allow List, though that doesn't explain the toggle working. I'm not sure what to think.

Zyxel_Tina

Hi @NEP,

Based on your description, the ATP200's public IP is being blocked by the remote site / peer firewall via IP Reputation ("Scanners, high"). Adding the IP to that firewall's Allow List did not take effect, while toggling IP Blocking off and on restored the tunnel — so we would like to look into the behavior on the blocking device itself.

Could you let us know the model and firmware version of the remote site / peer firewall?

To investigate further, we would also need access to that device:

• If the remote site device is managed via Nebula: please enable Zyxel Support Access and share the organization/site names with us
• If the remote site device is in standalone mode: please follow this guide to allow us GUI access from WAN

In addition, if the issue happens again, please collect the diagnostic file from the remote site device and send it to us via PM for further analysis.

NEP

@Zyxel_Tina The remote side is that ATP200. The local side being an ATP800 with the last firmware. The ATP200 (remote) was blocking the ATP800 (local) IP. I'm fine with saying that I did not click Apply when adding the local IP to the Allow List of the remote device, however, why did toggling "Enable blocking" allow this to work temporarily? Was it as PeterUK said that the cache was cleared and there is so period of time before it's redownloaded?

That said, I set up a ping which ran every minute through the weekend and there were no drops. Based on that I'll chalk this up as solved, no remote access necessary, though hopefully you can explain the above questions. Thanks.

NEP

There haven't been any issues with this for the last week. Suppose that means it's solved.

However, I would love to have an answer to the "Enable blocking" question above before closing it.

Zyxel_Tina

Hi @NEP,

Thanks for your patience!

After checking with our team, please allow us to clarify that the IP Reputation Allow List applies to forwarding traffic only; it does not take effect for WAN-to-ZyWALL (local-in) traffic on ZLD firewalls. Since the blocked traffic in this case was from a VPN session terminating on the ATP200 itself, the Allow List entry having no effect is expected behavior.

Additionally, as you mentioned that the IP had been removed from the Spamhaus blacklist in the original thread, please note that the firewall's reputation filter may not yet have been successfully updated at that time, so it may still have matched against an older signature database. Therefore, please ensure that the firewall's reputation filter signatures are kept up to date.

Regarding why toggling "Enable blocking" restored the tunnel: this is not the behavior we would expect, so we are unable to explain it with certainty at this point. As the issue has not occurred again since then, we have not been able to reproduce it or look into the actual behavior. Should the issue happen again, and if you would like us to clarify the root cause, please keep the environment as-is and grant us access to the device so that we can investigate further.