Default Drop STUN when port 22880 hits the external perimeter. Anyone know how to let it pass?

I work at a college and inherited a Sophos SG 450 solution.  Had a request from an instructor to setup SecondLife for a media class. When running SecondLife, as soon as it loads an online chat room, the Sophos SG450 logs a STUN Default Drop when port 22880 hits the external perimeter and the room never fully loads.  Anyone know how to let it pass? We are running internal IP's that pass in and out but for some reason when SecondLife engages it faults with the STUN Default Drop.  I didn't set this one up personally so any detailed info about what to create in order to halt the drops would be greatly appreciated.  Thanks very much "D"

  • Hi Dennis and welcome to the UTM Community!

    What do you learn from doing #1 in Rulz (last updated 2019-04-17)?

    Cheers - Bob

  • In reply to BAlfson:

    Great rule set, Thank you!  With my limited knowledge about the original setup i went through the rules and found the intrusion detection had been turned off by the previous and retired admin.  Although it is now on and working again, I am still faced with the issue of how to fix the mentioned issue.  When SecondLife is engaged the live log shows: Default Drop STUN internal IP:22880 > perimeter IP:22880 and I believe this is the cause of the application not fully engaging when the instructor is working on projects with students.  The port shifts between 22880 and 22890 but still gets Default Dropped.  I have even had a Sophos engineer onsite working with me on another project and he also could not figure it out.  At this point i am getting pressure to replace it with another solution but i want to stick with Sophos if possible because its  been doing a great job in all other areas so far.  Thank you for your response and help, much appreciated.  

  • In reply to Dennis Hill:

    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 one line corresponding to the drop in the Live Log.

    Cheers - Bob

  • In reply to Dennis Hill:

    Hi Dennis,

    Can we have you post the raw firewall log of these drops (not live log)?

    Also is this part of a NAT or outbound firewall rule? Please provide screenshots.

    I would also make sure you don't have any of the objects in these rules bound to an interface. 

  • In reply to MasterRoshi:

    Here is a complete line post of the firewall log showing an IP of 10.1.95.196 being dropped: 

    2019:06:18-13:18:42 sophosutm-2 ulogd[28428]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth10" mark="0x1dd" app="477" srcmac="00:1a:6c:40:87:ff" dstmac="00:1a:8c:f0:8e:ca" srcip="10.1.95.196" dstip="134.39.11.2" proto="17" length="56" tos="0x00" prec="0x00" ttl="127" srcport="22890" dstport="22890"

    It translates through the 134.39.11.2 front end but it stops there and wont traverse. 

  • In reply to Dennis Hill:

    That line says that there's no firewall rule allowing the traffic.  fwrule="60001" means that the traffic was dropped out of the INPUT chain, so we assume that 134.39.11.2 is the IP on eth10.  How did 10.1.95.196 even get there?  If my assumption is incorrect, please show a simple stick diagram with devices and these IPs.

    Cheers - Bob