You don't really give us enough detail to answer this question with certainty. For instance, you don't give us any information about the exact nature of the traffic that is being blocked, what kind of traffic it is, forest or external trust, what ports are allowed between members of each domain, how exactly you are attempting to connect to the server, (Remote Desktop? Drive mapping?), etc. etc.
I'll take a stab anyway. Let's assume I am trying to use the Remote Desktop Client to connect to the server in the other forest. So we know that at least TCP port 3389 must be allowed between client and server.
(For reference, This document is basically the bible for how Active Directory uses Kerberos. One of the best TechNet articles on the web, IMHO. Here is another extremely relevant TechNet article about AD trusts for you to bookmark.)
During authentication using Kerberos, one of the final steps is that the client sends its service ticket and authenticator directly to the remote service that it is trying to access. (KRB_AP_REQ, and then an optional KRB_AP_REP back from the server to the client). If that cannot happen because of ports being blocked, then Kerberos authentication cannot happen. If I get a TGS referral back from my DC that directs me to your DC, and I cannot directly query your DC, I can't use Kerberos.
Perhaps that is some of the traffic that you are seeing being dropped.
So, what happens when Kerberos fails? The client typically falls back to the next security provider, e.g. NTLM. You can pass NTLM-protected credentials to the server right over the same port 3389. At this point the server just needs to validate your credentials. Please refer the section named "NTLM Referral Processing" in the second article that I linked.
NTLM Referral Processing
If the client uses NTLM for authentication, the initial request for
authentication goes directly from the client to the resource server in
the target domain. This server creates a challenge to which the client
responds. The server then sends the user’s response to a domain
controller in its computer account domain. This domain controller
checks the user account against its security accounts database. If the
account does not exist in the database, the domain controller
determines whether to perform pass-through authentication, forward the
request, or deny the request by using the following logic:
Does the current domain have a direct trust relationship with the user’s domain?
◦ If yes, the domain controller sends the credentials of the client to
a domain controller in the user’s domain for pass-through authentication.
◦ If no, go to the next step.
Does the current domain have a transitive trust relationship with the user’s domain?
◦ If yes, pass the authentication request on to the next domain in the
trust path. This domain controller repeats the process by checking the
user’s credentials against its own security accounts database.
◦ If no, send the client a logon-denied message.
So ultimately, given the limited information that you've supplied to us, that is the process that I believe you are witnessing when you authenticate to a service in the other domain.