Hi mgillespie2,
10 times slower seems a bit much.
I have a 2862 and use LAN-to-LAN with IPSec and have no real speed issues, it is a little slower than unencrypted, or lesser encrypted traffic, mainly because of the encryption/decryption processing - as you mentioned, but, also because of the header room needed inside the packets for the method you are using, whatever that may be, as it eats into the size of the payload you can send across the connection.
You can test your payload size (MSS) by sending a ping packet with a specific size of your choosing. You could do this test before making any changes to see what the difference currently is.
Open a cmd prompt (on Windows) and ping the router (or a device) at the remote site to make sure your pings echo back, then try adding a payload larger than the default by typing:
ping 192.168.5.1 -l 1350
(I’ve used a random ip address here)
If that packet echos back, try increasing it until it doesn’t echo back. The -l 1350 is the payload size, minus everything else involved in the packet (headers etc).
Once you know what your maximum payload size is, you can try to make some adjustments to help pass the largest possible payload across your connection.
You will most likely be limited by the standard MTU of 1518 bytes (sometimes 1520 with added head-room) which generally gets set to 1500 by most shipped units; which is fine.
Max that MTU out at every possible point, to 1500, if you can. Nowadays you don’t need to worry too much about leaving head-room, like setting it to 1485, as most equipment will automatically adjust the payload size to allow for the header space it needs.
When you have matched this test on both your LAN-to-LAN and your Client App connection and can send the same size payload, or not, through both then you’ll know why one is faster than the other and if it’s the payload or the processing that is the bottle-neck.
