Advisory: Support Portal Maintenance. Login is currently unavailable, more info available here.

Port Still Blocked After Rule Allowing it Added

Hi,

Our new voip desktop phone app (MaX UC / Mitel) has a chat feature that should include the ability to send over sms. It looks like it's getting blocked as below:

I have these (among others) allowed between my  LAN and my provider's server (the address getting blocked above)

443-443:49152-65535

TCP 443

Separate rules, one allowing the from provider to my lan, the other from lan to provider.

I read the section in "rulz" and still can't pin down what could be blocking this. Rule #2 lists the order in which the packet is handled, but..

  1. the connection tracker (conntrack) first - WHAT IS "CONNECTION TRACKER?"
  2. then Country Blocking - COUNTRY BLOCKING OFF AT MOMENT
  3. then the 'ICMP' tab in 'Firewall': Traceroute and Ping are regulated on the 'ICMP' tab.  The "All" service only includes TCP and UDP - none of the other IP protocols are included. THIS WOULDN'T AFFECT THIS I DON'T THINK.
  4. then Intrusion Prevention (see the images below to see that IPS actually can happen in several places but happens only once!) - I VERIFIED THE ADDRESS IS LISTED IN EXCEPTIONS FOR BOTH IN AND OUTBOUND
  5. then DNATs* - NOT RELEVENT I DON'T THINK.
  6. then VPNs - SAME. EXCEPT I DID TURN OFF SSL VPN SINCE IT'S USING 443
  7. then Proxies (except the SMTP Proxy in Transparent mode which captures traffic after it has been forwarded  by a DNAT) - NOT SURE ABOUT THIS, EXCEPT WE DO HOST OUR OWN WEBSITE BUT IT ONLY FORWARDS SPECIFIC REQUESTS GOING TO OUR "WEB ADDRESS" ADDITIONAL IP address ON OUR WAN INTERFACE
  8. then manual Routes and manual Firewall rules, which are considered only if the automatic Routes and rules coming before hadn't already handled the traffic - THIS IS WHAT I HAVE THE RULE LISTED IN, iSN'T IT?
  9. and, finally, Application Control.

I'm stuck and lost.

Thanks,

Jeff

  • Hi Jeff,

    first: it's a "Default DROP", that means no other rule applied.

    Please show us the DROPs from the log again, ut do not obfuscate all parts of the addresses, as we are not able to see, if this is inside or outside or whatever without these infos.

    Then: show us the definition of your rule(s), you can abfuscate some part of adresses or servernames, but not everything, please. Otherwisem again, this would not make much sense to us helping hands.

    I guess your rule definition is much to "tight" for this simple purpose, but we will see

    Mit freundlichem Gruß, Regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • Also, Jeff, alone among the logs, the Firewall Live Log presents abbreviated information in a format easier to read quickly.  Usually, you can't troubleshoot without looking at the corresponding line from the full Firewall log file.  Please post the line corresponding to that above.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi, Sorry for the delay. I'm a department of one and in the middle of getting new phones a couple of our printers decided to spaz out.

    I mostly have it working and the only rule I seem to now be having trouble with is allowing an IP from our phone provider  to go from its address on port 443 -> a phone's on our LAN: port [some random # port]. The various "northland Mitel" definitions are hosts, groups, and DNS addresses sent to me by our phone provider. The ports in both directions include what they told me I should open up along with what I discovered through the logs I SHOULD open up because blocking them was disrupting calls.

    (all the phones are on LAN2; New Phone is actually an OLD "new phone" network which I hope to move the phones back to at some point, but right now everything is on one network).

    The rule I put in place thinking it would allow connections from the phone company's IP:443 -> my phones: someRandomPort is

    "443-443:49152-65535"
    TCP/UDP
    Dest: 49152:65535
    Source: 443

    I'm honestly not sure why they're coming from 443.

    Below are screenshots (less obfuscated then before) blocked events in the full log from another similar event yesterday.

    2020:12:08-16:51:31 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST" 2020:12:08-16:51:31 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST" 2020:12:08-16:51:32 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST" 2020:12:08-16:51:32 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST" 2020:12:08-16:51:34 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST" 2020:12:08-16:51:35 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST" 2020:12:08-16:51:38 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST" 2020:12:08-16:51:43 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST" 2020:12:08-16:51:55 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST" 2020:12:08-16:52:01 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST" 2020:12:08-16:52:05 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST" 2020:12:08-16:52:11 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST" 2020:12:08-16:52:17 kingarch ulogd[12333]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60003" outitf="lag0" srcmac="{SOURCE_MAC_ADDX}" srcip="{PHONE_CO_ADDX}" dstip="{PHONE_LOCAL_IP}" proto="6" length="40" tos="0x00" prec="0x00" ttl="64" srcport="443" dstport="55327" tcpflags="RST"

    Thank you so much!

    Jeff

  • It looks like it's that one phone with an issue that's causing the phone company to send reset (RST) packets.  Normally, one doesn't worry about RST packets being default-dropped.  A 60003 drop is one out of the OUTPUT chain and indicates that the connection tracker believes the connection is no longer active.  Even if you did let such packets in, the UTM would have no idea where to send them.  A packet capture might help, but the easiest would be to tell the VoIP provider that your stateful firewall is dropping those TCP 443 response packets - I bet they will know immediately what needs to be changed where, if anything.  Let us know what you learn.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA