Log in to ask questions, share your expertise, or stay connected to content you value. Don’t have a login? Learn how to become a member.
Just upgraded to 10.4 on SRX210H.
Added static NAT
Added policy to allow ping to internal host
added proxy arp
Traffic flows great.
deleted policy and commit. traffic still flows
removed static nat and traffic still flows
removed proxy arp, then traffic stops
Do you have "set security policies policy-rematch" statement in the config?
that is the problem. So as long as the session is live the policy lives by default?
Traffic matching an established session will continue to flow as long as that session remains active. When you delete the security policy, no *new* flows will be created, but existing flows will stay active until they age out.
As Alex suggested, using policy-rematch will cause all active sessions to be re-evaluated against the security policies upon a commit, and sessions will be torn down if they are no longer permitted.
You can also manually clear the sessions using "clear security flow session" and specifying various criteria -- or clearing ALL sessions. Be careful with that, because it will drop ALL sessions and any existing flows will stop and need to be restarted, including your SSH session to the CLI and all your users' traffic flows. 🙂
I think you are not right!
When a policy is deleted all via this policy established sessions are deleted; when you change the policy name with "replace pattern" first the old policy is deleted and than a new one is inserted --> all established sessions are deleted too.
From JTAC I have got the answer that this is the normal behaviour.
@sok wrote:Hi keithr, I think you are not right!
Yeah, I get that a lot. It happens.
@sok wrote:When a policy is deleted all via this policy established sessions are deleted; when you change the policy name with "replace pattern" first the old policy is deleted and than a new one is inserted --> all established sessions are deleted too.From JTAC I have got the answer that this is the normal behaviour.
If you have "policy-rematch" configured, then it will behave like this. If "policy-rematch" is *not* configured, then the sessions will not be cleared when a policy is changed.
That is... unless Juniper changed the default behavior and I didn't get the memo... but I'm pretty sure it's still as it's documented, i.e. "policy-rematch" is necessary if you want your device to re-check all sessions for validity after policy changes.
To the best of my knowledge without policy-rematch configured sessions will only be cleared if the matching policy is deleted. I don't know if this holds true when the policy is renamed. Otherwise if policy-rematch is configured all sessions will be reevaluated upon commit. Unless, as keithr mentioned, Juniper changed this behavior.
here the answer from JTAC:
"When you change a policy name, it deletes the policy out and adds a new policy. There is not any way to get around this. I understand that this may not be how you expect the device to handle this, but unfortunately there is not anything that I can do to change this behavior.The command "policy-rematch" makes it so that when there are existing sessions and a policy is changed, all of the existing session have to be re-matched to the policy and will therefore be dropped if they do not match the change in the policy.The SRX is a security device and therefore when it was designed it was not designed to allow the policy names to be renamed on the fly. Other parts of the policy can be changed without making changes to existing sessions such as adding new address objects to a source or destination in the policy, but the device was not designed to allow the name to be changed. When the name is changed the device sees the policy as a new policy and therefore cannot match existing sessions to the new policy."
Is it have bug in vSRX3.0 (cluster) version 21.1 for policy-rematch?. I'm try the policy-rematch it not work until i do "commit full" during first apply policy-rematch.
Is it requirement we need do "commit full" during first apply knob "policy-rematch"
Thanks and appreciate any feedback