Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
m84_2019
New Contributor

HTTPS Forwarding not working correctly

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?

20 REPLIES 20
emnoc
Esteemed Contributor III

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

 

 

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
m84_2019
New Contributor

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
Esteemed Contributor III

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

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
Grave_Rose
New Contributor III

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)
Site: https://tcpdump101.com Twitter: https://twitter.com/Grave_Rose Reddit: https://reddit.com/r/tcpdump101 Discord: https://discordapp.com/invite/2MZCqn6
m84_2019
New Contributor

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
New Contributor III

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)
Site: https://tcpdump101.com Twitter: https://twitter.com/Grave_Rose Reddit: https://reddit.com/r/tcpdump101 Discord: https://discordapp.com/invite/2MZCqn6
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)

Site: https://tcpdump101.com Twitter: https://twitter.com/Grave_Rose Reddit: https://reddit.com/r/tcpdump101 Discord: https://discordapp.com/invite/2MZCqn6
m84_2019

Yes this was already done in the original post.

Grave_Rose
New Contributor III

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)

Site: https://tcpdump101.com Twitter: https://twitter.com/Grave_Rose Reddit: https://reddit.com/r/tcpdump101 Discord: https://discordapp.com/invite/2MZCqn6
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors