I am not able to get internet traffic through the firewall from MPLS net.
Environment is as follows, the firewall (8.3 appliance) has three interfaces, external, internal and DMZ.
The internal interface is connected to 10.10.0.0/16, which is the primary Lan, onto this Lan a MPLS router is connected with ip address 10.10.100.1, and on the other side, the MPLS network 10.199.0.0/16.
I have created a static route on the firewall 10.199.0.0/16 10.10.100.1, and allowed interzone traffic.
I can ping in both directions, from the firewall to a host on the MPLS, tracert to the MPLS, and vise versa, I can connect to and use terminal servers on 10.10.0.0/16 from the MPLS.
No problem with Internet or any other traffic from the 10.10.0.0/16 network through the firewall.
But I am not able to establish any traffic from the MPLS network through the firewall !!!
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.