Skip to main content
Bigio12
New Member
March 17, 2016
Question

Internal routing from WAN1 to WAN2

  • March 17, 2016
  • 8 replies
  • 14256 views

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

 

 

 

 

8 replies

echo
Explorer II
April 1, 2016

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.

Bigio12
Bigio12Author
New Member
April 4, 2016

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

echo
Explorer II
April 4, 2016

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.

Thought Leadership. Security Summit. Thursday, November 12th, PGA National Resort, Palm Beach Gardens, FL.
Thought Leadership. Security Summit. Thursday, October 8th. Disney's Grand Californian Hotel & SPA, Anaheim, CA.
Security Operations Summit: Modernize SecOps. Operate AI-Native.AMER: November 4 | 9:00 AM PST. India and SAARC: November 5 | 10:00 AM IST. EMEA: November 5 | 10:30 AM CET. APAC: November 5 | 11:00 AM SGT