Sophos AP/APX users may experience issues registering to Sophos Central. More info available here: Central Wireless
We'd love to hear about it! Click here to go to the product suggestion community
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.
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: 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="184.108.40.206" proto="17" length="56" tos="0x00" prec="0x00" ttl="127" srcport="22890" dstport="22890"
It translates through the 220.127.116.11 front end but it stops there and wont traverse.
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 18.104.22.168 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.