Backups take so long that the firewall closes the connection

Background on ASA Timeout/Timers:

The global timeout conn is TCP virtual circuit (session) idle timer and defaults to 60 minutes. The global timeout udp is for UDP holes and defaults to 2 minutes. The global timeout xlate is for clearing up translations that linger around after a conn has timed out. The conn (TCP) timeout takes precedence over the xlate timeout. The next paragraph further explains the relationship between conn and xlate timers.

If a conn is successfully torn down via TCP teardown, the conn and xlate go with it (if dynamic xlate, static NAT and static PAT xlate's are never removed). If a conn times out, then the xlate timer is taken into account. If the xlate times out first (you set it real low) it will not take down the connection until the conn times out.

The ASA has several methods for dealing with the varying timeouts. Conn is one where the global setting can be overridden based on class-map -- this should be preferred over increasing the global setting if possible.

The other interesting feature the ASA possesses is dead connection detection -- DCD. DCD allows you to keep your [global] conn timeout at 60 minutes (the default) and when 60 minutes is reached -- the ASA man-in-the-middle spoofs null data ACKs to each endpoint as the other endpoint. Null data works to prevent the sequence numbers from incrementing. If both sides respond the connection's idle timer resets to 0 and begins again. If either side does not respond after a set number of attempts (configurable) in a given period the conn is removed and the xlate timer gains relevance as described above.

I'd recommend configuring a class-map and adding it to your policy that enables DCD. You can use an ACL or a port (others are available as well). Using the port is quick, easy, and will work well if you are certain the TCP/5633 is where the problem sits..

I have used the global_policy below but feel free to adjust as necessary.

class-map BE-CORBA_class
 description Backup Exec CORBA Traffic Class
 match port tcp eq 5633

policy-map global_policy
 class BE-CORBA_class
  -->::Choose one below::<--
  set connection timeout idle 1:00:00 dcd --> for 8.2(2) and up
  set connection timeout tcp 1:00:00 dcd --> for prior to 8.2(2)

service-policy global_policy global

@Comment

According to the reference guide -- "A packet can match only one class map in the policy map for each feature type."

The key phrase is in bold. A packet crossing an interface can match multiple classes inside of a policy-map, but only if those classes use different "features." If you scroll up just a tad in the aforementioned link you will see the various features listed. That whole page is a goldmine for MPF tidbits.

As you mentioned that you have a match any class-map defined and then referenced as a class inside the policy-map -- if you are performing any other TCP and UDP connection limits and timeouts changes in that policy-map class, then subsequent class-maps that match the traffic -- if set in the policy-map -- will not perform TCP and UDP connection limits and timeout changes on that packet.

If you post all the ACL's, class-map's, policy-map's, and service-policy's we can determine for certain.

As much as I'm not a fan of applications taking their toys and going home (and failing the backup) when one single TCP session gets killed, in this case I'd say just up the ASA's TCP session timeout.

Putting a hard limit on session length at all is really just a product of the ASA's need to track all connections to maintain state (and usually, NAT) - if you're running against your device's connection limit, then it may be an issue, but otherwise, just crank it up to 6 hours or something.

Unless both nodes at the ends of a TCP session go dark, the ASA will bear witness to one end or the other ending the connection when it ends naturally, and tear down the connection then (or trigger the shorter half-closed connection timeout), so you're unlikely to end up with a ton of dead connections clogging things up. The endpoint devices have an interest in tearing down useless connections, too - web servers are a good example, as they'll usually have much shorter connection timeouts than your ASA.

You might consider using a generic TCP proxy on the remote Linux machine that answers and forwards the connections from Backup Exec to the local CORBA port. (You could easily arrange for the Backup Exec server to connect to this proxy by way of the NAT rules on your firewall.) That TCP proxy would need to have the SO_KEEPALIVE option set on the listening socket it creates. My proxy-of-choice is rinetd, but a quick look at the source shows that they're not setting the SO_KEEPALIVE option on their listening socket (so you'd have to modify it to get the behavior you want). There maybe another generic TCP proxy that does set SO_KEEPALIVE by default (or as an option) but I'm not aware of one off the top of my head.

Another option might be to bring up an SSH tunnel to the remote machine as part of a pre-job script w/ the SSH client set to either use SO_KEEPALIVE or SSH null packets to keep the connection alive.