I believe you have to setup ePO to talk on both NICs somehow if I remember correctly. I think it dates back to some of the steps you had to take when implementing ePO itself...
Have you looked at using an Agent Handler on the second network? Then point the agents over there to see it as their main contact point to talk to ePO. You'll have just the one relationship to work through the firewall. Does need an upgrade on the server to ePO 4.5. UPgrading MA to 4.5 gives more robustness (fallback addrs for agent handlers, the server etc) but MA 4.0 can also see the single "server" that would in reality be the agent handler.
Thanks for the suggestions, I think the problem may lie in the SiteList.xml file on the laptop I'm testing with. The ePO server IP in the xml file points to the wrong server IP. Instead of pointing to the 140.x.x.x network, it's pointing to the internal 192.168.x.x network (which the laptop can't hit because it's outside the firewall). I'm gonna work on this a bit and post what I find out.
I have the identical setup - some of my computers on the other side of a firewall in a different address range.
I discovered the same thing - sitelist was preventing the agents from checking in because the firewall had been recently installed.
I created a distributed repository on my ePO server and replicated to it. I manually placed the new serversitelist.xms and sitelist.xml to the appropriate directory on the clients in the remote network and forced the agent to check for new policies. in addition i added an entry into the host file of each remote machine pointing back to the ePO at its address behind the firewall. this forced them to go through the firewall.
the firewall will have to have the necessary ports enabled for the remote machines of course.
once they checked in they will now follow any changes to sitelists or policies etc.