Platform: Windows Server 2022 Standard, Version 21H2 (Build 20348.4171)
FileMaker Server: 21.0.2
OttoFMS: 4.13.1
SSL certificate: valid and trusted
Access: only reachable when connected to VPN
Both Otto installations are configured and operational, and I can reach each one individually. When connected to the VPN, I can access the Windows FileMaker server directly via RDP or FileMaker Pro with no issues.
However, when I try to run a Deploy operation in Otto from the Linux source server to the Windows destination, the process fails. Based on the error logs (attached), it looks like the source server cannot reach the destination server.
My assumption is that the actual file transfer during Deploy happens directly server-to-server, not routed through my local client machine. Because the Linux server is outside the VPN, it can’t see the Windows destination that’s only accessible within the VPN.
Can anyone confirm whether Otto Deploy traffic flows directly between the two servers (rather than through the initiating client)?
And if so, what’s the recommended approach when one server is VPN-restricted?
By default, OttoFMS does two way communication between the two servers for the deployments to run deployments. The OttoDeploy client is only the triggering agent.
There is an option called “Push Build to Destination” which you can toggle off to make the deployment do only one way communication from the destination. Check out the Advanced Deployment options docs for details on toggling that off. Once you toggle it off all calls are made from the destination to the source rather than both ways.
Thank you Kyle. It is still not working for me after unchecking that box. I tried twice today just now. And remembered that maybe after I updated the file maker server admin console credentials on the production box that perhaps I hadn’t updated them in Otto. After doing that I got a new error…
You’ll see in my logs that I did have a permission issue the first time. But the second time I can’t tell what I’ve done wrong.
It looks to me like the destination hostname can’t be resolved from the source server. Both machines have valid SSL certificates, and I can reach each Otto interface independently (the destination via VPN, the source from the open internet).
At this point, my best guess is that the source Linux server is still trying to “see” the internal destination host even though it’s not accessible without VPN. I’d appreciate confirmation on whether the “Push Build to Destination” option completely reverses that network direction, meaning, if it’s turned off, all traffic should originate from the destination toward the source (so the VPN restriction wouldn’t matter).
Having that option turned off should completely prevent that log you see where it says “error pushing build.” if you do the “copy deployment json” button in OttoDeploy is the push build option turned off? It should be in the json somewhere.
Having the push build option turned off will cause all network requests to initiate from the destination. It’s explicitly for exactly your use case where you have a destination server behind a vpn.
Woohoo! I had forgotten it, but that is actually a known issue with OttoDeploy. I’ll see if its feasible to release a new version of OttoDeploy with the fix this week.
