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?
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
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.
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
Site: https://tcpdump101.com
Twitter: https://twitter.com/Grave_Rose
Reddit: https://reddit.com/r/tcpdump101
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.
@Grave_Rose. Yes had already tried that for the rule related to that traffic.
Site: https://tcpdump101.com
Twitter: https://twitter.com/Grave_Rose
Reddit: https://reddit.com/r/tcpdump101
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
Yes this was already done in the original post.
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
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1702 | |
1092 | |
752 | |
446 | |
228 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.