Unfortunately multiple interfaces is a lesser-used feature of the SSL VPN and since we don't expose all parts of the routing table (specifically source-based routing) it's possible in some cases for the SSL VPN to receive an incoming connection (i.e. the SYN part of a TCP handshake) on the IP address on NIC2, but try to respond by sending the SYN/ACK out of NIC1. This has only affected a handful of customers but for those that are affected there isn't really a quick fix.
Generally speaking, for a deployment like this, I would recommend simply having a single NIC in the DMZ part of your network and then explicitly allow traffic from the DMZ zone into your internal network as required. The SSL VPN appliance comes with virtually no access control so by attaching it in the way you have, you are not really getting the advantages of a DMZ because clients that connect to the SSL VPN with Network Connector/IPsec will be able to hit your internal LAN directly anyway because the SSL VPN does not perform any firewalling functionality. The SSL VPN appliance is really just designed to be a "leaf" device, as it is lacking certain features that make it suitable for connecting multiple networks together.
Alternatively, you should look into the CloudGen Firewall which is the replacement product - the TINA VPN functionality performs better and is more secure, and the CloudGen Firewall is a firewall so access control is handled too.