In scenarios in which the client and SF1 are in different computes, if vxlan_tool is running in SF1, the vxlan_tool decrements the nsi, sends the packet back to the SFF as expected, but, it also consumes the packet which it just sent. Therefore, the tool starts generating packets artificially with decremented nsi:

NSH base nsp: 48, nsi: 255
NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800
NSH base nsp: 48, nsi: 254
NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800
NSH base nsp: 48, nsi: 253
NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800
NSH base nsp: 48, nsi: 252
NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800
NSH base nsp: 48, nsi: 251
NSH context c1: 0xac1df00c, c2: 0x00000000, c3: 0x00000000, c4: 0x90000800

This breaks the topology in which two SFs are in one chain and deployed in the same compute and SF2 is blocking packets (firewall). As SF1 will generate packets with nsi=253, even if SF2 drops packets, the chain logic will decapsulate the nsi=253 packets and they will reach the destination