NAT / control connections option for management object

[the_rock]

Hey guys,

Apologies if I posted this in wrong place, but since its related to change on management object, figured its correct, but it affected VPN tunnels, so admin can move it if needed.

Anyhow, this was the situation. Customer originally had mgmt object hide nat behind gateway (in this case their cluster) and this worked fine. Then we introduced new gateway (also CP) and we had issues pushing SIC to it, so what we had to do is to get it connected to same mgmt server, create manual nat rule to say src new fw external IP, dst was the IP of external subnet /27 IP, and then translated dst was internal IP of mgmt server and this let us establish SIC and push policy.

Now, here comes interesting part. When we created VPN community between main data center cluster and this new CP 6200 fw, as soon as we would push policy, sic would break and policy would fail after 10 mins.

To mitigate this, though we knew VPN would never work this way, we created an interoperable object with same external IP and vpn domain as main new 6200 fw and put that in community and that let us apply policy.

After opening TAC case, we were told to actually change nat on mgmt to static and statically nat this to an unused IP from external /27 range and check option for "control connections" and this actually did bring up new vpn tunnel fine, BUT, it appears it broke remote access from our end to the customer.

We tried changing mgmt nat back to original cluster IP, but by mistake, rather than putting it as hide nat, we left static nat and original cluster VIP, which broke additional 2 VPN tunnels. WE reverted back, but still had same issues for about 36 hours or so and then appears tunnels came back. TAC did some testing when it was broken and told us that maybe there was nat entry stuck in connections table, so we would need to clear connections table on both members, but that might not be needed now.

Here are my questions and I hope someone can confirm this 100%.

1) Is it SUPPORTED to configure mgmt object as static nat to cluster external VIP?

2) Would config like that break VPN tunnels and if so, why did only 2 tunnels go down rather than all of them?

3) Why reverting this to original state we had when TAC gave us suggestion did not fix VPN tunnels?

4) Why would this also break remote access VPN?

5) "control connections" option for mgmt nat, is that ONLY used for VPN connections or something else as well?

Im sorry, I know its a long post, but I want to know all these things for my own sanity : - ). In all my 15 years dealing with CP, I had seen 4 customers use this setting for natting mgmt server, its not something commonly used at all.

Thanks as always!

[PhoneBoy]

The reason the management needs to be accessible to remote VPN endpoints (including remote access) is to check the CRL of the ICA to ensure the certificates are still valid.
This check is typically done every 24 hours and if the management is not available, it will cause an outage for the VPN (site to site and remote access).
How often it checks the CRL when it's not available is a separate question (thus the VPNs being "down").

I believe the best practice is for the management to have its own NAT IP as this is also needed for logging and fetching policy as well.
It's possible this will work for HIDE NAT with the Cluster IP, but I don't recall offhand if it is supported.

[the_rock]

Thanks brother. Any way you could give me an answer to my 5 questions, I would really like to have them for my own reference and provide to the customer as well.

1) Is it SUPPORTED to configure mgmt object as static nat to cluster external VIP?

2) Would config like that break VPN tunnels and if so, why did only 2 tunnels go down rather than all of them?

3) Why reverting this to original state we had when TAC gave us suggestion did not fix VPN tunnels?

4) Why would this also break remote access VPN?

5) "control connections" option for mgmt nat, is that ONLY used for VPN connections or something else as well?

[PhoneBoy]

Most of these questions were answered in my response.
But, to answer them as they were asked just to be crystal clear:

1. I don't know offhand, recommend following up with the TAC.
2. If the remote end cannot reach the management (or whatever the CRL is) for an extended period of time, VPNs of all sorts (remote access, site-to-site) WILL fail. Period.
3. I presume the failure is related to the fact the CRL check failed and we do not continually check if the CRL is reachable again, only on a periodic basis. However, that is merely a guess based on what happened and further troubleshooting would have to be done.
4. It would break Remote Access for exactly the same reason Site-to-Site VPNs are broken (can't reach the CRL).
5. Control Connections NAT also apply to anything involving SIC with the management (e.g. sending logs to management, fetch policy from gateway).

[the_rock]

Ok, thanks @PhoneBoy