Fortigate Port Forwarding Configuration

0 views
Skip to first unread message

Marsilius Boa

unread,
Aug 3, 2024, 4:35:34 PM8/3/24
to chopilbestchil

This example describes how to configure port forwarding to allow access to an internal Windows server PC with the Remote access protocol which uses the default port of 3389.

To add a virtual IP that forwards RDP packets.

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.

I am not going to lie to you. Port forwarding on V7 is pretty much the same as V6 and if I remember rightly that was the same as V5 but the internet is a hungry beast crying out for content. We need to feed the best lest we feel is wrath.

Now in the next section, we want 'NAT' on as we are nat'ing this traffic, but you can leave the rest as the default. Here you can also apply some of the advance features of the fortigate such as AV and IPS. I am not going to cover that in this guide.

that will show you some useful information about what traffic has passed on that rule. If you have tried to test it and this has a hit count of zero, the chances are the firewall configuration is incorrect.

your right eric, i need to do a VIP for every port i want forwarded. if i use our externa IP and dont check port forwarding, it assumes that i want everything going to one location and this precludes using that external IP for anything else.

This topic shows how to use virtual IPs to configure port forwarding on a FortiGate unit. This example has one public external IP address. We map TCP ports 8080, 8081, and 8082 to different internal WebServers' TCP port 80. This allows remote connections to communicate with a server behind the firewall.

What has me confused is the Comcast modem apparently has two IP addresses. The WAN2 interface for it in the Fortigate router is set to 10.1.10.10. However, all of our port forwarding settings are set to an external IP address of 10.1.10.50.

Configuring port forwarding on a 60B is a several step process. First you need to create a Virtual IP for the interface (WAN2) and IP (I assume 10.1.10.10) you want to forward. Then you have to add a firewall rule allowing traffic from the virtual IP to the internal interface. Can you confirm you've already done both of these?

Also, you mention that your static IP (with Comcast) remained the same. If this is the IP of the modem, I'd expect it to be an external IP, ie not in the 10.xx subnet. Yet the WAN2 interface of your Fortigate has a 10.xx address. This suggests you've got a double-NAT setup.

It really sounds like my guess at the double-NAT scenario is correct. The DSL modem connected to WAN1 is getting the external IP address, and is assigning a 10.1.10.xx address to the Fortigate's WAN1 interface via DHCP. If the old modem definitely didn't have port forwarding then it was probably in bridge mode.

I've got a Fortigate 90D (5.4 Build 1011 in interface mode and doing NAT) with two wan connections. One is fibre (wan1) with a small range of public IPs and the other is an ADSL/pppoe backup connection (wan2). I've setup failover between the two wan ports and it works great. Wan2 is configured as a pppoe port with the ADSL router in bridge mode.

On the primary interface (wan1) I have a few public IPs that I forward to various internal servers via VIPs and port forwarding. I want to have a similar setup for when the link fails to the adsl connection (which has one dynamic IP).

I just bought and put a Fortigate 60e in place with the most current firmware (6.2.2, build 1010GA). I am getting stuck trying to get a port forward solution working for external access to a plex server inside the Fortigate which is only leading me to banging my head against the desk. While I have been doing plenty of google searching and looking at the Fortinet cookbooks online which are great resources. I am wondering if anyone is willing to assist with breaking it down in layman's terms on how to set up the port forwarding.

And while you do that, you notice why you might need port forwarding. SSL-VPN or IPsec VPN towards your FGT will send traffic to your WAN address as well - which will be forwarded completely to your internal server if you don't port-forward.

Correct me if I'm wrong but I remember reading somewhere that by filtering out unneeded packets at the VIP level (or IPv4 Access Control List) rather than relying solely on the IPv4 Policy's service filter that the switch controller's packet filter is saving the FortiGate from wasting unnecessary CPU cycles filtering it out during policy inspection.

It's been now 3 months that I started to find a VoIP solution for our company. I was totally unaware how it worked with VoIP configuration and now I have some ide and came to conclusion on how it works and I would like to ask you one thing.

When I wanted to do for other IP phones by mapping another private IP address to the same Public IP address by opening the same SIP and RTP ports it got rejected. You have to use another public IP address and that is not practical.

