Hello, We are encountering a problem with sessions:
We are running two Radius servers, One device is trying to authenticate against these two Radius servers which are running VRRP in between themselves. The authentication traffic between the "device" and Radius servers is passing through SRX4600 firewall.
If failover of the Radius server happens, authentication to the server (passthrough Radius traffic) stops working. Sessions on the SRX4600 don't react to the change in ARP table and they keep sending traffic to the old MAC address (00:50:56:9b:cf:cb), Which leads to the loss of traffic because it's still being sent to the wrong server. Authentication stops working because of it and it causes us problems. Sessions don't timeout even after 20 minutes of waiting. When we use following command: clear security flow session source-prefix X.X.X.X destination-prefix Y.Y.Y.Y the firewall establishes new sessions and authentication starts working. Could you please let us know whether it's expected behaviour or if it's a bug or if there is any workaround.
When the Radius server fails over (VRRP changes mastership), the Mac address gets changed in the Arp entry, and also the PFE shows correct interface to the exit out of SRX, however traffic related to radius server keeps on dropping.
Ip X.X.X.X communicates to Radius Y.Y.Y.Y (VRRP address) it uses udp 1812 session.
Lab@JTAC> show security flow session source-prefix X.X.X.X destination-prefix Y.Y.Y.Y
node0:
--------------------------------------------------------------------------
Session ID: 171853465615, Policy name: aruba20220916001/4601, State: Active, Timeout: 58, Valid
In: X.X.X.X/41185 --> Y.Y.Y.Y/1812;udp, Conn Tag: 0x0, If: reth5.2123, Pkts: 1668, Bytes: 894419,
Out: Y.Y.Y.Y/1812 --> X.X.X.X/41185;udp, Conn Tag: 0x0, If: reth5.2009, Pkts: 1662, Bytes: 1059141,
Session ID: 171857803077, Policy name: aruba20220916001/4601, State: Active, Timeout: 56, Valid
In: X.X.X.X/33311 --> Y.Y.Y.Y/1812;udp, Conn Tag: 0x0, If: reth5.2123, Pkts: 1642, Bytes: 857259,
Out: Y.Y.Y.Y/1812 --> X.X.X.X/33311;udp, Conn Tag: 0x0, If: reth5.2009, Pkts: 1646, Bytes: 1045732,
Session ID: 171859205997, Policy name: aruba20220916001/4601, State: Active, Timeout: 54, Valid
In: X.X.X.X/60696 --> Y.Y.Y.Y/1812;udp, Conn Tag: 0x0, If: reth5.2123, Pkts: 109, Bytes: 26178,
Out: Y.Y.Y.Y/1812 --> X.X.X.X/60696;udp, Conn Tag: 0x0, If: reth5.2009, Pkts: 109, Bytes: 9800,
Total sessions: 3
When VRRP changes mastership from one Radius server to the other it changes it's MAC address. Firewall recognizes it in it's ARP table.
lab@JTAC> show arp no-resolve | match Y.Y.Y.Y | refresh 2
---(refreshed at 2023-04-27 12:25:30 CEST)---
00:50:56:9b:cf:cb Y.Y.Y.Y reth5.2009 none
---(refreshed at 2023-04-27 12:25:32 CEST)---
00:50:56:a3:41:51 Y.Y.Y.Y reth5.2009 none
Once this change happens, and is recognized by SRX, Authentication pass-through traffic on port 1812 through SRX starts to drop and users start getting authentication fail messages.
The above mentioned issue is caused because of service-offload.
This is because, when the session is first initiated and service-offload gets called in, it updates the details to the PFE, however when the change in MAC address happens, service-offload does not have any way to update the PFE that the MAC address has changes for a session which is already anchored on the IOC.
The solution for this is to enable selective service offload on the device for the traffic under security policy.
Once service-offload for this traffic is disabled, any changes in regards to the Mac address gets updated to the PFE for the session which is already active.
Or the other option is to clear the flow session on the device manually.
https://prsearch.juniper.net/problemreport/PR1755181