USG20W-VPN NAT Rule Blocking When It Shouldn't
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.
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.
0
Accepted Solution
-
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.1
All Replies
-
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.0
-
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.0 -
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?0 -
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 here0 -
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.
0 -
Hi @DeanHCould you provide the config file and diag-info log to us via private message for a further check?
Thanks.Don't miss this great chance to upgrade your Nebula org. for free! https://bit.ly/4g2pS9L
0 -
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.0 -
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.1 -
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.0
Categories
- All Categories
- 415 Beta Program
- 2.3K Nebula
- 142 Nebula Ideas
- 94 Nebula Status and Incidents
- 5.6K Security
- 228 USG FLEX H Series
- 266 Security Ideas
- 1.4K Switch
- 71 Switch Ideas
- 1K Wireless
- 39 Wireless Ideas
- 6.3K Consumer Product
- 244 Service & License
- 384 News and Release
- 82 Security Advisories
- 27 Education Center
- 8 [Campaign] Zyxel Network Detective
- 3.1K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 83 About Community
- 71 Security Highlight