Daz Studio fails to initialize CMS when on VPN
MZ1R
Posts: 28
[Daz Studio fails to initialize CMS when on VPN] Title says it all
Post edited by Richard Haseltine on
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Does install manager or Daz Central seem able to communicate, if you use either of those?
DIM and DC both work although it takes 2-3 minutes to connect. I don't have this issue with any other CMS based systems like Reallusion, Epic or Adobe.
Do they use IP protocol to link to an SQL database? I've not seen others reporting this issue, and it seems unlikely no one else uses a VPN, so it may be some interplay of the particular VPN and any security software.
Check that your internal LAN traffic is not getting routed through the VPN interface. You can achieve this by excluding your internal IP address range (10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16) from the VPN interface.
This morning I just let DS startup run and at around 9 minutes it finished 'Connecting to CMS' and loaded. However, Smart Gallery is useless at it takes several minutes but I don't use it anyway.
I've reinstalled numerous times on 2 high end systems, neither of which I have any software/internet connection issues with while VPN is active.
It's irrelevant where internal LAN traffic is routed as that was one of my first test processes (retired NW engineer). I could pull out Wireshark and sniff it down but I'm too old for that crap and Daz ain't paying me to troubleshoot their software.
Local content is fine and I only use DIM so as long as I can access my paid content, I'm not going to spend any more time on the slow connect as it's a DS issue.
Thanx,
MT
I had a similar issue where DS would complain about connecting to CMS everytime during startup while VPN connection was active as I am using a NAS drive for my content. Turned out the VPN client was routing all LAN traffic through the VPN tunnel due to that omission. Lost a few hours of my life learning that DS would still complain with CMS connection in case the content library's network paths were not reachable even though the CMS was running locally and had no access issues.
Thanx but content paths are all default. It's just poor error checking on the coding side for it to take so long.
If its not the content paths then it could be the PostgreSQL port 17237 thats probably no longer reachable once VPN is active. Have you tried accessing the CMS database using a standalone SQL client while your VPN is active? Its possible that those SQL connection requests are passing through the tunnel and getting blocked. In any case, it is imperative to first ensure that your VPN is not intercepting any connections it is not supposed to.
Port 17237 rang a bell so I looked at the DS log and saw where 17237 couldn't be accessed.** Then I remember that I had blocked it so DS wouldn't data mine and stay connected to their cloud system as I don't need it to use DS. My bad as I hadn't used DS since I started the new VPN and I was thinking that was the issue. I can flip my firewall toggle but as I don't need it I'll just wait for their slow a** error checking to complete and DS loads.
Thanx for all the feedback.
**could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 17237?
Daz doesn't datamine - both Daz Studio and the installers wait to be asked or, in the case of the product improvement programme for DS, ask if you want to opt in. I can't recall if the update check asks or not, but it doesn't - as far as I know - send any data, just asks Daz what the latest build is and then does a comparison locally.
"Product improvement programme' is data mining and regardless of opt outs, companies nowadays always find a way to data mine.
Port block on commercial firewall.
Assuming that the "commercial firewall" is installed on your PC, you probably don't need it if you are using it solely for port blocking. A DHCP enabled home router would serve the same purpose when not using VPN. DHCP would allocate separate internal IP address which prevents your PC to be accessed directly from the internet thereby providing a layer of security there. All your ports in your PC would be inaccessible from the internet by default unless you specifically configure port-forwarding. Also, if your ISP uses CGNAT (most of them do these days) then you are already protected from direct inbound access as your ISP's allocated IP address would be different from your public IP address.
While using self-managed VPN, its better to configure any access control rules, such as port blocking, on the VPN server's firewall which is your first point of entry for any inbound connections. That way your all devices using the VPN connection will benefit from centralized control and those access control rules would not affect any local communications within your LAN. However, your home router or ISP's CGNAT would be transparent to the VPN connection.