Let me preface this by saying that I have not used Fortigate, but speaking generally.
You should have two links from each firewall (FW ), one to each switch (SW), just as you have a link from each FW to each server (SRV).
This is what I suspect is happening. Assuming SW1 is the HSRP active interface, it initially receives traffic from SRV2 on the link to SW2 and creates an entry in the MAC and ARP tables. When the link between SW2 and FW2 goes down, SW2 removes the entries for that interface from it's tables, but SW1 doesn't know the link is down and maintains it's entries.
When traffic comes in to SW1 for SRV2, it looks up the ARP/MAC information and sends the traffic to SW2. SW2 doesn't have an entry for SRV2 anymore, and floods it out all ports except the one it received the traffic on (normal switch operations). This results in the traffic never reaching SRV2 as none of the other links on SW2 provide a path to SRV2.
With the second link the traffic between FWs and SWs, the flooded traffic would then be received at FW1 and be able to get to SRV2.
If you have outbound traffic from SRV2 after the link goes down, or you clear the MAC entries on SW1, I suspect that this would work as well.
I have found the issue.
The problem was my testing procedure.
I simulated the http connection using telnet to http port but I did not generate any traffic(requests). I repeated the tests using GET requests and the nat session table was replicated almost instant.
I post the debug messages.
The NAT replication trigger is the next segment, request in the tcp session.
Debug messages
Telnet from client
telnet 10.31.73.12 3099
*Nov 7 03:52:17.071: TCBB2701B60 connected to 10.31.73.12.3099
GET / HTTP/1.0
GET / HTTP/1.0
GET / HTTP/1.0
New active
Becomes Active at 03:52:32,34
NATGW2#
*Nov 7 03:52:32.700: %HSRP-5-STATECHANGE: Ethernet0/2 Grp 100 state Standby -> Active
NATGW2#
*Nov 7 03:52:32.701: IP-ADDR: ipaddr_table_insert_w_tableid() 10.31.71.254, in global table on Ethernet0/2
NATGW2#
*Nov 7 03:52:34.657: %HSRP-5-STATECHANGE: Ethernet0/1 Grp 200 state Standby -> Active
new Active listens for ARP requests for the HSRP IP
*Nov 7 03:52:34.658: IP-ADDR: ipaddr_table_insert_w_tableid() 192.168.153.253, in global table on Ethernet0/1
The nat session is recreated on the new Active.
*Nov 7 03:52:34.745: NAT: API parameters passed: src_addr:10.31.71.3, src_port:0 dest_addr:10.31.73.12, dest_port:0, proto:6 if_input:Ethernet0/2 pak:B072F0A8 get_translated:1
*Nov 7 03:52:34.745: ipnat_api_translated_address_and_port_common, out->in want IL,OL
*Nov 7 03:52:34.745: NAT: API Translated-Info(1): (src-addr:10.31.71.3, src-port:0) (dest-addr:192.168.153.12, dest-port:0)
Best Answer
For R2 to become the active HSRP router, the priority has to be higher than R1. You've set the priority on R1 to 150, and the decrement value in the track statement to 20.
So when the IPSLA "fails" R1's priority changes to 130 (150-20). but that is still higher than R2, so it remains the active router.
You can change R1's priority to 110, so when the IP SLA fails, the priority value will be 90 -- less than R2, which will make R2 the active router.