inbound HTTP & HTTPS

DNAT Rule: Any > HTTP & HTTPS > Going: WAN address > Change Destination > InternalServer and Service Leave Blank. 
Check Automatic Firewall Rule

I have changed the DNAT to what you suggested as in the screenshot below i'm no longer getting the drop in the firewall log but the connection is still being refused and isnt making it to the server. the screenshot below is how the HTTPS is setup and the HTTP rule is the same. 

Hi Chris,

can you try logging your NAT-rule for further investigation?

(click "Advanced" in the "Edit NAT rule" tab and check "Log initial packets")

After that you can try to reach your WebServer through https and see if your connection is passing the NAT or not.

(Maybe also provide the logs after testing)

Regards,

Ole

Hi Chris,

can you try logging your NAT-rule for further investigation?

(click "Advanced" in the "Edit NAT rule" tab and check "Log initial packets")

After that you can try to reach your WebServer through https and see if your connection is passing the NAT or not.

(Maybe also provide the logs after testing)

Regards,

Ole

the logs are showing the rule being accepted and passed then a green line saying its being forwarded but its not making it to the server i have tried 3 different servers and all are not receiving the request on either HTTP or HTTPS i am about to do some more investigation using wireshark and i will post the utm firewall logs 

this is a screen shot of the logs 

In the grey line should be the wan ip. Are you sure you dont have duplicated DNAT rules?

it looks like i have found the issue, i noticed that the default gateway on the servers was set to another router on the network once i changed it to the ip of the utm it started working

My setup is isp's router using 192.168.0.0/24 addresses > utm has 192.168.0.0/24 address on wan port and 192.168.1.0/24 on the lan port until > internal network so to the utm the wan address is 192.168.0.2 for now.  

The solution has to be the gateway.

The traffic was forwarded from an external IP (unknown in the internal network) to your server.

The server then had to figure out a route to this external IP.

That way he had to go to his default gateway that did not know what to do with the packet.

Now it makes sense :)

You might wan to keep this link to the Rulz handy and refer to it when you have problems.  See #3.1 relative to this issue.  I also would have mentioned #3 as the cause of this.  Had I seen your first post above before now, I would have suggested doing #1.

Cheers - Bob