Deep Insight - Tips & Tricks for Firewall Products

In this article, we want to give you an overview over a plethora of different best practice tips, shorter deep dives in terms of debugging, analyzing and other interesting remarks regarding our Firewall products to gain the most out of them.

The Command Line Interface

In case you may not know, our devices have a command line interface which you can either access via SSH or console cable: Access the command line interface of your Zyxel device (SSH via puTTY & Console via TeraTerm)

But did you know, you can even access the CLI from your webbrowser? Click on the webconsole icon in the right corner of your USG FLEX' menu:

No VPN Traffic passing through? (Subnetting & Protocols)

This is a quick tip for a problem which often occurs on VPN: Many of our customers report to us that the VPN tunnel, may it be Site-To-Site or Client-To-Site, perfectly fine connects, but there is no traffic coming through - why is that so? Often, there are two different reasons for this

1. Subnets are set up wrong
2. ISP is blocking protocols

#1 - Subnets are set up wrong

Imagine you have two sites which you want to interconnect, and both sites have the same IP-Range, let's just assume 192.168.1.X, as shown below:

Often, customers will report that the VPN in fact does connect and build up, but they are not getting traffic over the VPN, thus not being able to connect from the PC to the Server - what is happening here?

The thing is, that on creating an interface on the USG, we are creating a Direct Route. A direct route source-independently places a traffic wanting to go to an IP which matches one of the firewalls interface subnets onto the respective interface. In different words: by having LAN1 on USG #1 with 192.168.1.1, whenever we want to reach 192.168.1.200 (the servers IP), we will always on reaching our gateway be sent back into the LAN1 Subnet of USG #1 via the direct route. Here's what it looks like:

You could read the rule as following: "Without looking at the source, if the destination matches the interface of LAN1, just push it out to LAN1", so connection from PC to the Server will never reach the fourth routing block "Site-2-Site VPN" and thus can never be processed by the routing algorithm to be pushed into the VPN. The clear learning out this is: make sure to never have overlapping subnets!

And if you do, then check out this tutorial: How to setup SNAT in a VPN tunnel

2# - ISP is blocking protocols

It may be that the reason for your VPN connecting, but no traffic passing through, is simply because your ISP is blocking no ports, but protocols. So the VPN can establish through port 500 UDP, 4500 UDP and/or 1701 UDP, which are responsible for exchanging the handshake to connect the tunnel to each other, but the protocol used to encapsulate the VPN tunnel data, ESP  - also known as protocol 50  - is being blocked. If you are affected are not, you can find out via the command line: enter

packet-trace interface wan1 ip-proto esp

and trigger a VPN connection (Tip: make sure to not have any additional tunnel open and not have any traffic running through the tunnel expect of your client. Then trigger a ping to the remote LAN gateway IP. If you see packets going out, but not coming back to your WAN interface, that's a pretty solid indicator that your ISP is doing something wrong-  in that case, step into contact with them. 

Naming matters! Organize your Objects well!

Our USG FLEX/ATP/VPN-series in standalone bring a great menu structure and layout with them. One of the key advantages our devices have is the incredible flexibility to twist and tweak settings to your needs. However, this comes with a price to pay - you need to keep your naming organized! 

Now, since there are many individual approaches on how to do it, we will simply show how some of our colleagues do it. To give you a small example, first, navigate to

Configuration > Object > Service

and press the "Add" button to create a new entry:

Since the name of a Service has to start with a letter, but mostly we are defining Services outside of the spectrum, we could start the name with something generic as "Port", followed by the Port number. In the end, we might add the Protocol as well, as it might be that at a different point in time the matching UDP Port might be utilized by a different application. 

If you want to, you can also enhance this system by adding a short keyword on what the service is about:

A similar approach is recommended for all other objects, especially addresses - make sure you organize and understand the system you built-up and maintain it for reasons of consistency.

Firmware Updates - never change a running system!

What might sound at first read as a recommendation to stay with your current firmware (it is not!) is a tongue in cheek wordplay, but let us explain further. Our security firewalls have two Boot-Up/Firmware partitions:

Each partition have their own database, also consisting of two configuration databases individual to each other - that's important to know, because if you would to apply a new firmware, you might want tend to set the firmware on the Standby Partition, "just in case something happens, I can roll back to the Running and be fine again. " - a lot of our customers actually think that exact way. But there's a fallacy to it: each time you change the partition, your current configuration will indeed by tried to brought over and applied to the other partition. That might go well in most cases. However, if there somehow is an issue spotted with the current configuration - which can happen if you upgrade from a very old firmware to the latest without any steps in between - it can be that the USG bugs out and reboots itself and tries the process again. However, to not fall into an eternal bootloop, after 3 attempts the device will revert itself to system-default-configuration! 

If you are now in a situation that you are remotely connected to the USG over multiple 100 kilometers and the device has crashed itself in this way, you better have someone on site who can help out or be prepared for a long trip on-site.

You are much better off overwriting the running partition, as only if something not anticipated happens ( such as a rollout bug or similar), there might be an issue - in most cases, it will just run perfectly fine upgrading the firmware from an already quite recent firmware on the running partition.

Backup your configuration - right now! No, not copying it to the router, actually save it on your PC!

Another tongue in cheek headline for a serious recommendation: Backup your configuration file regulary. Also, do the backup not only on the device itself (which is already a good step into the right direction, but actually download it to the computer via 

Maintenance > File Manager > Configuration File

and selecting the startup-config.conf and pressing the Download-button:

You now may find the downloaded .conf file, which can be opened via Notepad or Notepad++:

Having a regular synchronization of this sort helps you drastically reducing down-time when it's really needed - in a problem situation.

There are many other tips and tricks to eventually be added in the future, but this gives you a good start on some hopefully useful information.