This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Is there a way to use the hostname for captive portal instead of IP?

Really, the subject says it all... is there a way to configure the HTTPS & HTTP proxies to redirect to a hostname instead of the IP address of the firewall?

Reason I ask is I'd really like to keep my certificates consistent.  We use an internal PKI, and so I have issued the XG a valid certificate based on our root cert.  Yes, I can go back and re-issue it with the IP address, but I would like for it to redirect, if possible, to the internal hostname instead.

Similar to overriding the hostname for the external SSL vpn... I want to do it on an internal-facing service.

If the answer is currently "not possible" - I would like to suggest this as a feature.



This thread was automatically locked due to age.
Parents Reply
  • The following pages will use the settings.

    • Captive Portal
    • User Portal
    • Guest User Registration
    • Clicking Proceed on the Warning page
    • Sandstorm analysis in progress

     

    The email Quarantine Digest will always use the IP.

    NTLM authentication (which is only HTTP) will always use the IP.

     

    Let me know if there are any other pages that do not follow the configured setting.

     

Children
  • For the XG units I have that have been successively upgraded from v15, I'm seeing the following:

    - Sandstorm analysis in progress still uses ApplianceCertificate certificate, regardless of certificate specified for Captive Portal.

    - The Captive Portal certificate doesn't get pushed into /cfs/web/apache/sslcert.conf which is used for the [<IP>:8090] virtual host.

    Recreating the ApplianceCertificate certificate to include the IP and FQDN hostname as sAN attributes fixes up the remaining virtual hosts and makes this work as I'd expect according to the documentation of this feature addition. Although you still need to push out the Appliance CA certificate and add it to the client PCs' trusted root CA certificate store.

    EDIT: This may not be the case for everyone, but it certainly is for me on the units I have that have been successively upgraded from v15.

  • Why is that "The email Quarantine Digest will always use the IP". This way quarantine will be available only for internal or external users, not for both.

  • Hi Chris,
    I appreciate that you are trying to understand the system but please be aware - you are hacking the system without any knowledge of how it works.  Some of what you are posting is wrong or at least misleading.  I don't want to spend too much time trying to explain how it works because, quite frankly, you shouldn't be doing that.
     
    Lets back up.
    Using the documentation in community.sophos.com/.../132058
    What end-to-end functionality is not working as you expect?
  • FilippoBastianello said:

    Why is that "The email Quarantine Digest will always use the IP". This way quarantine will be available only for internal or external users, not for both.

     

    The Email quarantine digest uses a separate setting, configured under Email > Quarantine Digest > Reference User Portal IP. When we built the "proxy_use_hostname" feature for 17.1 we did not realize email was a separate configuration (built by a different team).  We are looking at options for changing this in the future.

     

    There is no reason why you cannot use the same IP for both internal and external users, as long as you can route there.  Putting in a hostname/FQDN does not change the fact that the FQDN will resolve to a single IP address which will be one of the interface IPs (the same interface IPs you can select right now).

  • "There is no reason why you cannot use the same IP for both internal and external users". In Email > Quarantine Digest > Reference User Portal IP I can choose one interface (I usually choose LAN or WAN). How can I route users from one zone to the IP chosen?

    "Putting in a hostname/FQDN does not change the fact that the FQDN will resolve to a single IP address" is not necessarily true if you use, as in my case, split DNS in order to resolve FQDN differently, depending on which zone you are in; usually internal DNS for LAN and public DNS for WAN

  • Thanks to the saint-like patience of Michael Dunn, I was able to work out that my Captive Portal certificate binding issue was due to the fact that PFX Import - while helpfully reporting that it imported the certificate chain correctly - would result in the awarrenhttp service (responsible for handling the Captive Portal) not being able to find the Root CA from the Intermediate CA and would silently roll back to using the ApplianceCertificate certificate. Once I imported the Root CA, Intermediate CA and leaf certificates separately as PEMs it worked correctly.