Hi @jtaczanowski,
SFE is designed to bypass the netfilter stacks processing once it has been established (i.e. after netfilter has determined that the connection is allowed.) This is similar in design to the first rule you see in the INPUT netfilter rules:
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
The 'acceleration' is achieve by not going through the same netfilter checks for every incoming/outgoing network packets, as it is redundant, if it has been established previously to be safe.
So it doesn't really matter whether the traffic is going thru your router WAN link or through a tunnel to another location, SFE is supposed to 'accelerate' the connection.
I patched the fast-classifier code as the original codes does not work properly when it is used in conjunction with a not-physical network device and non-default routing table (in my case, an OpenVPN tunnel with Policy-Based-Routing.) The original code fails to find the correct output interface and when SFE kicks in, the network packets is discarded as it was sent to the wrong network interface.
I also encounter issues when using IPSec going through my router, whether it is directly via the router's WAN interface or via the OpenVPN tunnel. So I had to patch the IPv4 SFE code to bypass the IPSec traffic. AH traffic appears unaffected as far as I can tell. I guess it is because AH is done periodically, while IPSec traffic is more frequent and the SFE code does not track IPSec connection properly. Didn't spend too much time in this area tho. Planning to do it something in the future
My router is accelerating (it's running my custom DD-WRT build with my patched SFE codes, as it is a Broadcom router) traffic via OpenVPN tunnels just fine. A sample of the connection that goes to the WAN port and another that goes thru the tunnel is shown below from my router:
o=1, p=17 [40:cb:c0:xx:xx:xx]:192.168.28.134:37905 x.x.x.x:37905:[00:00:0c:xx:xx:xx] m=00000000 h=751
o=1, p=17 [00:00:00:00:00:00]:192.168.27.154:37905 x.x.x.x:37905:[00:00:00:00:00:00] m=00000000 h=8088
Both connections are IPSec traffic connections. First line is from local router (192.168.28.0/24) to WAN, while second line is from remote site (192.168.27.0/24) via an OpenVPN tunnel to WAN. What I noticed is that when traffic goes thru a tunnel, the MAC address is always 00:00:00:00:00:00, which makes sense as a virtual interface does not have MAC addresses.
For your case, it looks like the SFE code is still routing traffic through a physical interface, which is incorrect. So when SFE kicks in, the network packet gets discarded. I'm not too familiar with IPSec traffic routing in the Linux kernel so I'm not sure if I can help in your problem.
Maybe someone in the forum can help shed some light into how IPSec traffic are routed and we can collectively figure out how to solve this problem.