Anyone have experience with using GTM

[Matthew Rasmussen]

We have a LOT of VPNs that we have to maintain and update when we change the engine IP. I’m researching ways GTM can help us simplify this by passing the burden of updates on to the network team. Has anyone had any experience (good or bad) with using GTM this way for inbound and outbound traffic to remote vendors?

Topic

[Jason Russell]

I’m curious as to why your engine IP changes? We’ve always been careful that we never change the IP (nor the hostname). Any upgrades are tested on our test system first, then migrated to production with a downtime. Unless there are major OS changes (IE: we went from CentOS to RHEL) or engine changes (eGate to cloverleaf), we never changed our IP or host name. Even major version updates use the same information. In the 10 years I’ve been here, we’ve only changed our engine IPs twice. Once was when we migrated to Epic, and the eGate engine then was heavily consolidated from five servers to two. The only reason we didn’t repurpose some of those IPs was because all the interfaces has to be up while we imported/brought in data before go-live to Epic. The second time was our recent migration from eGate to Cloverleaf.

However, the only real solution (and you should be doing this anyways) is use a NAT IP that the vendors connect to, and Network routes that to the actual server. This is not applicable to internal servers that use the engine, only external servers that use the VPN. External systems should not know your internal engine IP. This way the NAT IP stays the same, and your engine IP can be pointed to by your network team.

We really can’t change our IPs even more than before since we are now running a HA set up with a DR failover. We have a floating IP that points to the correct server, and changing any of those would cause massive headaches for everyone.

[Author]

Replies