Hello @R0g22

Thank you for the reply. The firewall will handle the NAT, in there will be also the policy and the VIP port forwarding.
I didn't understand this part "You would only NAT the CME DNS facing IP to your public IP". Can you bring an example? or link for configuration example?

Thank you.

3. Every user will have one phone on our network. On eBay, a lot of routers that is included the license FL-CME-SRST-25= which will cover 25 users and we will not be more than 10 users.

We removed my HTTP and HTTPS port forwarding VIPS and tried generating a certificate again. It still used a tls-alpn-01 challenge, which passed once the VIPS were removed and the FortiGate was able to bind to port 443. The TAC engineer and I looked over the configuration together, and we could not find an option that sets the ACME challenge type.

The only change I did just before I tried to generate a new certificate was enabling SSL-VPN, so I'm wondering if that implicitly changed the ACME challenge type somehow. I tried disabling the VPN, but that did not change anything. However, I have noticed that enabling the SSL-VPN even just once makes many other changes, some of which I cannot figure out how to undo, like deleting the VPN interface.

No, I set that one up in a lab just to mimic your setup.
[which was much more entailed than yours, but it still worked]
[had to cross firewalls to get to the nginx proxy, which then had to cross several firewalls to get to the lab unit]

I have VIPs configured to forward internet traffic to HTTP and HTTPS to a NGINX webserver. NGINX is configured to pass ACME HTTP challenges to the FortiGate when a specific hostname is used. This allowed me to use to host multiple websites on the server behind HTTP and HTTPS VIPs, while still allowing the FortiGate to respond to ACME http-01 challenges.

However, once SSL-VPN is enabled the FortiGate uses a tls-alpn-01 ACME challenge, which cannot be proxied via an XGINX reverse proxy. This persists even after the SSL VPN is disabled in the web UI or set to a custom port.

After I undid the setting changes made by enabling the SSL VPN in the web UI by running the following commands, the ACME challenge type flipped back to http-01, and I could obtain a new certificate as expected.

Even though the ACME interface is "internal" (and should not conflict with SSL-VPN), the (external) "wan1", being used by SSL-VPN, interface can't be used for both SSL-VPN and VIPs [on conflicting port(s)].

I have a problem that I need help with. I am using a Fortigate 30e firewall and a log server on a virtual machine with ELK stack and Logstash installed. The goal is to send logs from the Fortigate 30e to the log server's Logstash, and from there to Elasticsearch and then visualize them in Kibana.

I have configured the port 5144/udp and the log server's IP (Logstash's IP) from the Fortigate management panel. On the Ubuntu side, traffic has been allowed through the firewall. The port has been checked and is free to use.

The problem is that no logs are coming through to the log server or appearing in the log files /var/log/logstash-plain.log or /var/log/syslog. I have connected the WAN network from the internet cable > to the firewall > from the firewall to the switch > from the switch to a laptop that contains VMware and the log server virtual machine.

This seems like a network issue, if Logstash is listening on the correct port and IP and you still do not get any logs, you need to check if everything is ok in the network, there is not much else to do in Logstash side.

You will need to enable port forwarding via the network editor (I think that's what it's called) otherwise the NAT translation will not forward the incoming packets to the VM. NAT allows many devices to share the same egress IP and so the port forwarding rule helps the NAT determine which inside host should receive the traffic.

Port forwarding is a popular feature many networks use to allow access to your servers inside your network over the public internet. It is used primarily for the webservers, where you want to expose ports 80 and 443 to the public. However, it is used by many other applications as well.

There is some risk regarding the port forwarding configuration on the FortiGate firewall, just like any other firewall. First of all, You must know what you are doing; otherwise, you may put your firewall to risk of an attack. Port forwarding the webserver is okay on ports 443 and 80. However, if you want to access a service using the management protocol such as SSH, RDP, it is always better to use SSL VPN or create an IPsec tunnel if possible. So traffic will be encrypted through a tunnel, and none of the traffic is traversing over the plain internet.

c80f0f1006
Reply all
Reply to author
Forward
0 new messages