Another issue not addressed by fastforwarding is the change of the routing table through pfil (i.e. setfib in ipfw). After the outgoing pfil hook there should be a check to see if the routing table has changed. If it has ip_findroute() should be called to determine the new route.

Possible patch:

After a lot of testing I found the culprit:
removal of the lines 515-516 resolves my bug.

515  if (mcopy)
516                m_freem(mcopy);

the question is why?

I am trying to find where the problem lies but without success so far.
However if I add the following right after line 311 ("passin :") the bug dissappears:

Regarding my previous comment, I was running 10.2-RELEASE and had not turned fastforwarding on.
The bug still persists. I think there might be a problem with the fastforwarding routine as this does not happen when fastforwarding is off.
Steps to reproduce:

1. WAN-interface: route change default -mtu 1196
2. Browse some pages with a client machine
3. Try to access the gateway via ssh on the LAN-interface.

@ae
I think you are right. I am currently trying with "hw.em.enable_msix=0" and it seems to work ok!

On a vanilla 10.2-STABLE with the latest available kernel and applied patch I get this (ipfw+nat):

With the patch backported to 10.2-RELEASE I got a kernel panic today.
I will try to get a dump.

I backported this to 10.2-RELEASE and it runs ok. Mistakenly I was running the 10.2-STABLE kernel on a 10.2-RELEASE userland.

I tried this on my gateway running 10.2-STABLE but it keeps crashing, meaning I am losing all connectivity including IPMI. On the IPMI console I do not see any panic. In the logs I do not see anything unusual.