While troubleshooting an ISA issue today where the ISA servers could not contact our issuing CA for a client certificate, I came across a great blog entry ( http://www.shudnow.net/2009/02/01/default-gateways-and-multihomed-boxes/ ) explaining the need for static routes on multi-homed servers. In the case of ISA, we have two seperate NIC’s each on a seperate VLAN with only the NIC in the DMZ configured with a default gateway. After running a route print command from Windows command line I discovered that persistent routes had already been statically created for our internal networks by the consulting firm we used for the project. What I was missing was the relatively new network where my issuing CA resided. When the server tried to contact the newer network, it routed the traffic through the NIC with the default gateway which has no access to my internal networks for obvious reasons. By utilizing the command: route add 10.8.13.0 mask 255.255.255.0 10.10.10.10 -p I was able to add a persistent route to the server. The command is broken down as follows: route add [network] mask [mask] [router (in my case the ip of my Internal NIC)] -p
Adding the persistent routes helped but I was still receiving errors in the Windows Application log indicating autoenrollment was failing.
I ran a capture on the ISA firewall logging page that showed all traffic from the localhost to my Issuing CA. I noticed traffic on random ports not being detected by the “Allow RPC from ISA Server to trusted servers” default system rule. I created a temporary access rule allowing all outbound traffic from localhost to the Issuing CA. This fixed the autoenrollment issue and the certificate registered successfully. I removed the temporary rule once the certificate was in place.