DMZ to LAN rule kills internet traffic on NAT'd host

[dcgnetsec]

Running latest build of 7.2 on a 200E

Have a web server in the DMZ that needs to communicate with an internal LAN box solely for https traffic

I have several boxes in similar config, none with issues.  This is perhaps the first new rule I've had to make since upgrading to 7.2, and wonder if that's the issue

As soon as the rule is made, internet traffic on the internal box is killed.  It can get anywhere internally.  If I run a non stop ping to an external address and disable the firewall policy, internet access is restored.  

I'm at a complete loss and since the firewall is in production 24x7 rebooting is something that will have to wait

Anyone seen this or have an idea?  

When the policy is active and I run a trace route the traffic dies at the firewall, i have no idea what its trying to do internally to cause this issue.  A rule allowing https traffic from one host to another shouldn't be killing its ability to get to the internet

[dcgnetsec]

the intent is to let DCGWEB access GENESIS via port 443, that's it

The IP of the DMZ is 192.168.1.xxx/24, pretty standard stuff here

[Toshi_Esumi]

You're probably misunderstanding what VIP/DNAT does and when it's needed. If the device with 10.70.1.43 is connected to Country LAN(port1), which has like 10.70.1.x/24, there is no NAT/address translation involved.

VIP/DNAT is necessary when the destination/server's local IP is behind a NAT, like a local web-server accessed over the internet, to forward FROM the internet-facing interface TO the internal port like DMZ.

Your policy is on the opposite direction.

Toshi 

[dcgnetsec]

Yes, my policy is allowing a server in the DMZ to access a server on the LAN.  We have multiple policies doing the same thing, this is the only one that isn't working.  The DMZ has no direct access to the LAN, so there has to be an address translation.  I have 8 other policies working perfectly set up just like this one.  The only thing I can think of is this is a bug since we upgraded to fortiOS 7.2.8.  I think this is the first new policy i've created since we updated.  

[Toshi_Esumi]

What is the IP on port1? And are you saying there is no route for10.70.1.0/24 or a super net on the FGT?

Toshi

[dcgnetsec]

And just to re-iterate - the problem when this policy is enabled is the destination server loses its ability to get to the internet, which should have NOTHING to do with this policy

[dherard]

It's probably the VIP you created. First try to make the policy without the VIP, using only the nat, or second option, restrict the port in the VIP with the port filter so that it does not apply to all ports. and select the especific interface for the inbound traffic, no leave in "any". if you cann not change that interface now, delete the VIP and create again but this time select the propper incomming interface on the VIP.

the more specific the configuration. It prevents other traffic from being affected by matching with general rules or objects.

[Ade_23]

Hello dcgnetsec,

You are very likely hitting the behavior described in the article below.

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Outbound-Traffic-uses-VIP-IP-as-SNAT-IP/ta...

The behavior of the sNAT changes if DNAT is set up with no port forwarding as can be seen on this forum post: https://community.fortinet.com/t5/Support-Forum/VIP-DNAT-effect-on-SNAT-behavior/td-p/249901

[Ade_23]

Set up an ip pool for that internal box using the wan interface IP and see if it works