Yes I understand your scenario and your requirement ..to access resources on remote firewall on port RDP ie 3389 from fortigate 200d connected switch lan users
For your requirement no natting required.
.
Please configure static route in fortigate 200D as below
Ip route 10.48.1.0 255.255.255.0 points towards gateway 10.189.254.17
And for reverse traffic static route in remote n
/W firewall
Ip route 192.168.60.0 255.255.255.0 pointing towards gateway 10.189.254.18
And have a security policies in firewalls allowing traffic
Policy in fortigate 200D
Source interface : interface Port need to mention Destination interface : interface Port need to mention Source address :192.168.60.15/32 Destination address :10.48.1.4/32 Port :tcp-3389 Action : allow Security profiles : on
Now security policy in remote n/w firewall
Source interface : egress interfàe of firewall Destination interface :ingress interface of firewall Source address : 192.168.60.15/32 Destination address :10.48.1.4/32 Port :3389/TCP Action : allowed Security profiles :on
.
Now user of fortigate 200D lan users can access internal hosted server on remote network firewall on port 3389
For futher security if you wants to hide your ips then you can use source natting in fortigate 200D firewalls but to accomplish this you need to configure static route in fortigate 200d with destination as source nat pool pointing.
Towards gateway 192.189.254.17..likewise..
I upgraded to 5.4.0 and it fixed the issue. Prior to upgrading I could reproduce the issue by rebooting the PPPoE router and the VPN would not come back up with debug showing the error "could not locate phase1 configuration". This is no longer an issue after upgrading. The VPN auto reconnects after a reboot. Time will tell, but I suspect that future power outages will no longer require human intervention to re-establish the VPN tunnel.
Best Answer
Just providing 2 egress policies won't suffice.
Traffic to unknown target networks has to follow the default route. But, there is only 1 default route per system/FGT (for obvious reasons). To match a (static) route the FGT only looks at the destination IP address.
In your case, this is not enough because you want traffic from different sources to follow different routes through different interfaces. For this, use a Policy Route. To match a PR, you can specify the source subnet address as well as the destination (which is '0.0.0.0/0' for the default route).
So the steps to take are:
1- pull WAN2 from the WAN zone to make it addressable. WAN1 remains in the zone, no changes required.
2- create a Policy route as mentioned, through WAN2
3- create an additional egress policy for 'lan' to 'WAN2'. Don't forget to enable NAT!