We run a FileMaker server in a restricted network environment. I haven’t been able to find documentation about what outgoing ports need to be open and to where in order to activate our instance and to deploy to our public network FileMaker servers.
Hi!
Welcome to the community 
OttoFMS and OttoDeploy use port 443 to communicate to each other.
License activation also uses port 443. The license server is at https://edd-sl-proxy.geistgate.com.
We will add a note to the getting stated docs about that.
We have offline activation on the roadmap. But it isn’t ready yet.
Let us know if that gives you the information you need, or if you have further questions.
Thanks
Todd
I made a change to the docs that I hope makes this clearer. There was a note about the license server. But the url was buried behind a hyper link. I made it a little clearer.
I will also add a FAQ about restricted networks as it comes up a lot.
Thanks
Todd
Todd, sorry I was expecting a notification and didn’t see this answer until late last week. Unfortunately our network firewall can’t allow traffic by DNS name. I did a DNS lookup for edd-sl-proxy.geistgate.com and requested the two specific IPs returned be open, but I still can’t activate and I’m getting different IPs on subsequent lookups. It looks like all the DNS responses so far have come from 76.76.21.0/24. Is that the subnet that edd-sl-proxy.geistgate.com may be listening on?
Hello,
I am sorry. https://edd-sl-proxy.geistgate.com is running on a serverless architecture based on AWS Lambda functions. It won’t have an IP Address that you can rely on.
As I said in the previous email, we have offline activation on the roadmap, and we may consider moving the license server to a regular server.
But for right now, that is all we have.
Thanks
Todd
1 Like
Hi,
I spoke to someone at the booth at Engage 2024 and it sounded like OttoFMS would work for me. Our servers are also restricted with no outside connections. I had to work with FileMaker for a no-phone home license for one of the Mac servers that kept refusing connections every 90 days because it couldn’t phone home.
I’d love to give OttoFMS a try and see if it will improve my work flow, but I guess that is on hold until there is offline activation. Is there a timeline? Wondering when I should check back?
1 Like
Hello,
Offline activation is on our list for sometime this spring.
Sorry I can’t be more definite.
Todd
1 Like
OK, so the forum machine says “This topic has been solved” but since my question came from this topic, I’ll drop it here.
We finally got our client’s big files all recovered, then I was authorized to install Otto on their On-Premis Production Stack. So we could get ready to actually use the product; however, Activation doesn’t work. I enter the License Key select the activation button and I get a little swirly icon, and then nothing.
Port 443 is open on the server And I’m told that we can telnet to https://edd-sl-proxy.geistgate.com. Is there something else that need to be opened up or another test you can recommend?
In the client’s AWS account, I have no problem activating the product. But for their on premise machines, I don’t have direct access to their network. I believe their servers are all on VMWare–if that makes a difference.
Spins and then nothing sure sounds like the license server can’t be reached.
I usually test by navigating to https://edd-sl-proxy.geistgate.com in browser from the server. In theory telnetting would do the same thing, but perhaps they block http traffic only ???
We do have a way to activate servers offline now, so let us know if you want that and we can get you an offline activation key. We’ll need your Server Id. Which is available in the FMS Admin Console /admin-console/app/configuration/generalsettings. You can DM that to us or send en email to support@proofgeist.com.
Todd
1 Like
Well that’s very interesting. When I try to connect from their local terminal server (just in a web browser) I get a certificate error, and then I can’t “proceed.” When I connect from my local machine–no problem.
When I run a wget from one of the servers in question, I get…
wget https://edd-sl-proxy.geistgate.com
--2024-04-12 16:03:42-- https://edd-sl-proxy.geistgate.com/
Resolving edd-sl-proxy.geistgate.com (edd-sl-proxy.geistgate.com)... 146.112.61.106, ::ffff:146.112.61.106
Connecting to edd-sl-proxy.geistgate.com (edd-sl-proxy.geistgate.com)|146.112.61.106|:443... connected.
ERROR: cannot verify edd-sl-proxy.geistgate.com's certificate, issued by ‘CN=Cisco Umbrella Secondary SubCA nyc-SG,O=Cisco’:
Unable to locally verify the issuer's authority.
To connect to edd-sl-proxy.geistgate.com insecurely, use `--no-check-certificate'.
Also, I’m glad to here there is an offline way of doing this.
This is a firewall interfering the http traffic. It is probably Stateful packet inspection or a bump proxy, which is a sort of man in the middle packet inspection. It may not be working properly. The cert that it says is bad is not our cert, but the cert the firewall uses to re-encode the traffic… or they may just need to whitelist the url.
I am passed the end of my expertise here. But our infra team could probably help more if they need it.
Hope that helps
Todd