-
This is probably related to bug 2888445. When we create a new Resource Override with a public service override and we add the IP address before changing the public server, we have two problems with the dynamic rules (the static rules are fine):
1) The ServiceDNAT rule is missing the destination NAT port
2) The ServiceSNAT rule is missing the sourceNAT port and uses dport instead of sport for...
2009-11-14 21:34:15 UTC in Security Policy Manager
-
I'm delighted to report that this is now working fine for me. sword 1.6.0 bibletime 2.3.3 on 64 bit Ubuntu 8.0.4 fully patched.
2009-11-14 18:54:03 UTC in BibleTime - a Bible study tool
-
This was a somewhat complicated transaction so I do not know if we have captured all the details. We created a Resource Override for with a public service override. The private service was pcsync-https and the public was https. This conflicted with the existing https on the server so we save the override without the NAT. We then deleted the https service and added the NAT to the resource...
2009-10-29 02:09:50 UTC in Security Policy Manager
-
We created a resource override with a public service override but it detected a NAT conflict. We created the Resource Override without NAT. I do not recall if we created the public service override even though we had no NAT. We then deleted the conflict and edited the Resource Override to add NAT. The resulting dynamic rule did not include the original port in the DNAT rule.
2009-10-29 01:08:33 UTC in Security Policy Manager
-
If one creates a new service via the Services Manager and then logs into a different database without closing the SPM, the new service appears in the Service Manager even if it is not in the database.
2009-10-21 20:45:49 UTC in Security Policy Manager
-
We changed the public IP address of a PEP and then changed the DNAT address of a server behind the PEP to reflect that change. This was not port mapping; the server was using a unique IP address. Changes were applied to the PEP but failed with an inconsistent state message. This was not unexpected. However, after reinitializing the server, the new address was added but the old address was...
2009-10-05 15:55:02 UTC in Security Policy Manager
-
Changing a public IP address on an unmanaged PEP provoked changes on the managed PEPs (probably redefining the IP address ranges for the Internet). This produced an error on the managed PEPs that they could not properly implement or backout the dynamic changes and were thus in an inconsistent state and needed to be reinitialized.
2009-10-05 15:12:34 UTC in Security Policy Manager
-
We create a new Access Group under and existing Access Group and move the Accessors to the new Group. We then edited a policy that used the first Access Group to now use the new child Access Group. When we distributed changes, all the PEPs returned an indeterminate state error and needed to be reinitialized.
2009-10-03 20:48:59 UTC in Security Policy Manager
-
jsulliva made 1 file-release changes.
2009-09-07 22:23:02 UTC in Security Policy Manager
-
jsulliva made 1 file-release changes.
2009-09-07 22:22:01 UTC in Security Policy Manager
