This bug was discovered when trying to use learn security groups - though the bug is due to bad floating IP MAC changes.
We knew there are some missing MAC changes there but we were never affected - here's a classic case.

Pinging from VM to 8.8.8.8:
Packet from VM on ingress arrives with destination MAC of internal gateway - fa:16:3e:bf:56:c7
This causes a rule for egress to VM to be added, matching on this source MAC

However, the return ping uses the source MAC of the router gateway (10.64.0.1) - 00:1c:73:4e:d3:31
This shouldn't happen, in the floating IP translation the MAC of the internal gateway should be set, probably here where we change "router" in the metadata -
cookie=0x8000004, duration=2784.697s, table=25, n_packets=766, n_bytes=74900, priority=10,ip,nw_dst=10.64.98.3 actions=set_field:10.0.123.3->ip_dst,write_metadata:0x222e0/0xfffffffe,goto_table:27

Need to also review reverse flow - NAT from VM to outbound - should we change source MAC to router gateway? (in this case the source mac is changed to floating IP MAC in table=28, but it might be more correct this way..)

cookie=0x8000004, duration=4824.160s, table=26, n_packets=0, n_bytes=0, priority=10,ip,metadata=0x222e0/0xfffffffe,nw_src=10.0.123.4 actions=set_field:10.64.99.6->ip_src,write_metadata:0x222e2/0xfffffffe,goto_table:28