USG20W-VPN NAT Rule Blocking When It Shouldn't

DeanH
DeanH Posts: 23  Freshman Member
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.

Accepted Solution

  • DeanH
    DeanH Posts: 23  Freshman Member
    Answer ✓
    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.

All Replies

  • mMontana
    mMontana Posts: 574  Guru Member
    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
    DeanH Posts: 23  Freshman Member
    edited October 2021
    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
    DeanH Posts: 23  Freshman Member
    edited October 2021
    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
    PeterUK Posts: 1,283  Guru Member
    edited October 2021

    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
    DeanH Posts: 23  Freshman Member
    edited October 2021
    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
    mMontana Posts: 574  Guru Member
    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
    Zyxel_Jeff Posts: 259  Zyxel Employee

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

  • DeanH
    DeanH Posts: 23  Freshman Member
    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
    DeanH Posts: 23  Freshman Member
    edited October 2021
    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.

Security Highlight