Juniper SRX Policy Rematch feature allows SRX device to re-evaluate active sessions whose associated policy has changed. Therefore, active sessions with changed policy will remain open if they are still allowed to be forwarded, otherwise they will be closed.
Juniper SRX Policy Rematch Fundamental
To better understand the concept behind Juniper SRX Policy Rematch, suppose that we have many policies in the security policies and “permit SSH” is also between these policies.
There is an active session from the IP address 192.168.1.10 to the destination IP, 1.2.3.4 and destination port 22 or SSH which is permitted by SSH policy.
Now we change the related policy. What happens to the active session?
comparing policy-rematch with default behaviour
By default, Juniper SRX keeps the active sessions, associated with the modified policy, be open unless the policy is renamed, deactivated or deleted. In other words, changing source address, destination address, application or action of the policy doe not close active sessions.
This is because, traffic related to active sessions are not inspected with the policy and it is the default behaviour in any stateful firewall.
But with “policy-rematch” feature, any active sessions associated with the modified policy will be re-evaluated to decide whether they must remain open or must be closed.
“policy-rematch” has an “extensive” option and the behaviour is different when we use “extensive” option or when we don’t use “extensive” option.
Without “extensive” option, , the active sessions will be re-evaluated against only the modified policy to decide if active sessions can remain open or must be closed.
This is true when the source address, destination address or the application of a policy changes. But active sessions are closed if the action of associated policy is changed to deny traffic or when the associated policy is renamed, deactivated, or deleted.
But with “extensive” option, juniper SRX re-evaluate active sessions associated with a modified policy against all policies to decide if they can remain open or must be closed. It happens even if the policy is deactivated, renamed or deleted.
Be notice that extensive option does not work correctly in specific cases for example ALG data sessions.
Juniper SRX Policy Rematch Configuration
To configure and test “policy-rematch” feature, we will create a SSH session from inside to the outside once without “policy-rematch” feature, once with “policy-rematch” but without “extensive” option and once with “policy-rematch extensive” option.
In each case we will change the policy and monitor the behaviour of active sessions.
Default (without "policy-rematch"): Change the action of Policy to Reject/Rename the Policy
In the first configuration example, we configure no “policy-rematch” option and we want to see the default behaviour of active sessions when associated policy changes.
Let’s firs make sure that SSH traffic is permitted from inside to outside zone with “show configuration” command.
rayka# run show configuration security policies from-zone inside to-zone outside | display set | grep SSH
set security policies from-zone inside to-zone outside policy PERMIT-SSH match source-address NET_192_168_10_0__24
set security policies from-zone inside to-zone outside policy PERMIT-SSH match destination-address any
set security policies from-zone inside to-zone outside policy PERMIT-SSH match application junos-ssh
set security policies from-zone inside to-zone outside policy PERMIT-SSH then permit
set security policies from-zone inside to-zone outside policy PERMIT-SSH then log session-init
set security policies from-zone inside to-zone outside policy PERMIT-SSH then log session-closeNow we make an SSH session from inside to outside zone. then we monitor the session with “show security flow session | grep /22” command.
rayka# run show security flow session | grep /22
In: 192.168.10.121/4828 --> 192.168.1.111/22;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 26, Bytes: 3016,
Out: 192.168.1.111/22 --> 192.168.1.250/27919;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 32, Bytes: 5277, As you can see, SSH session is active between 192.168.10.121 in inside zone and 192.168.1.111 in outside zone.
now we change the action of the policy from permit to reject. Then we check again status of active session associated with SSH policy.
[edit]
rayka# delete security policies from-zone inside to-zone outside policy PERMIT-SSH then permit
[edit]
rayka# set security policies from-zone inside to-zone outside policy PERMIT-SSH then reject
[edit]
rayka# show | compare
[edit security policies from-zone inside to-zone outside policy PERMIT-SSH then]
- permit;
- log {
- session-init;
- session-close;
- }
+ reject;
+ log {
+ session-init;
+ session-close;
+ }
[edit]
rayka# commit
commit complete
[edit]
rayka# run show security flow session | grep /22
In: 192.168.10.121/4828 --> 192.168.1.111/22;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 26, Bytes: 3016,
Out: 192.168.1.111/22 --> 192.168.1.250/27919;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 32, Bytes: 5277,
[edit]
rayka# run show security flow session | grep /22
In: 192.168.10.121/4828 --> 192.168.1.111/22;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 26, Bytes: 3016,
Out: 192.168.1.111/22 --> 192.168.1.250/27919;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 32, Bytes: 5277, As you can see, the session is still active , however the action is changed to be rejected. This is because active session is not evaluated against the policy.
But if we rename, deactivate or delete the policy, we expect that the active session will be closed.
To test it, we just rename the policy from PERMIT-SSH to PEMIT-SSH1 to see the behaviour of active sessions.
[edit]
rayka# rename security policies from-zone inside to-zone outside policy PERMIT-SSH to policy PERMIT-SSH1
[edit]
rayka# commit
commit complete
[edit]
rayka# run show security flow session | grep /22
[edit]
rayka# run show security flow session | grep /22
[edit]
rayka# As you can see, active session related to SSH policy is discarded when we rename policy.
with “policy-rematch”: Change the action of Policy to Reject
In the second example, we enable “policy-rematch” feature but without extensive option.
in this case, when we change the policy, it is expected that exact this policy will be re-evaluated.
We create an SSH session from inside to outside and check the status of the session with “show security flow session” command.
Then we change the action of the policy from permit to reject.
It is expected that the SSH session is discarded when it is re-evaluated.
To make sure, we monitor the session again with “show security flow session” command. As you can see, the session is finally discarded.
[edit]
rayka# set security policies policy-rematch
[edit]
rayka# commit
commit complete
[edit]
rayka# run show security flow session | grep /22
In: 192.168.10.121/4828 --> 192.168.1.111/22;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 28, Bytes: 3160,
Out: 192.168.1.111/22 --> 192.168.1.250/27919;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 33, Bytes: 5429,
[edit]
rayka# delete security policies from-zone inside to-zone outside policy PERMIT-SSH then permit
[edit]
rayka# set security policies from-zone inside to-zone outside policy PERMIT-SSH then reject
[edit]
rayka# commit
commit complete
[edit]
rayka# run show security flow session | grep /22
In: 192.168.10.121/4828 --> 192.168.1.111/22;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 28, Bytes: 3160,
Out: 192.168.1.111/22 --> 192.168.1.250/27919;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 33, Bytes: 5429,
[edit]
rayka# run show security flow session | grep /22
[edit]
rayka# with “policy-rematch extensive”, Rename the Policy
In the last example, we use “policy-rematch extensive” command.
Again we generate a SSH session from inside to outside and check the session with the command “show security flow session”.
Then we rename the policy from “PERMIT-SSH” to “PERMIT-SSH1”. Unlike previous two cases that active sessions are closed when the policy is renamed, with “policy re-match extensive” case, active sessions are re-evaluated against all policies and it is expected that the SSH active session remain open.
We can check the status of the session again with the command “show security flow session” after renaming the policy.
[edit]
rayka# set security policies policy-rematch extensive
[edit]
rayka# show | compare
[edit security policies]
+ policy-rematch extensive;
[edit]
rayka# commit
commit complete
[edit]
rayka# run show security flow session | grep /22
In: 192.168.10.121/4535 --> 192.168.1.111/22;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 27, Bytes: 3056,
Out: 192.168.1.111/22 --> 192.168.1.250/28748;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 32, Bytes: 5277,
[edit]
rayka# rename security policies from-zone inside to-zone outside policy PERMIT-SSH to policy PERMIT-SSH1
[edit]
rayka# commit
commit complete
[edit]
rayka# run show security flow session | grep /22
In: 192.168.10.121/4535 --> 192.168.1.111/22;tcp, Conn Tag: 0x0, If: ge-0/0/1.0, Pkts: 32, Bytes: 3448,
Out: 192.168.1.111/22 --> 192.168.1.250/28748;tcp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 35, Bytes: 5733, As you can see the session is still open even after renaming the policy.
hello
very good video thanks, but one question i have read in many places that an existing active session is saved to the session table and when the policy is deleted the session continues until it ages out can you explain this please?