In addition to Matt's suggestion (which will show if the Firewall is blocking the connections), I would also suggest running a tcpdump on the internal side of the Firewall to see if the traffic from a host on the 10.199.0.0/16 subnet actually arrives in the first place.
I generally use:-
tcpdump -npi 1-1 host <source_ip_address>
-where 1-1 is the internal interface (I think - as 1-0 is normally the first configured interface and is the external NIC), but you can always confirm this first from the GUI.
Intrazone traffic has been something of a bugbear for me, since the very simple checkbox setting in v6 was removed and I'm still not 100% certain about its configuration in v8.
But, to be fair, as the traffic is originating from the other side of a routed connection I don't think that the intrazone configuration is an issue. It only tends to be one when the client machines are using the Firewall as their default gateway/route that you need intrazone routing configuration.
If you can ping across the MPLS link between the two networks OK, the problem may be that the MPLS routers themselves don't have a default route and don't know what to do about any traffic not destined for either the 10.10.0.0/16 or 10.199.0.0 subnets. This is hopefully what the tcpdump should prove.
If you see results from this, it means that we are back to Matt's suggestion - check the Firewall audit and see what the Firewall is doing.