We outsourced the encryption part of a VPN, but I recently setup a GRE tunnel between a 6500 and a 1811 router that passes through the VPN for EIGRP and full routing control (instead of being reliant on the SonicWall's rules).
This is setup as a hub and spoke method, the 6500 on the main campus is connected to a SonicWall. At that point all traffic managed by the outsourcing company, and passes through a VPN on the Internet to the remote site, which has another SonicWall, and is connected to an 1811.
I setup the two remote sites exactly the same (except for a difference of ip addresses), and went through and compared the configs to make sure they were basically identical. In both cases, almost all communication is working fine, EIGRP is passing routes, all traffic to the Internet is fine (which passes through the main site). VoIP phones are working fine, I was able to use AFP against a server, DNS is fine, DHCP is fine, a number of other services are fine, but on just one of the sites HTTP/S to internal sites is only partially working.
I did a tcpdump on both ends on the connection (Mac to a Linux server), and the initial packets make it through just fine. After the initial packets (enough to verify a SSL certificate, and sometimes a bit more), the Linux server will try to continue sending packets, but the computer on the remote side stops receiving them. Everything else, including HTTP/S connections to the Internet works fine. I tested turning off the ACL on the server subnet (the only place where a ACL is applied for this test currently, on the 6500), and it didn't make a difference.
Any ideas on where I could potentially start troubleshooting this/things to check for?
My guess would be that you have a fragmentation issue. When running GRE (and also with IPSec) adding the extra header to packets may produce packets that exceed the maximum size and require fragmentation. But if the IP header has the dont fragment bit set then the packet can not be fragmented and will be discarded. One way to address this is to use the adjst mss command (I typically do it on the LAN interface where users or servers are conneted). Try configuring:
ip tcp adjust-mss 1300
on the interface and see if it improves your problem.