I have set up a lab using ISA 2006 Enterprise Edition consisting of a single Enterprise with two arrays to simulate a main office/branch office site to site VPN scenario. I have configured the CSS in the main office to be located on the same box that is running ISA 2006 EE. No replica CSS has been deployed in the branch office and therefore the array member in the branch office is configured to connect to the CSS/ISA in the main office. The VPN connection is active and the branch ISA can communicate with a DC at the main office.
The problem that I'm experiencing is that the ISA 2006 EE array member in the branch office array is unable to connect to the configuration storage server in Main office. Also, the main office CSS/ISA is failing to connect to the branch office array member as the mgmt console of the ISA/CSS shows that it's unable to retrieve information from the server in the branch array.
When the branch office ISA tries to connect to the main office CSS/ISA, the logs on the main office array show that connections are being denied for the MS Firewall Storage and Control protocols. The source address is shown as the Branch ISA IP address assigned from the DHCP server on the main office internal network and the destination is the internal IP address of the CSS/ISA. When the main office CSS/ISA tries to retrieve information from the branch office array member, the logs show that connections are being denied to 'RPC (All Interfaces)'. In this case, the main office array logs show that the source address is the main office CSS/ISA IP address assigned from a static address pool configured on the branch ISA and the destination address is the internal IP address of the branch ISA.
Yeh Matt, same problem as me indeed, Since I'm only playing around in a test enviroment I managed to get a fully functional vpn tunnel when creating it with a standard edition as opposed to the enterprise edition.
I have DHCP Relaying btw enabled at both sites and both are using dhcp for it's assigning although I just noticed that the branch site had a apipa address again. Odd.
However, if you still have problems, it might be worth checking that the DHCP server on the main office network is working. I had a similar issue and it turned out the DHCP service on the DC at the main office had stopped.