Yesterday, I migrated my first actual enforcement module. What was supposed to be quite simple, went quite pear-shaped instead.
Fortunately, I picked a relatively unimportant firewall for the first cab off the rank, so the fact that I ran an hour over the alotted change window wasn't an issue. It also enabled me to keep bashing on the problem until I resolved it, rather than having to back out.
What was the problem? Well, it was actually a problem with the migration of the management server for that particular enforcement module. When I migrated the SIC (that's Secure Internal Connection for you non-Firewall-1 savvy people) related crap in $CPDIR/registry/HKLM_registry.data, I screwed up, and didn't set the 6 characters in the SIC's distinguished name to the same thing for both occurences in that file, which produced quite screwed up results when resetting the SIC between the management server and the replaced enforcement module.
What I had was:
: (SIC :ICAState ("3") :ICAdn ("o=my_management_server..yyyyyy") :HasCertificate ("1") :MySICname ("cn=cp_mgmt,o=my_management_server..zzzzzz") :CertPath ("/opt/CPshrd-53/conf/sic_cert.p12") )
when I really should have had:
: (SIC :ICAState ("3") :ICAdn ("o=my_management_server..zzzzzz") :HasCertificate ("1") :MySICname ("cn=cp_mgmt,o=my_management_server..zzzzzz") :CertPath ("/opt/CPshrd-53/conf/sic_cert.p12") )
This had the interesting effect of the enforcement module getting the 'zzzzzz' SIC during the initial SIC initialisation, but the management server thinking it was 'yyyyyy', and expecting this during normal SIC operation, so nothing worked.
This problem hadn't manifested itself for the other enforcement modules, as they must only deal with the 'MySICname' part of HKLM_registry.data for normal operation. I'm guessing the 'ICAdn' is only consulted when the SIC is reset.
So I just fixed up the HKLM_registry.data file on the management server and restarted Firewall-1 on it, and then lo and behold, I could establish a connection to my new enforcement module.