1 2 Previous Next 16 Replies Latest reply: May 30, 2014 5:08 PM by Jeff_J RSS

    DNS / Hostname woes with SGD & SGD Gateway


      OK I thought we had done pretty well in setting up a test SGD system:


      sgd1.domain.local x.x.21.31 (SGD Peer)

      rds1.domain.local x.x.21.41 (Windows Terminal Server)

      ad1.domain.local x.x.21.51 (Windows AD Server)


      AD works great, on the 'internal' network, everyone can log in, connect fine, seamless windows work lovely.


      However things are not working so well for folks outside the network. With a VPN - yes no problems they can get in fine.


      But we really wanted SGD to work *without* VPN.


      We decided to have a go at installing the SGD Gateway - internally known as gw1.domain.local (x.x.21.71)


      We thought we would test the Gateway by connecting directly to it's internal IP x.x.21.71 - doing this, we can connect to SGD fine, everything works. We thought we'd cracked it, however our joy was short lived!


      We created a NAT rule on the externally facing firewall to forward HTTPS from a public IP of the external DNS 'sgd.domain.com' - to the internal IP of the gateway. After doing this we can see the sgd page externally.


      Alas, logging in from here does not work, it tries to connect, and logs us out immediately.


      We noticed that - if we enabled the VPN, and again tried to go in via the public URL - sgd.domain.com - it works.


      Closer examination of the local client logs - showed the following when the VPN was disabled - the client was 'unable to connect to sgd1.domain.local:5307 (internal address of SGD server).


      So for some reason, externally, the external clients are still trying to connect internally, even though they are connecting via the external URL via the gateway.


      Running a netstat on the sgd server - shows no aip protocol from the gateway server to the sgd server.


      The external host setting in SGD is set to *:sgd.domain.com

      The external connecting host/IP of the GW is set to sgd.domain.com (public url).

      We set the certificates up on the GW and registered the GW with the sgd server.


      We think the config is all good - but it's just refusing to work right.


      Any ideas why this might be happening?



        • 1. Re: DNS / Hostname woes with SGD & SGD Gateway

          Two things.


          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.



          • 2. Re: DNS / Hostname woes with SGD & SGD Gateway

            Your description suggests you have not configured the security-gateway attribute on your SGD array. The following links should help you:


            • 3. Re: DNS / Hostname woes with SGD & SGD Gateway

              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.



              • 4. Re: DNS / Hostname woes with SGD & SGD Gateway

                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.




                • 5. Re: DNS / Hostname woes with SGD & SGD 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.



                  • 6. Re: DNS / Hostname woes with SGD & SGD Gateway

                    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.


                    • /opt/SUNWsgdg/proxy/var/log
                    • /opt/tarantella/var/log


                    In particular look at the latest <pid>-proxy.log on the Gateway and the jserver_error.log & stderrout.log on the SGD server.

                    • 7. Re: DNS / Hostname woes with SGD & SGD Gateway

                      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.


                      2.2 SGD Gateway Configuration Tasks


             How to Install SGD Server Certificates


                      Step five refers to a URL (https://sgd1.example.com is 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.








                      • 8. Re: DNS / Hostname woes with SGD & SGD Gateway

                        For that step in particular Jeff you need to supply the URL that the Gateway can contact the SGD web server on internally.

                        • 9. Re: DNS / Hostname woes with SGD & SGD Gateway

                          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:


                          Bad Request

                          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.



                          • 10. Re: DNS / Hostname woes with SGD & SGD Gateway

                            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.

                            • 11. Re: DNS / Hostname woes with SGD & SGD Gateway

                              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?



                              • 12. Re: DNS / Hostname woes with SGD & SGD Gateway

                                I have enabled NAT reflection in the setup so that both the GW and SGD server can resolve the public URL (sgd.domain.com) and this didn't appear to change anything.


                                Still there appears to be no AIP connection from the GW to the SGD server when performing a netstat

                                • 13. Re: DNS / Hostname woes with SGD & SGD Gateway

                                  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:

                                  /opt/tarantella/bin/tarantella status

                                  (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.

                                  • 14. Re: DNS / Hostname woes with SGD & SGD Gateway

                                    Hi there,


                                    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 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!)


                                    Good luck!



                                    1 2 Previous Next