HTTPS Forwarding not working correctly

[m84_2019]

Hi all,

Running v6.2 firmware and not able to perform a simple port forward to an HTTPS server internally, something odd in the Fortinet logic or is it a known issue?

Trying to access an internal HTTPS server from outside, I've setup a NAT (Virtual IP) for the external IP, internal IP of the web server and using port 445 on the outside and 443 inside.  Added the corresponding IPv4 policy to allow HTTPS traffic through.

When browsing the external IP on https://x.x.x.x:445 i'm receiving the Fortigate login page rather than the expected internal web server. The NAT doesn't appear to be working as it should, what's wrong with the above config?

[emnoc]

Trying to access an internal HTTPS server from outside, I've setup a NAT (Virtual IP) for the external IP, internal IP of the web server and using port 445 on the outside and 443 inside.  Added the corresponding IPv4 policy to allow HTTPS traffic through.

and

When browsing the external IP on https://x.x.x.x:445 

We would have to see your DNAT VIP and FWpolicy, Every thing else mention and about service ports should not be applicable here not anything else stated unless you change the admin.port of  the firewall to 445

Fwiw; tcp.port 445 is NOT an admin-port for any Fortigate. You can quickly determine this by looking at your config sys global and check if you have SET tcp.port 445 for admin. if you have than Dave and others already gave you the reason and the fix.

Ken Felix

[m84_2019]

I'm well aware that 445 is not used by Fortigate hence the reason to select it. It is however used internally on 443 and I suspect it's not able to NAT correctly internally to a different IP when using 443.

David provided a workaround, this is not a fix.

[emnoc]

No your still confused, Dave provide you the fix & not a work around. You are not listening to the wise information given to you.

You need to show you config and determine if you admin port is 445. It seems like it is. As far as NAT the DNAT vip does that automatically so no need for nat  in the fwpolicy.

Ken Felix

[Grave_Rose]

Hey m84_2019 Just had a thought... Do you have any NAT applied in the firewall rule for you inbound traffic? If so, disable NAT and it should work. Sean (Gr@ve_Rose)

[m84_2019]

Let me spell out the difference for you.

Workaround: Changing internal web server port to allow access remotely OR changing SSLVPN/Admin port on Fortigate

Fix: Fortigate allows port 445 (any free external port) externally on it's own IP to an internal web server IP on 443 (HTTPS).

Rather than become obnoxious, read the facts in my post. Admin port is not running on 445.

[m84_2019]

@Grave_Rose.  Yes had already tried that for the rule related to that traffic.  

[Grave_Rose]

Did you still get the login page when you disabled NAT? Is it still set to disabled? Make sure it is disabled for the next test. Run a PCap on the server interface: diag sniffer packet port1 'host 10.20.30.40 and port 443' 6 10 Replace 10.20.30.40 with the internal IP of your webserver and port1 with the proper interface. Do you see the SYN packet go to your webserver? If so, do you see the SYN/ACK reply? Is the destination port 443 and the protocol 6? If you can post the PCap output, we can look at it as well. Sean (Gr@ve_Rose)

[Grave_Rose]

Oh, one other thing to check... When you set up the VIP, did you specify that it was PAT and not NAT? On mobile right now so I can't check but I believe the option is just called "Port Forwarding" in the VIP object.

*Edit

So I'm back in front of a box and the clue to this was when you said "it's own IP" which meant that you're doing Static PAT and not Static NAT as I (as well as others probably) assumed. This is why it seemed so strange, at least to me. :) I've got the same thing configured at home with my 'Gate but for remote syslog. I was going to attach both screenshots but apparently I can only attach one file so I've added a screenshot of my VIP object. Just use this object in your policy (make sure NAT is disabled) and you should be good to go. Set the "External Services Port" to 445 and the "Map to Port" as 443. Bingo-bango-bongo you're all set. Hope this helps.

Sean (Gr@ve_Rose)

[m84_2019]

Yes this was already done in the original post.

[Grave_Rose]

Hrm... Okay. Without your config, I've got one last idea. Run the following commands. Replace 1.2.3.4 with an external host that you can test with which you will only use for this test - We don't want to capture any traffic which isn't destined for your public IP address on TCP/445. Make sure you have your SSH session logging output or have a large enough scroll-back buffer since this will generate a lot of information:

diagnose debug disable diagnose debug flow trace stop diagnose debug flow filter clear diagnose debug reset diagnose debug flow show function-name enable diagnose debug flow show iprope enable diagnose debug flow filter addr 1.2.3.4 diagnose debug flow trace start 5 diagnose debug enable

With this running, connect to hxxps://y.y.y.y:445 from 1.2.3.4 and it should load up the login page as it has been already. You should have a lot of information in the deubgs on your SSH session. Stop the debug with:

diagnose debug disable

If you can, post the output of that to the thread and we can see what's happening on the firewall from an internal processing view.

Sean (Gr@ve_Rose)