SCCM 2012 - Network requirements for Client communication to primary in a Cross Forest Environment

Question

Hello, I have been trying to get some definitive answers on what network traffic is required between a client and a primary site versus a secondary in a cross forest scenario.
Here is the scenario:
Company A has an existing SCCM 2012 primary Site. Company B (Separate Forest) has now been brought in. One subnet on each side can route to each other and using that one subnet a two way forest
trust has been setup. But the remote offices have IP address overlaps between companies. At some point in the future all assets on company B will be re-IP and brought over to Company A domain. But in the interim it would be nice to get SCCM cross forest clients
working. Upgrading to a CAS model with two Primaries would not be preferred here as this is a temporary solution. 
My questions are as follows.
If a secondary site is deployed into Company B Forest/Network. I have seen people online elude to that clients will still need to communicate to the Primary located at Company A, even though they
are assigned to a secondary on Company B’s network. Is this true? Is there any workarounds for this? Is a NAT back to the primary acceptable, or is reverse lookup required?
Will the Primary need to communicate directly to the clients in Company B? If this is in fact a requirement, then this would be a show stopper. But if its only needed for things like client pushes,
then we could work around it.
Thanks

Answer 1

"But the remote offices have IP address overlaps between companies"
Technically, this is unsupported because clients, depending upon your boundaries, will not be able to find a local DP since they use IP addresses for this. The only way to work around this is to use AD Site boundaries.
"though they are assigned to a secondary"
Clients are *never* assigned to a secondary site -- that's not what secondary sites are for. Yes, clients require communication with an MP in the primary site where they are assigned. There is no way to change this or work-around this except to put
an MP from the primary site closer to those clients and use the new MP affinity option in R2 CU3.
Reverse lookups are only used to verify names by applications that wish to have this type of functionality (which are very few in number) and have nothing to do with true network traffic. NATing is an issue for the reason I gave above -- DP location.
Remote control, client push, and WoL won't work either because there is no way for the traffic to reach the destination behind the NAT.
All client *agent* communication in ConfigMgr is client initiated in ConfigMgr (remote control, client push, and WoL -- as just mentioned -- are sort of exceptions to this but they don't really involve the client *agent*.)
Jason | http://blog.configmgrftw.com | @jasonsandys