USG FLEX 50W Not Following Allow Policy

DeanH
DeanH Posts: 47  Freshman Member
First Comment Fourth Anniversary
in Security
I have a USG FLEX 50W (USG20W-VPN) running V5.32(ABAR.0) that was just installed in front of a PBX.  Initially all went well.  After installation, we could make calls in and out.  Now, for some reason, it is dropping packets due to the default rule when it should not.

I pulled a packet capture and see the packets for a new call coming in to the WAN port, but not making it out the LAN port to the phone system.  Upon searching the log, I see the packets are being dropped due to security policy.  The original configuration has not changed, so why is it now deciding to drop these legitimate packets?

I even tried moving the policy rule for the inbound VoIP packets up to the top priority to see if that changed anything and it did not.  The packets are still being dropped.

The policy rule enabled allowing the VoIP packets through is set from WAN to LAN1 with a source of the originating servers (our VoIP servers), the destination is the LAN1 card IP of the PBX, and the service is set to a service of 5060 (SIP).  Everything else for the policy is default except for the name and description.

I ran the diagnostics in case the file is needed by ZyXEL to look deeper into this.

If someone has any bright ideas to kick it into gear, I'd like to hear them.

Accepted Solution

  • DeanH
    DeanH Posts: 47  Freshman Member
    First Comment Fourth Anniversary
    Answer ✓
    Finally figured it out.  I forgot that on the security policy, it wants to see the LAN1 port, not the WAN port as the Service.  That is so confusing since I am used to a WAN rule utilizing WAN components (IP/ports), not LAN components (IP/ports).

All Replies

  • DeanH
    DeanH Posts: 47  Freshman Member
    First Comment Fourth Anniversary
    I have also rebooted it to see if that works, but no.  Still blocking for some unknown reason.  It is like the original rule is not being seen in the table and the default rule is catching the packets.
  • DeanH
    DeanH Posts: 47  Freshman Member
    First Comment Fourth Anniversary
    I ended up removing the rule completely and rebuilding it again.  It is now working.

    However, I found another rule that is for management access to the PBX that is also blocking the packets.  On this one, I changed the service object from a specific port on the external side to match with the same port on the LAN1 side (device) and it works.  This required changing both the policy and the NAT rule.  So, there appears to be a problem with this particular static NAT rule for some reason.

    I put the original external port back in to both the security policy and the NAT rule and it is blocking me once again.  ?????!!!!
  • DeanH
    DeanH Posts: 47  Freshman Member
    First Comment Fourth Anniversary
    Answer ✓
    Finally figured it out.  I forgot that on the security policy, it wants to see the LAN1 port, not the WAN port as the Service.  That is so confusing since I am used to a WAN rule utilizing WAN components (IP/ports), not LAN components (IP/ports).
  • mMontana
    mMontana Posts: 1,389  Guru Member
    50 Answers 1000 Comments Friend Collector Fifth Anniversary
    edited January 2023
    Rule of thumb about security policy rules.
    98% of the times the author write it wrong. I did that too, so many times :)

Categories

Security Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）