VPN user looped into heartbeat network

[cheungtony]

Just spot that if a VPN user is using the same network address with heartbeat segment (i.e. 192.168.x.x) , they cannot route to internal network properly after authentification but receive server not responding message, apart from changing the heartbeat segment to an uncommon address, could I make heartbeat network totally transparent from firewall ?

BTW, office mode is not used since we may need to upgrade the VPN client to SecuClient instead of using SecuRemote. Any suggestion ?

[melipla]

Originally Posted by cheungtony

could I make heartbeat network totally transparent from firewall ?

There's no such thing as "totally transparent" because the cluster members need to know which network to use for sync.

The problem could be either that Firewall is seeing SecuRemote traffic as violating Anti-Spoofing or SecuRemote is trying to route traffic to cluster member's Sync Interface IP...

Check the logviewer and see which cluster IP responds, you will need to turn off DNS resolution so that the object isn't displayed and the IP is. You should see the request from the client go to the cluster VIP and then see one of the cluter member's IP in the response, it may or may not be natted to the cluster's VIP address (most likely not). Verify that its not using the sync network. Verify that the topo definition for the sync interface(s) on the cluter is listed as "Sync" and not a combo.

Either way you should see some kind of drop in the logs as to why. If you have the other "cluster anti-spoofing" feature turned on, it may be dropping traffic and not logging it. Otherwise per-interface anti-spoofing drops should display in the logs normally.

Originally Posted by cheungtony

BTW, office mode is not used since we may need to upgrade the VPN client to SecuClient instead of using SecuRemote. Any suggestion ?

This is why Office Mode was invented. :) The easiest and quite painless solution is to change the sync network...