We'd love to hear about it! Click here to go to the product suggestion community
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.
In reply to GaryChancellor:
I tried this but it is not working for me. Still it is opening with IP Address instead of hostname.
The issue is still present on firmware16.05.2 MR-2 and affects access to mail quarantine and sandstorm files too.
Guys, I found a workaround for this. It's working for me.
My box XG450 (SFOS 17.0.5 MR-5)
That's it enjoy. Ensure you have a valid HTTPS certificate uploaded to the UTM. Above method is working for me.
In reply to CharlesEapen:
No luck here.
This just bailed me out! Thank you!
In 17.1 there will be an option to use the hostname instead of the IP. This will apply to both Captive Portal and Warn/Proceed.
In reply to Michael Dunn:
Yep, its done. I just used it 5 minutes ago! :)
Seems this feature would be available for 17.1
Version 17.1 has now been released. Once you have updated to v17.1, you can switch to using the device hostname for the Captive Portal and other end-user interactions as follows:
1) Log in to the Firewall console over ssh 2) Select option 4 (Device Console) 3) Enter the following command at the prompt: set http_proxy proxy_url_use_hostname on 4) To confirm that it has set, enter the following command: show http_proxy 5) Type ‘exit’ to return to the menu and logout.
source : https://ideas.sophos.com/forums/330219-xg-firewall/suggestions/11580213-captive-portal-fqdn-support
In reply to oussama bekkaye:
While you can now use the Hostname FQDN using the steps you outlined, it does not use the specified certificate for the Captive Portal - it defaults to using the default ApplianceCertficate certificate.
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.
In reply to ChrisKnight:
Here is our KB article about the feature:
To upload a certificate, go to Certificates > Certificates.
To select the certificate to use, go to Administration > Admin Settings > Port Settings for Admin Console.
All HTTPS traffic that goes to directly to the box, whether by IP or hostname, should be using the certificate selected above.
The following pages will use the settings.
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.
For the units I have that have been successively upgraded from v15, I have the following problem:
- Not all the virtual hosts use the correct certificate binding.
- /cfs/web/apache/sslcert.conf continues to use the ApplianceCertificate certificate, rather than the specified certificate
AFAICT this is anything that uses the virtual host [<ip>:8090] which includes the Sandstorm analysis page.
Workaround for this specific problem was to recreate the ApplianceCertificate certificate to include the IP and FQDN hostname as subjectAlternativeName attributes. A process made difficult by having to find an openssl.cnf file, fix it to match the current certificate store layout + ability to sign certificates with sAN attributes, and finding where in the Postgres db the certificate passphrases are stored.
Once this was done, everything now works as I would expect according to the documentation you provided.
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.
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.