Hi,
I've 2 FortiGate 200D in HA.
For internal policies I set up 2 WAN interfaces used for different company areas.
Area 1 uses WAN1 as default gateway
Area 2 uses WAN2 as default gateway
To do so I configured both wan1 and wan2 as default gateway then with route policy I force Area 1 with WAN1 and Area 2 with WAN2
All works fine
On Area 1 I have a SMTP server with an internal IP (10.1.1.1)
This server has a VIP configuration so from outside it is reachable with IP 1.1.1.1 and also is has a NAT configuration so it communicates with outside with natted IP 1.1.1.1
On Area 2 I have a SMTP server with an internal IP (10.2.2.2)
This server has a VIP configuration so from outside it is reachable with IP 2.2.2.2 and also is has a NAT configuration so it communicates with outside with natted IP 2.2.2.2
All works fine
I have problems when server 1 try to send email to server 2 using external IP
It cannot comnunicate from 10.1.1.1 to 2.2.2.2
On log I see error message "Denied by forward policy check"
I attach you network diagram
I think problem is about routing
I check internal connection and policies and server 1 can communicate with server 2 using internal IP (from 10.1.1.1 to 10.2.2.2)
FortiOS version is v5.0,build0318 (GA Patch 12)
Thanks
regards
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Did you create policy from dmz1 to dmz2 where the source is dmz1's internal network and destination is that vip that gives access from internet to dmz2? And also vice versa if needed. You got that "forward policy check" refusal because there isn't any such policy yet. That kind of NAT-hairpinning is not enabled by default by FGT so you have to create a special rule.
Eg in a situation where public wifi users (possibly company's workers with their smartphones) have to get access to the mail server that is located behind the same router and they use the external IP-address / name for that access as if they were in any other outside network.
echo wrote:Did you create policy from dmz1 to dmz2 where the source is dmz1's internal network and destination is that vip that gives access from internet to dmz2? And also vice versa if needed. You got that "forward policy check" refusal because there isn't any such policy yet. That kind of NAT-hairpinning is not enabled by default by FGT so you have to create a special rule.
Eg in a situation where public wifi users (possibly company's workers with their smartphones) have to get access to the mail server that is located behind the same router and they use the external IP-address / name for that access as if they were in any other outside network.
Hi Echo,
I have a policy from DMZ1 to DMZ2 where the source is dmz1's internal network and destinations are:
- DMZ2 host I need to reach via SMTP
- external IP of DMZ2 host I need to reach via SMTP
also I have a rule from any to WAN2 where the source is 0.0.0.0/0 and destination is VIP address. This because I configure VIP address on WAN2 and not on DMZ2 so I cannot insert VIP address in a rule where destination is DMZ2
Let me know
Thanks
Regards
First, when I recall creating policies so that the destination is both the internal address and internal via vip, it won't allow me to do that. You can also try to separate these rules just in case.
The rule that allows from any to wan2 should be, at least in my understanding, from wan2 to dmz2 with networks any to vip. But for the rule that is currently in question, from dmz1 to dmz2, should not be related to that one.
Maybe you need an extra rule from wan1 to wan2 too because of those policy routes.
echo wrote:First, when I recall creating policies so that the destination is both the internal address and internal via vip, it won't allow me to do that. You can also try to separate these rules just in case.
The rule that allows from any to wan2 should be, at least in my understanding, from wan2 to dmz2 with networks any to vip. But for the rule that is currently in question, from dmz1 to dmz2, should not be related to that one.
Maybe you need an extra rule from wan1 to wan2 too because of those policy routes.
Yes... sorry.
I did a mistake unswering you
Those are my rules:
- From WAN2 (any) to DMZ2 (VIP)
- From DMZ (DMZ net) to WAN2 (wan2 net) (tried enabling NAT and also disabling NAT)
- From DMZ (DMZ net) to DMZ2 (DMZ2 host)
- From DMZ (DMZ net) to DMZ2 (DMZ2 host - external IP)
Now I create a new rule for make a new test
- From WAN (wan network) to WAN2 (wan2 network)
not works
Try this rule
- From WAN (0.0.0.0/0) to WAN2 (wan2 network)
not works
Where is this rule:
- From DMZ (DMZ net) to DMZ2 (VIP) (without additional NAT)
You mentioned that you tried this so -- you did but it is currently not active / was deleted? I just want to be sure you really tried that because in my cases, that's all that was needed.
There is also an option not to use policy routing. Create an untrust zone, put both interfaces into that, create one-element ippool's for both ISP's and use it in nat in the rules where needed. I can't remember if I have used it somewhere but if you don't need a failover solution then this might be an option to try out.
echo wrote:Where is this rule:
- From DMZ (DMZ net) to DMZ2 (VIP) (without additional NAT)
You mentioned that you tried this so -- you did but it is currently not active / was deleted? I just want to be sure you really tried that because in my cases, that's all that was needed.
There is also an option not to use policy routing. Create an untrust zone, put both interfaces into that, create one-element ippool's for both ISP's and use it in nat in the rules where needed. I can't remember if I have used it somewhere but if you don't need a failover solution then this might be an option to try out.
This rule (without NAT) is still active
I also have this policy routes in this order:
- FROM DMZ2 (DMZ2 net) to DMZ net force traffic to Outgoing interface DMZ (no gateway address set)
- FROM DMZ (DMZ net) to DMZ2 net force traffic to Outgoing interface DMZ2 (no gateway address set)
- FROM DMZ (DMZ net) to any force traffic to Outgoing interface WAN (gateway set)
- FROM DMZ2 (DMZ2 net) to any force traffic to Outgoing interface WAN2 (gateway set)
(I have other rules but they are not from or to those networks)
I have almost the same issue. I have got fortigate 200D model, and i build on it a simple configuration. wan1 is connected to an isp and wan2 is connected to another isp. wan1 is connected internally to a servers that control the domain and mail server and web server, and VIPs is configured through wan1 port, and wan2 is connected internally to another server that serve anther hosts through policy route on the fortigate. everything is giong to be ok and access to the internet except one thing, hosts that connected to wan2 cant access to the mail site or the web site hosted through wan1. I create policies on the firewall wan2-->wan1 but it doesnt work. anybody can give me a solution?
By now I have another idea why such traffic is blocked: if policy routes route traffic out then to reach one internal network from another, there has to be an additional policy route preceding the "default route" one: from dmz1 to dmz2 directly, and vice versa too if needed. In GUI you have to select "Stop policy routing" for these policy routes, and it looks later in the list like the gateway is 0.0.0.0. It is needed because Fortinet doesn't check if the traffic to external IP is allowed, it rather checks the internal NATed address, dmz in this case.
Of course, if there are certain all-all rules (policies), then for any other traffic between two internal dmz networks to be prevented, the all-all rules have to be reconfigured (remove all) or alternatively, a deny rule has to be added on top of all other rules.
I recently had to go through all this and that's what I did.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1714 | |
1093 | |
752 | |
447 | |
232 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.