Hi all,
I'm having some issues with port forwarding. I'm running fortinet v7.0.5. I have a Windows Server running Tomcat 8.5 which is running my website. I've succesfully managed to import my SSL certificates into tomcat (on my windows server, going into https://localhost:8443/ i can see the certificate (shows as error, because the domain doesnt match, but all of the information about the CA etc is there, so its working okay). But when i go through https://domain.com:8443/ i get Unable to connect - An error occurred during a connection to domain.com. If i go to https://domain.com (without the port) i get The connection has timed out - An error occurred during a connection to
Now i have a public ip on my fortinet wan, which is used mostly just for ssl-vpn to remote into my workspace when im at home.
I've added 2 VIP's one for port 80 and one for port 8443(https) - port 8443 seems to get hits, but cant load, and port 8443 reports as closed when using tools to check for open ports.
I've attached some screenshots of my vip's and firewall policies (im guessing the issue might be within the firewall rules, as im a complete newbie at this).
I've attached 2 screenshots - 1 of the vip settings, and other of the firewall rule. I would greatly appreciate if someone more experienced could point be to the right direction, i've fought this for 3 days without any luck.
If you require any more information, please do say and i will provide them!
Many thanks!
screenshots:
Solved! Go to Solution.
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.
Created on 03-25-2024 04:17 AM Edited on 03-25-2024 04:19 AM
Look at this single flow (which repeats throughout the capture):
2024-03-25 08:23:57.044783 wan in PUBLIC_IP.114.53929 -> PUBLIC_IP.110.8443: syn 800780839
2024-03-25 08:23:57.044848 vlan99 out 10.1.99.30.53929 -> 10.1.2.63.8443: syn 800780839
2024-03-25 08:23:57.044853 lan out 10.1.99.30.53929 -> 10.1.2.63.8443: syn 800780839
2024-03-25 08:23:57.045227 vlan99 in 10.1.2.63.8443 -> 10.1.99.30.53929: rst 0 ack 800780840
2024-03-25 08:23:57.045249 wan out PUBLIC_IP.110.8443 -> PUBLIC_IP.114.53929: rst 0 ack 800780840
Or in short:
-> SYN
<- RST
This is very much an explicit rejection of the attempt to communicate by 10.1.2.63 (or whoever else may be acting on its behalf, such as another firewall, on the path, on the server, etc.).
From the FortiGate's point of view, the important thing to notice is that the SYN packet goes through, i.e. the packet/session was allowed to pass.
At a glance the setup looks OK. Here's a list of semi-random points that may be worth checking:
If all else fails, start with basics and make a packet capture and check the packet flow:
diag sniffer packet any "port 8443" 4 0 a
(CTRL+C when done)
Hi and thanks for your pointers.
Here's a glance at the sniffer command. I've changed most parts of the public ip to PUBLIC_IP leaving .114 and .110 which is the ends of that WAN ip address. Is there something you see that i dont?
Many thanks!
Looks like the sniffer output wasn't attached, can you retry?
Created on 03-25-2024 02:25 AM Edited on 03-25-2024 02:48 AM
Sorry! Here it is (10.1.99.30 is fortinets ip that i access web ui with)
Im also attaching a screenshot of interfaces in use
edit: Might be of some use: i found that if i run the sniffer test against ports 80, 8080 and 8443 the results are all the same. Keep in mind port 80 and 8080 (non-ssl) work fine and display the page normally; port 8443 gives unable to connect error. So to my understanding, if all results within the sniffer for port 80 8080 and 8443 are the same, this shouldnt be fortinet blocking something, correct? Can this be due to network policies and firewall on the windows server itself?
Created on 03-25-2024 04:17 AM Edited on 03-25-2024 04:19 AM
Look at this single flow (which repeats throughout the capture):
2024-03-25 08:23:57.044783 wan in PUBLIC_IP.114.53929 -> PUBLIC_IP.110.8443: syn 800780839
2024-03-25 08:23:57.044848 vlan99 out 10.1.99.30.53929 -> 10.1.2.63.8443: syn 800780839
2024-03-25 08:23:57.044853 lan out 10.1.99.30.53929 -> 10.1.2.63.8443: syn 800780839
2024-03-25 08:23:57.045227 vlan99 in 10.1.2.63.8443 -> 10.1.99.30.53929: rst 0 ack 800780840
2024-03-25 08:23:57.045249 wan out PUBLIC_IP.110.8443 -> PUBLIC_IP.114.53929: rst 0 ack 800780840
Or in short:
-> SYN
<- RST
This is very much an explicit rejection of the attempt to communicate by 10.1.2.63 (or whoever else may be acting on its behalf, such as another firewall, on the path, on the server, etc.).
From the FortiGate's point of view, the important thing to notice is that the SYN packet goes through, i.e. the packet/session was allowed to pass.
Okay, so in my understanding FortiGate allows the connection to go through but then it gets rejected by its next hop, some other instance like the windows server where the packet is destined to go?(for example www -> fortigate(allowed) -> windows server(rejected)
Correct. Something behind the FortiGate is rejecting the connection. It may or may not be the destination server itself, depending on what else is on the path in-between, if anything.
Created on 03-25-2024 05:57 AM Edited on 03-25-2024 05:57 AM
Yes, you are correct. The destination server (windows server) needed inbound/outbound rules added for those ports. Everything is working smoothly now. Many thanks for your assistance in this matter!
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 |
---|---|
1732 | |
1106 | |
752 | |
447 | |
240 |
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.