SSL VPN Listens on all Interfaces???

Hello Everyone,

Recently with the release of 17.1 I was happy to see the ability to change the SSL VPN port. I decided to take a plunge and move to XG. After a few hours of configuration and getting everything up and running I changed my SSL VPN port to 443 as most of us prefer. I than noticed that no matter the interface/alias IP port 443 is now used on every single interface and I can no longer use a second WAN port/static ip to forward 443 traffic to an internal Web Server or even use Sophos XG WAF on 443. I continue to get the error "Port already in use". I then decided to take a look on the Advanced shell and noticed 2 things. 443 is binded to all interfaces (netstat) and when I look at the openvpn.conf file it also shows that openvpn (SSLVPN) binds to all interfaces on 443. Does anyone here know of a work around or why Sophos dosnt let us choose the port to bind to like they did in UTM?




EDIT: created feature request as mentioned below:

  • Hey Chris,

    What did you have configured in your Local Service ACLs for the SSL VPN service? System > Administration > Device Access > "SSL VPN"

  • In reply to FloSupport:


    In device access only the WAN zone has ssl vpn checked off.

  • In reply to Chris Schnobb:

    Hey Chris,

    Edited: For correction (see reply post)

    Please raise a feature request for the option of selecting which interface(s) to bind/enable SSL VPN to. I believe the local service ACL's will enable/deny the incoming connections based on which zone it is arriving on, regardless all the interfaces will still be listening for this SSL VPN port traffic

    For the SSL VPN and WAF port conflict, I will also bring this issue up with our team for their feedback. I believe further investigation may be needed for this scenario as this should be possible with OpenVPN's port-share capability.


  • Hi,

    Good day!


    This is one of the limits of SophosXG as it is a Cyberoam Technology with the same issue. I suggest that request it to Sophos.

    Warm Regards,


  • Hey Chris,

    I followed up with our team and I would like to perform further investigation regarding your SSL VPN and WAF conflict. Please raise a support case and PM me with your case number.


  • In reply to FloSupport:

    Any info on how this is going?

    We were finishing the configuration of XG when I found out we cannot have the same port for WAF and SSL VPN like you can do in UTM! Not sure what to do now, throw away months of work or what really...

    I believe allowing to select the interface to listen in OpenVPN, like you can do in UTM, would solve it. I don't know how XG got into production without this, port 443 can't be used for anything.

  • In reply to ZLogistics:

    Same problem here.

    Since SSL VPN listens on all interfaces, it blocks the designated port for all other services e.g. WAF.

    this literately  makes it impossible to use 443 for most deployments.

    Please add the possibility to limit SSLVPN to a particular interface or alias interface!

  • In reply to samuel.heinrich:



    Setting up SSL VPN and a WAF. Both using port 443 and ran into this issue.

    Has there been any change to be able to do this or even work around? Other then move the VPN or WAF to different port.

    Am running SFOS 17.5.3 MR-3

  • In reply to SPY3:

    Hello ,

    No, there is no workaround for your requirement.

  • In reply to Aditya Patel:

    Is there any ETA on a fix or workaround?

    We are currently waiting for this to happen to migrate to XG.

    WAF must be on 443 to avoid connection problems from restricted networks (companies, hotels, airports...) but VPN should use that port aswell for the same reasons. I think this should be a priority.

  • In reply to ZLogistics:

    Hello ,

    We do not have an ETA at the moment on this implementation. We do have a feature request for the same and would encourage you to vote on this requirement.

  • In reply to Aditya Patel:

    As a workaround, i would suggest to talk to somebody regarding some small appliance with a NAT enabled.

    Resolved all my blocker project regarding this feature with a simple second appliance, which "Re-NAT" the Traffic back to XG to another port. 

  • In reply to LuCar Toni:

    Thanks for the idea. I already thought of that but it's overkill in my opinion. Since this is possible with UTM and not XG, we will keep UTM until this is implemented on XG.

  • In reply to ZLogistics:

    One customer used a Raspberry Pi for this rewrite. 

    So it is up to you. 

  • In reply to LuCar Toni:

    I'm a huge fan of the Pi, but we can't rely everyone's access to the company network on a Raspberry Pi. Nice approach though.