The default route for all outbound traffic is ETH2 (MPLS link with PUB IP)

Most policies from TRUST to UNTRUST have been set to Source NAT, apart from the policies used by site-site VPN's.

Track IP has been enabled, and in the event of a failure the default route changes to ETH3 (the secondary private circuit)

At the other end of the private ethernet circuit there is a managed firewall that has same rule base as ours. The problem is that the policies are set to NAT, and therefore the traffic is denied, as their firewall is expecting to see the traffic from our private IP VLAN's in the TRUST network.

I was thinking that the easiet way to resolve this issue was to:

1. Create another UNTRUST interface on our firewall, set it to route mode, and move all the VPN's to this interface. - Thus changing the gateway. I realise we would have to teardown and rebuild the VPN's, but there are only a few.

2. Change ETH2 Egress port to NAT mode.

3. Remove, the source NAT from the policies.

4. Change the MIP's to VIP's.

Voila, all done.

I have some questions based on the above.

A. Would this be a workable solution, or are there better options, and if so for what reason?

B. We are looking at getting SIP phones, with an external gateway running at the ISP on ETH2. Would this be a problem running through ETH2, as it's in NAT mode?

C. Would putting an interface in NAT mode, NAT both ingress and egress traffic?

Re: NAT policies based on route

The interface mode (route or NAT) on the egress interface has NO impact on the traffic. The NAT mode configured on the ingress interface may force a "default" src-NAT to the IP of the egress interface or may not. Everything depends on mapping of interfaces to zones and zones to the VRs. As explained in KB4761:

"Where does interfaced-based NAT work?

Interface based NAT only works From and To the following zones in the Trust-VR:

Trust zone to Untrust zone

Trust zone to DMZ Zone

Traffic From and To other zones will be routed.

The behavior for interface NAT with the Untrust-VR is different. If the destination zone is in the Untrust-VR, then NAT will take place from ANY zone."

This kind of NAT is a (bad) legacy from the earliest ScreenOS days. I would recommend to never use it.

In your case the NAT mode on the trust interface forces the src-NAT on the untrust interface even when you do not want it (VPN).

I always use the route mode on all interfaces and an explicit policy-based src-NAT.

Everything can work correctly with the initial configuration if NAT mode is not selected. Converting of MIPs to VIPs is also required because the policy based src-NAT does not override the MIP bidirectional behaviour. The packets sent from the mipped host are src-NATed to the MIP IP which is public.