Assume that the following TLS proxy exists
User <-----> Load Balancer that decrypts, encrypts <------> WebServer
Where the web server is running a vulnerable version of OpenSSL.
Can the user exploit the web server if it is vulnerable to TLS or Beast, assuming the first link to the load balancer is secure?
BEAST is a vulnerability on the client, not on the server. A server is not, and never has been, "vulnerable to BEAST". There is some confusion about tools that "test SSL servers", that may report a "BEAST vulnerability" if the server fails to fix a vulnerable clients -- namely, if the client is vulnerable, and specifies in its ClientHello that it prefers to use a cipher suite with a block cipher in CBC mode, and also says that it accepts to use a non-vulnerable cipher suite (e.g. based on RC4), then the server has the possibility to save the client by choosing the non-CBC cipher suite, despite the client preferences. When the server does not do that, SSL testing tools will report "vulnerable to BEAST", but the vulnerability is still on the client, not on the server.
That being said, both BEAST and CRIME rely on a usage context where the attacker can do all of the following:
The attacker can choose part of the data that gets encrypted, along with some secret data that the attacker is very interested in (typically, an HTTP cookie).
The attacker can see the encrypted result.
Information obtained from point 2 can be used for point 1: the attack is adaptive.
In your case, this would require that the attacker can eavesdrop on communications between the load balancer and the Web server, and can choose the data that gets encrypted by the load balancer. Since the load balancer encrypts data that it just decrypted, straight from the user, the concept of BEAST and CRIME applies. This is true regardless of how the data is conveyed from the user's browser to the load balancer. That specific TLS protects data in transit between the user and the load balancer, but the attack really is on the connection between the load balancer and the Web server, i.e. out of the scope of that first TLS.
Things will still be challenging for the attacker, for the following reasons:
The usual method by which an attacker can both insert his data in the plaintext stream and observe the encrypted result is through a fake WiFi access point. However, in your situation, the attacker must somehow inject his malicious JavaScript on the client side (so he must be close to the user, network-wise), but also observe things on the internal network between load balancer and Web server. The attacker must be at two places at once.
BEAST does not work any more. To apply the attack, the attacker must have rather fine control on the bytes that he adds to the plaintext stream; mere HTTP headers are not sufficient. Note that we are talking here of the malicious code that runs on the client, i.e. within the context of the user's browser. The BEAST authors had found two ways to push their bytes in the stream, using a Java hole, or a draft implementation of WebSockets. Both holes have been fixed in browsers for several years.
Even if BEAST still worked, it might still have trouble getting through the load balancer: the fine-tuning of the attacker's additional input is not compatible with HTTP request; things must be a little more low-level than that.
CRIME will get through fine, though.
