Firstly, we had mis-read the external DNS entry screen thinking that it said 'restart server' as in restart the the SGD Application in order to make a new external DNS name stick. However we found out (by chance) that only after we restarted the entire server, the change became applied. So when they say 'restart server' they mean it! Hope that helps someone.
Secondly - initially we were not able to use directly use SGD externally (we assumed a firewall issue, but it was due to the fact we had made the external DNS change and not re-started the server). This was the reason for us to look at the Gateway.
After the external DNS setting became applied, we gave logging in directly to the SGD again. This gave us a new error in the java logging, which we were able to track back a solution on MOS telling us to add a new ServerAlias in the SGD httpd.conf for the public hostname of the server. Why oh why was this manual edit needed!? After adding the ServerAlias in , and of course, restarting the entire server - at last we are able to directly connect to the SGD externally, without the use of a VPN. So hurrah for that.
I would still like to get the gateway working, Just so that we can clean go in without having to count on port 5307 outbound being open.
The situation with the gateway still hasn't changed. If you go in via it, yes it goes proxy through to the SGD server, however for some reason, the remote client is still trying to talk to the external DNS using 5307, so it's like we are talking to the gateway, there is some handshaking going on, ending up with the client trying to talk directly to the SGD server rather than the GW.
Thanks! We now get the connection reporting to be out on 443 - so that's something.
Unfortunately we are still hanging at login.
The Java client console does not report any error - it's just saying the connection is DIRECT - is that right - shouldn't it report as being SDGD?
I will investigate the logs and perhaps check a few other settings - but I think setting that attribute was a good suggestion - strange that I didn't see it mentioned in the GW installation guide as part of the setup process.
To clarify, the java console reports:
network:Connecting https://sgd.domain.com:443 with proxy=DIRECT
And I was wondering if, going via the gateway this should show:
network:Connecting https://sgd.domain.com:443 with proxy=SDGD
( https://sgd.domain.com is the publicly resolvable URL of the datacenter firewall public IP - which is then NAT'ing through to the internal IP of the SGD Gateway)
The external domain setting on the SGD server is set to sgd.domain.com, as is the 'inbound address' on the Gateway.
Just thought I would add that on the client O/S we do get the SGD tray icon with 'cog' which usually indicates a successful connection.
However in SGD Admin there is no active sessions showing up and of course we are stuck with the 'loading' page.
I am continuing to review the logs / settings on both the GW server and the SGD Server to see where we might have gone wrong.
Setting the security-gateway attribute is a mandatory part of configuring an SGD Gateway. I would strongly advise you review whether you have followed all other necessary steps as documented here. If you continue to have no success review the log files in the locations below and report if there are any errors.
In particular look at the latest <pid>-proxy.log on the Gateway and the jserver_error.log & stderrout.log on the SGD server.
Thanks - I will check those logs. The problem is that the documentation for the GW is not particularly clear with regards to internal and external dns URLs.
184.108.40.206 How to Install SGD Server Certificates
Step five refers to a URL (
https://sgd1.example.comis the URL of the SGD web server.) but does not make it clear if this URL is the internal 'Peer' 'internal' URL of the SDG server or the external URL. The documentation is full of references to URLs without any clarification on whether they are internal or external. It would be have been more helpful if all of the examples used obviously internal urls (sdg1.domain.local) rather than domains that could be used both externally and internally via split DNS.
The basic configuration example diagram at the start of 2.1.1 does not show IP addresses or URLS (only TCP ports) when clearly it should.
Yes that is what we did - thanks at least we did something right!
We have decided to have a go at using a loadbalancer / ssl offload system in front of the gateway & SGD servers - in the hope that we can control / manage SSL on this device, and all other communication to the GW & SGD servers will be un-encrypted and therefore problems with ssl certificates would just go away.
However it seems the External SSL Accelerator support in SGD 5.1 is totally broken - or perhaps again some undocumented hard coded fudge is required?
If we run the decrypt on the LB device, and forward from here the un-encrypted HTTP to port 443 on the SDG Server - we get the following error:
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
This error is totally nonsense - the whole point of the SSL offload feature is to enable the SDG SSL Daemon to take un-encrypted traffic on port 443!!!!!
Yes we have restarted the entire SGD server & followed instructions as per 1.6.2 (SGD Administrator Guide) plus 2.2.3 SGD Gateway Administrator guide.
If you want to use an external SSL accelerator with a Gateway you need to follow these instructions from the Gateway admin guide. Section 1.6.2 from the SGD admin guide is only relevant in a non-gateway deployment. You must also ensure that your load balancer is configured to allow both AIP & HTTP traffic through it. In my experience with load balancers they only allow expected types of traffic on well-known ports by default.
OK I'm not sure our LB / SSL offloader is going to be able to handle AIP - it's possibly going to introduce more problems than it can solve - so I have scratched that idea and gone back now to trying to get the GW to work!
The only trace of any error on either GW or SGD sever is on the GW server - <pid> proxy log:
May 29, 2014 3:35:03 PM proxy.Route run
INFO: Error: Route Route [From: TCP:*:443 <- SSLFilter:SGD <- SSL <- Router, To: TCP -> SSL] error. Restarting.
This error actually occurs after we log in - we get the SGD tray icon with 'cog' and then stuck at 'loading' - when we kill the page / exit the SGD process in system tray, this is when the error is logged.
So I'm not actually sure if this error is us killing the SGD process on the client, or the reason why we are stuck at 'loading'.
To simplify things we have configured the SGD to only use 'standard' (non secure) connections - restarted the server, plus we have updated the GW config so that when it asks if you want secure connection to SGD server, this is changed to [No] and also restart the GW.
Annoyingly - there is nothing on the SGD server by way of new log file entries today.
Doing a netstat on the GW server told us a few things
First of all - the only stuff going to the SGD server is https. No AIP at all.
Then there is this connection:
gw1.domain.local:46950 sgd.domain.com:tarantella SYN_SENT
This looks like the GW server is making an external connection to the external URL of the GW server itself. With the current FW setup - this won't work (no NAT reflection enabled).
Should the GW server being doing this? Why doesn't it just use it's real hostname?
For what it's worth - here's a quick recap!
Common Sever hostnames in setup:
Public IP > Public URL: sgd.domain.com
SGD GW Server URL: gw1.domain.local
SGD Server URL: sgd1.domain.local
Both these internal servers are on same local subnet, no firewalls between.
** What actually works **
On SGD server:
Change external domain on SGD server to sgd.domain.com - then reboot server
NAT public IP/URL sgd.domain.com > internal SGD server sgd1.domain.local
Addded ServerAlias sgd.domain.com to VirtualHosts section of
./tarantella config edit --security-gateway *:direct:sgd.domain.com:443
Users on the WAN can log in to OSGD via sgd.domain.com without VPN.
** What simply doesn't work **
Import / Export certificates on both SGD and SGD GW severs as per documentation
Change external domain on SGD server to sgd.domain.com - then reboot server
NAT public IP/URL sgd.domain.com > internal SGD GW server gw1.domain.local
./tarantella config edit --security-gateway *:sgdg:sgd.domain.com:443
Addded ServerAlias sgd.domain.com VirtualHosts section of
(As per MOS Doc ID 1496595.1)
Other stuff checked:
(As per MOS Doc ID 1355500.1)
sgd1.domain.local (primary): Accepting secure connections.
DNS resolving of external server from inside LAN
Reverse DNS for all servers works in and outside LAN
Tried logging in from servers inside the setup as well as outside, no dice there either
Users stuck at loading screen (SGD Client semi works, tray icon shows cog / connected info)
Doesn't appear to be any AIP network connections going from GW to SGD server doing Netstat.
Just a quick one to throw in.
In my experience we don't need to set up the ServerAlias if we're using the SGD Gateway. (we do if we're not using SGD gateway)
I may have missed it but I didn't see you mention that you 'tarantella gateway' add'd the SGD GW into the internal SGD array though you did say you imported certs both ways so that sounds like you did that so that's fine.
You also shouldn't need to tell SGD internally that it has a public external name of sgd.domain.com that's for the gateway to deal with. It may be confusing SGD if it's being told one minute it's sgd.domain.com but its SSL cert was for sgd1.domain.local could get a mismatch here between it and the gateway. (purely hypothetical thinking, no substance or proof)
I think before you looked at using the gateway the original problem was likely a lack of firewall traversal being configured so the SGD client on your local machine didn't know to bounce everything through 443 from the WAN side. That's a reasonably quick fix though the gateway is a better long term / defense in depth architecture though it does present some challenges itself.
In a set up of ours we'd have for example ..
The SGD gateway as sgdgw1.ourcorp.com with an externally CA signed SSL cert for this, this is the only identity the box has.
We'd then have our internal SGD array members sgdint1.ourcorp.internal, sgdint2.ourcorp.internal all configured as 'normal' SGD servers, no firewall traveral, and no mention of ourcorp.com for their own peerdns/external dns URLs (so that internal client connections don't go out and in)
We'd then tarantella gateway add on sgdint1.ourcorp.internal our sgdgw1.ourcorp.com (with relevant certs) and then configure --security-gateway to say *:sgdg:sgdgw1.ourcorp.com:443 (later we could go back and add a specific entry here to allow internal users on ourcorp.internal to connect directly bypassing the gateway)
On the SGD gateway side of course we'd gateway server add making sure to use the correct certs here too.
We'd then expect to be able to connect in, the cog is a good first sign, does it have the green colour over it showing it's connected?
Without the gateway in place we'd need to configure firewall traversal by telling Apache to bind on Listen 127.0.0.1:443 instead of Listen 443 and then configure --security-firewallurl to https://localhost:443 and configure --array-port-encrypted 443. It's at this point we'd configure --server-dns-external to be sgd.ourcorp.com since clients on the outside aren't going to trust sgd1.ourcorp.internal.
I think you're really close but I find sometimes with SGD you fight and fight with it changing configurations around and you can never fix it but starting over with the information and knowledge gained from changing it around and it then works! (SSL certs in the java keystores and whatnot hold long grudges!)