Richard Fincher Posted July 9, 2014 Posted July 9, 2014 I'm running Filemaker Server behind a NAT firewall in my data centre, and it mostly works fine. The server is bound to a 192.168.1.xxx IP address, and the firewall which it's behind, uses NAT to forward the external public IP address to the internal IP address which the server is on. All this works fine, except that on the Group Start Page, the "WEBD" buttons link to the internal 192.168.1.xxx IP numbers, which obviously don't work. Just wondering if there's any way around this, without reconfiguring the firewall to not use NAT.
Claus Lavendt Posted July 9, 2014 Posted July 9, 2014 If you access the group page via the internal IP, the link on the WebD button will also use the internal IP. If you use a domain name, which is mapped to your server, this should work from both outside and inside, provided DNS and NAT is configured correctly. e.g.: http://myserver.company.com:16000/groups/group1 then the webD button will use this link: http://myserver.company.com/fmi/webd/#fileName
Richard Fincher Posted July 9, 2014 Author Posted July 9, 2014 Interesting - so you think it might be displaying a URL based on 192.168.1.xxx because it can't do a reverse DNS lookup and obtain the right Hostname? If so, I should be able to fix it with a hosts file entry. Just to clarify, I'm already successfully accessing the Group Start page externally by means of a domain name, but the WebD buttons show the internal IP number, even though the page it is displayed isn't loaded using 192.168.1.xxx/fmi/webd. There is no requirement to access it through an internal IP number, as nothing else is on that subnet.
Claus Lavendt Posted July 9, 2014 Posted July 9, 2014 I think your server does not have a host DNS name set up. So yes, you might be able to fix by setting up a hostname on the machine. I mostly work with Mac OS X servers and here all my servers are setup with a hostname. Also have an internal DNS server, that resolves domain names, both those who can be accessed from outside and those who is only internally accessible. On Mac OS X you use the server admin app to setup the hostname. (or you could use Terminal)
Richard Fincher Posted July 9, 2014 Author Posted July 9, 2014 Ok, I edited /private/etc/hosts to add a reverse lookup for my internal IP number, and restarted Web Publishing - didnt help. The output of the "hostname" command is Filemaker-Server.local I do run my own resolving DNS servers, by the way, so i could insert a zone file for 192.168.1 but nervous about unintended consequences.
Jeroen Aarts Posted July 10, 2014 Posted July 10, 2014 It looks like FMI could have done a better job coding relative links '/fmi/webd#<database>' behind the WEBD buttons on the group pages, rather than using the local IP address which of course only works from within the LAN.
Claus Lavendt Posted July 10, 2014 Posted July 10, 2014 Well, if set correctly, the hostname on the machine should read-out a public accessibly domain name. As you get the .local output, this indicates that there is not set a global hostname for your server. I suggest that you use the Mac OS X Server Admin for this task as it will then work fine. Jeroen: FMI could not have coded this any different. It sees that there is no global hostname for the server and instead of using the servername.local (which does not always works on all subnets), they use the IP address of the machine itself, which in this case is a LAN IP as he has a NAT to manage forwarding. On my servers, this works as expected, but they all have a global hostname, instead of .local
Richard Fincher Posted July 10, 2014 Author Posted July 10, 2014 Hmm, ended up totally wrecking my Filemaker Server 13 install - good job there's no paying customers on it yet! On the other hand, I did manage to fix it myself, and in the process, worked out how to start Filemaker Server 13 from cold, *without* rebooting the Mac: sudo su - cd to /Library/LaunchDaemons launchctl start com.filemaker.fms start com.filemaker.httpd.start exit (Mac OS X Mountain Lion 10.8.5, not Server version) I'm inclined to agree with Jeroen Aarts, ended up setting the hostname back the way it was before. Part of the problem was that the encryption keys are based on the hostname, so changing that renders them invalid.
Recommended Posts
This topic is 4045 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now