USG20W-VPN NAT Rule Blocking When It Shouldn't

DeanH

Hello,

I have a USG20W-VPN running 4.65 firmware that all of a sudden today began blocking access on the NAT rule for SSH to a LAN PBX card.  We use a different external port (65022 for example) than the default (22) but translate it to the default (22) on the LAN.  So, the ports are 65022 external (WAN) and 22 internal (LAN).

I changed the external port number to another number and it still didn't work.  I changed the external port number to 22 and it worked (of course, it doesn't have to translate anything in that case).  I changed it back to the original port number and it didn't work again.

Why would the NAT rule be blocking on something that has been in place for over a couple months?

I pulled the diagnostic data, so if someone from ZyXEL can message me, I can provide it.

DeanH

Thank you Zyxel_Jeff.

I had the external (WAN) port on the security policy rather than the internal (LAN) port.

I had been switching them back and forth during troubleshooting and left it like that the last time.

I jump between firewalls all day and sometimes forget which ones want the internal port on what appears to be an external facing policy/rule.

mMontana

Double check your setting.

Not only the NAT rule, but also the security policy. Turn on logging of the rules for a better read of the issue.

DeanH

I have triple checked the NAT and security policy.  It is the same as before with the original external port.

All the log tells me - with logging enabled - is the following:
"Match default rule, DNAT Packet, DROP"

That indicates the NAT rule is dropping the packet for some reason.

I have even removed and re-added the NAT rule to be sure it wasn't some kind of corruption in memory.

DeanH

For further data, here is the configuration of the NAT rule with possibly sensitive data replaced with variables < >:
Enable Rule: checked
Rule Name: <name of SSH rule>
Port Mapping Type, Classification: Virtual Server
Incoming Interface: wan
Source IP: any
External IP: any
Internal IP: <PBX card IP>
Port Mapping Type: Service
External Service: <service object name to the port number 65022>
Internal Service: SSH_TCP
Related Settings, Enable NAT Loopback: unchecked

I am still a bit confused on the difference between the Source IP and the External IP.  Aren't they the same thing?

PeterUK

Source IP is where its from or remote IP and External IP is to your USG.

Tested here with port 5129 to 22 and works fine here

DeanH

Yeah, it used to work on this unit.  Just today it started not working for us.

Thanks for the clarification on the source vs external IP.

mMontana

DeanH said:

All the log tells me - with logging enabled - is the following:
"Match default rule, DNAT Packet, DROP"

That indicates the NAT rule is dropping the packet for some reason.

That IMVHO indicates that a Policy Rule is missing for allowing the NAT to work...

Zyxel_Jeff

Hi @DeanH

Could you provide the config file and diag-info log to us via private message for a further check?
Thanks. 

DeanH

Hello mMontana and Zyxel_Jeff,

Thank you for your respective replies.

mMontana, it has been my experience that when a policy rule is missing, the log shows the following error:
Match default rule, DROP

Zyxel_Jeff, I sent you the two requested files.

DeanH

Thank you Zyxel_Jeff.

I had the external (WAN) port on the security policy rather than the internal (LAN) port.

I had been switching them back and forth during troubleshooting and left it like that the last time.

I jump between firewalls all day and sometimes forget which ones want the internal port on what appears to be an external facing policy/rule.

DeanH

Zyxel_Jeff,

Thank you for the data.

I had the external (WAN) port in the security rule instead of the internal (LAN) port.  I swap from firewall to firewall throughout the day and I sometimes forget which ones want the external port and which want the internal port in the access rules/security policies.

Admittedly, it is a bit confusing why an external facing rule is configured to check the internal port to allow the traffic through.  I just call it cutting out the middle man.  I'm more familiar with rules dealing with each side (WAN versus LAN) separately, i.e. source/destination for the WAN and source/destination for the LAN.  Two rules instead of source of WAN to destination of LAN.