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

[amrit]

Could you please provide the following debugs from the firewall when rule is enabled

di de flow filter addr 8.8.8.8

di de flow filter prot 1

di de flow show function-name enable

di de flow trace start 50

di de en

run the ping to 8.8.8.8 from a test machine 

provide 

get router info routing-table details

make sure the rule is correct order 

Also provide the output from the policy

config firewall policy

edit <new rule id>
show

end 

end

[dcgnetsec]

Thanks for replying.  I'll have to run some of the debugs later as server in production for the day, but here is the policy

SCFORT200E # config firewall policy

SCFORT200E (policy) # edit 74

SCFORT200E (74) # sho
config firewall policy
edit 74
set status disable
set uuid 410dc4e0-543a-51ef-f646-bbc785bd31c9
set srcintf "port6"
set dstintf "port1"
set action accept
set srcaddr "DMZ DCGWEB"
set dstaddr "DMZ NAT GENESIS"
set schedule "always"
set service "HTTPS"
next
end

SCFORT200E (74) #

Port 6 is our DMZ, Port 1 is LAN

Never seen behavior like this before, and we have multiple rules just like this between other internal and DMZ servers.  Not sure if its just a bug, i've tried using different IP addresses as well with no change.  

[HiralShah]

Hello @dcgnetsec 

Can you please show the address object DMZ DCGWEB and DMZ NAT GENESIS , also please run the debug as provided so we can check if the traffic is using wrong interface when policy is enabled.

[dherard]

As mentioned above, verify the addresses of the indicated source and destination objects, that they are correctly created.
You could also try removing the HTTPS service from the policy and leaving it "ALL" initially to test and confirm if the traffic works that way.
If it works, re-establish the HTTPS service in the policy and try again. There are occasions when it may be necessary to require some other additional protocol to function. If it works with "ALL" you have to verify with debugging or captures if any other protocol or additional port is used for what you want to do to work.

and as additional information, test between "flow and proxy" mode if there is a difference.

Daniel Herard

[Toshi_Esumi]

Please share us the policy in question either CLI or GUI.

Toshi

[dcgnetsec]

Thanks - here's more info - believe the order of these snips is the address object for the source, then the destination, and finally the firewall policy, all from the gui

SOURCEDESTINATIONPOLICY

[dherard]

I don't understand why you use a VIP instead of a normal nat. but in case you want to use the VIP. specify HTTPS port 443 on that VIP to see if it doesn't conflict with having the port range open on the VIP. 

[dcgnetsec]

if there's a better way to set it up i'm all ears, i am not a fortigate expert by any means, our ISP set most of this up and we've just followed the blueprint they created over the years

[Toshi_Esumi]

What is your intention with the VIP? To let the "DMZ DCGWEB" accessible from outside/internet?
And what is the interface IP/subnet configured on DMZ(port6)?

Toshi