My best guess is that the problem is in AT&T's QoS settings in their Cisco routers at the offices, although it could be anywhere on their network.

Despite the fact that the VoIP calls are fully encrypted and encapsulated inside the VPN tunnel, it is still possible for them to be identified as VoIP calls by pattern matching the constant stream of identically sized packets, even though it is impossible to see what is in those packets. It seems that once the AT&T router identifies there is a VoIP call passing through the router, it is imposing bandwidth and connection limits on any traffic going inside the VPN tunnel, trying to make it fit into the steady pattern of a VoIP call, and effectively breaking any non VoIP connection currently in place. Once this was happening, the router at the remote office did what it was supposed to do and maintain the priority of the VPN traffic over the regular internet traffic and the since the router had a backlog of VPN traffic it was trying to push though, it interpreted this backlog as a bandwidth limitation and did the only thing it was able to do, slow down the rest of the internet traffic in attempt to reduce the load on the connection and deliver the VPN traffic. Thus causing the users to experience the slow connection speeds when web-browsing. It is likely this connection and rate limiting by AT&T only applies to the inbound traffic to Northbrook, and they impose no restriction on the data transmitted, otherwise we would have seen connection slowdown issues at the main office just like the remote offices experienced when the router ran into a backlog of traffic trying to send out.