Sophos Ideas

Do you have an idea for a Sophos product? Do you recognize a good idea when you see one? We want to hear from you!

Tony

My feedback

  1. 9 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SG UTM » Networking  ·  Flag idea as inappropriate…  ·  Admin →
    Tony supported this idea  · 
  2. 88 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    9 comments  ·  SG UTM  ·  Flag idea as inappropriate…  ·  Admin →
    Tony supported this idea  · 
  3. 36 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    9 comments  ·  XG Firewall » Network Protection  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Tony commented  · 

    DNSCrypt is a protocol that authenticates communications between a DNS client and a DNS resolver. It prevents DNS spoofing. It uses cryptographic signatures to verify that responses originate from the chosen DNS resolver and haven't been tampered with. It is an open specification, with free and opensource reference implementations, and it is not affiliated with any company nor organization. Its a must add. Securing DNS is the LAST holy grail of communications security.

    Tony supported this idea  · 
    An error occurred while saving the comment
    Tony commented  · 

    DNSCrypt is a protocol that authenticates communications between a DNS client and a DNS resolver. It prevents DNS spoofing. It uses cryptographic signatures to verify that responses originate from the chosen DNS resolver and haven't been tampered with. It is an open specification, with free and opensource reference implementations, and it is not affiliated with any company nor organization.

  4. 60 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    9 comments  ·  SG UTM » Remote Ethernet Device (RED)  ·  Flag idea as inappropriate…  ·  Admin →
    Tony supported this idea  · 
  5. 9 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  SG UTM » Remote Ethernet Device (RED)  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Tony commented  · 
    An error occurred while saving the comment
    Tony commented  · 

    NOTE: This must also work for the multi-wan configurations, not just a single wan. I didn't mention that but all my use cases have more than one WAN on the UTM. Imagine UTM with 3 WAN X RED50 with Two Wan. The work around is good to know, but doesn't scale :(

    Tony shared this idea  · 
  6. 77 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Under Review  ·  10 comments  ·  SG UTM » Remote Ethernet Device (RED)  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Tony commented  · 

    Just to add - Andrew Kay suggests that the RED is a "fail closed" device, and it is. But I think when Transparent Split was added, the failed closed makes the mode completely un-usable. The whole point of T/S mode is that you're providing a host or network access to a specific resource but leaving the access control policy to the firewall on the network. The only way Fail Closed makes any sense is in standard mode where you do not want any traffic to make it to the internet. I'm glad to see this is under review, even if its been under review since 9/2013. Hopefully after the next big release of the firmware for the UTM is out, we'll either see this move forward to close it. :)

    An error occurred while saving the comment
    Tony commented  · 

    This seems to be a big point of confusion. I was about to deploy a RED in Transparent/Split mode and was concerned that the RED would reboot after the UTM goes off line and effectively block internet access.

    Yesterday, I setup a RED in T/S mode in the lab, and blocked the red's ability to communicate with the UTM that is located at another office. After several attempts to contact the UTM the RED rebooted and the devices behind the RED lost their internet connection.

    I can confirm 100% that after the RED loses connection to the UTM, it will reboot, and will not pass any traffic. For uses where the RED is either in T/S or Standard/Split, having the RED reboot and block internet access is detrimental to the use cases where I've deployed it.

    I agree that if all possible, the RED shouldn't just reboot to try to bring up the tunnel again.

  7. 2 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SG UTM » Networking  ·  Flag idea as inappropriate…  ·  Admin →
    Tony shared this idea  · 
  8. 4 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  SG UTM » VPN  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Tony commented  · 

    I should have mentioned that this request is for windows

    Tony shared this idea  · 
  9. 17 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Under Review  ·  7 comments  ·  SG UTM » Remote Ethernet Device (RED)  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Tony commented  · 

    I have to agree. while there is NOTHING wrong with a self signed cert, a self signed cert trips up those scanning for VULS for PCI (and other?) compliance.

  10. 15 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  SG UTM » SNMP Monitoring  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Tony commented  · 

    I would also add that I think it is useful if the device name that we see in the wifi status screen also were included in the snmp output. This enables some really nifty monitoring.

    Tony supported this idea  · 
  11. 3 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SG UTM » Notifications  ·  Flag idea as inappropriate…  ·  Admin →
    Tony shared this idea  · 
  12. 26 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  SG UTM » Networking  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Tony commented  · 

    I think this is a good feature to add, albeit its not **** like many of the other great features in the new 9.2 release. There are known case examples where devices (Internet of Things) that use 802.15.4 and use long lasting TCP connections with VERY low traffic. A NEST thermostat is one such device - which we can use as an example to illustrate the usefulness of the feature. So a NEST uses a tcp connection, from the device to the cloud to send and receive data. Data from the NEST to the cloud goes out without a problem. However, after some time, the ARP entry for the NEST expires, but the tcp connection in iptables still exists. So after the arp entry expires, data coming from the cloud to the nest is passed through IP tables without a problem, however, since there isn't an ARP entry, the UTM can't find the mac address of the nest, since the arp entry is dynamic. The UTM does try to resolve the ARP entry, but since the nest is in a 'low power' state, it doesn't hear the "who-has" question, and the packets are dropped. Now the NEST could solve this problem by sending a "heart beat" every now and then to keep the arp entry alive.

    This is just an example of how this feature would help address this issue, but the usefulness of this feature extends beyond this example. I have a routine practice of statically setting the ARP entry for devices that are critical to the enterprise's infrastructure because it can address some forms of debauchery on the wire. I would think that being able to set the mac address in the host definition makes sense and also have some way to freshen the static arp list would address things nicely.

    Tony supported this idea  · 
  13. 2 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SG UTM » Management  ·  Flag idea as inappropriate…  ·  Admin →
    Tony shared this idea  · 
  14. 7 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SG UTM » Wireless Protection  ·  Flag idea as inappropriate…  ·  Admin →
    Tony shared this idea  · 
  15. 2 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SG UTM » Network Protection  ·  Flag idea as inappropriate…  ·  Admin →
    Tony shared this idea  · 
  16. 5 votes
    Sign in Sign in with Log in with your Sophos ID
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  SG UTM » Network Protection  ·  Flag idea as inappropriate…  ·  Admin →
    Tony shared this idea  · 

Feedback and Knowledge Base

icon-data-protection icon-endpoint-protection icon-phish-threat icon-sophos-central icon-sophos-central icon-sophos-central icon-sophos-central icon-sophos-central icon-sophos-central icon-sophos-central icon-sophos-mobile icon-sophos-utm icon-sophos-utm icon-sophos-utm icon-web-appliance icon-xg-firewall icon-xg-firewall icon-avid-secure icon-lightbulbCreated with Sketch.