u/Roversword

Dear all

I am trying to use the (yes, limited) ACME client on Fortigate to get a TLS cert for a specific domain.

Unfortunately, tls-alpn-01 doesn't work (see below) as tcp/443 is already in use and http-01 isn't kicking in. And I am wondering why.

Running FortiOS 7.4.12 on a 200F active/passive cluster.

Configuration:

• The FQDN is sub.sub.domain.com and resolves on public IP B.
• Public IP B is configured as secondary IP on the WAN interface of the Fortigate.
• The secondary IP has only PING activated, no other administrative access
• The public IP A (same subnet) is the primary IP on the WAN interface
• Public IP A has https as administrative access (trusted hosts and local-in-policies, and not running on tcp/443)
• Both tcp/443 and tcp/80 are not available for public IP A
• tcp/80 is available for public IP B, but tcp/443 is not (IPSec Dialup is listening to it).

Problem:

• According to the acme logs, fortigate tries to get the cert chain and fails - using tls-alpn-01, but never http-01.
• The IP used according to logs is the correct one (public IP B).
• According to the documentation (https://docs.fortinet.com/document/fortigate/7.4.12/administration-guide/822087), http-01 should be used, at least at some point.

Do I really need to use another port for IPsec DialUp over TCP when I want to use ACME? Anyone ever managed to get it running using http-01 instead of tls-alpn-01?

(Using acme.sh and then API might be an option later on, but that is still in discussion and might never be implemented)

Thanks a lot

Hi all

I am using FortiClient VPN-Only 7.4.3 build 4726.

Have one site with a ipsec dialup over UDP/500 and one ipsec dialup over TCP/443 (same public IP, no other ipsec tunnels).
Configured localid's.
Using SAML Logins - both connections work like a charm with said FCT.

Configured the same setup on another location - two dialups, one over UDP and one over TCP (same public IP, no other ipsec tunnels)

But on the second location TCP doesn't work - UDP does.
When checking IKE debug when trying to connect via TCP/443 it gives me "one liner" that the tcp connection is being established (showing the correct client and server address) and then destroyed again - without IKE handshake or any other useful information (like with IKE over UDP). Sniffer says they are talking (SYN, ACK, etc.). There is no indication that the client can't talk to the

I checked the configuration several times (phase1 especially). Short of reinstalling the FCT I am under the impression I tried it all. Even deleted the TCP profile and configured it again. Rebooted WIndows and all that.

Unfortunately, the FortiClientEMS Client on another machine seems to be able to connect to the affected site via IPSec over TCP - which makes me think:

Is it really that much of a hit and miss with the FortiClient VPN-Only whether or not a IPSec over TCP tunnel comes up or am I just that unlucky and missing something?

Dear all

One of our Fortigates (100F, v7.4.11) and one of our customers Fortigates (100F, v7.4.11) have an IPSec tunnel (site to site) established.

The tunnel works, there are no issues with work/user traffic (so far). However, there is the following issue:

• When DPD on this tunnel is "disabled", there are no errors on either side in the event logs for that VPN. However, if there is a HA event (switching nodes), the tunnel takes ages (>20 minutes) to come up again on the newly active node.
• When DPD on this tunnel is "on demand", then the HA event is smooth (the IPSec tunnel comes up after switching active node rather quickly), however, during off hours with no user traffic, the customer side has DPD errors and both fortigates see "tunnel-down" and "tunnel-up" messages in the VPN events of said tunnel. The tunnel goes down for either a short while or a few minutes - every 5 to 10 minutes (not really regular intervalls).

So far, the DPD errors happen only during off hours and have NOT affected work. The users can work without issues and the DPD errors (and tunnel-down/up) vanish once regular traffic is going over the tunnel.

We decided that the DPD errors are the lesser evil and start debugging with DPD enabled (trying to catch IKE debugs on both sides to hand over to Fortinet).

I inherited the fortigate on our side, so I am not familiar with its history - I only know that the IPSec tunnels terminate on a loopback interface (which is odd to me, see my post history) rather than a "normal" interface with the public IP on it.

The customer (as well as us) have several other IPSec tunnels (two dozens or slightly more) on the same fortigates and the other tunnels appear to be OK (haven't checked all of them just yet, logwise). So far it appears only that particular tunnel has an issue.

If someone of you should have happened to come across the same or a similar issue and could point me in a direction to investigate - I'd be very thankful.

Dear all

Its Tuesday, 07th of July, about 14:00 CEST.

Anyone else getting an error (504 Gateway Timeout) when trying to reach FortiIdentity Cloud in their FortiPortal Cloud account?

Also, some services that use FortiToken Mobile via FortiIdentity don't work ("an error occured").

The status page (https://status.fortistatus.com/guest-portal/fortitrustid/incident/overview) says, eveything is OK.

EDIT:
The status page for that is more likely - https://status.fortistatus.com/guest-portal/fortitoken/incident/overview

Cheers

EDIT 2:
At around 15:45 CEST on the 7th of Juli - things seemed to have started working again. Logins via FortiToken Mobile (using FortiIdentity Cloud) worked again.

Dear all

I am somewhat at a loss as I have no prior experience or knowhow with this.

Current configuration:

Smaller Fortigates (60F, 80F, 90G) with one single physical port connected to (third party) switches and on that pyhsical interface we have currently three VLAN interfaces configured. FGT does DHCP server for those VLANs.

New requirement:

There should be a new VLAN where sensors (Arctic Wolf) should be placed and the reuquirements are that those shall work with port mirorring (SPAN).
I never done that before, so I am reading the documentations now - which tell me about hardware and software switches.

Challenge:

We never really deploy hardware or software switches, but only single (or aggregated) phyiscal ports with VLANs configured on them that are "transported" to the downstream switches.

So far the documentation don't mention how I can configure SPAN in this context of VLAN interfaces. Breaking up the phyiscal port into a hardware or software switch and then add VLANs there (if even possible) sounds not right to me (but I couldn't tell, as I have no prior knowledge).

Question:

Assuming that I'd need to get the traffic from all other vlans to that fourth vlan with the sensor, does someone have experience how to do that (SPAN) when using a (single or aggregated) physical interface with VLAN interfaces in it?

Thanks a lot

Hi all

I have the following accprofile which my (personalised) user is working with.

Unsurprisingly, I can make backups. But the "Restore" option is not available (under my name in the upper right corner).

According to https://docs.fortinet.com/document/fortigate/7.4.11/administration-guide/702257 I don't see any specific information that hints for additional rights.

However, I am quite sure I am missing something.

config system accprofile
    edit "admin_rw"
        set comments "admin profile custom"
        set secfabgrp read-write
        set ftviewgrp read-write
        set authgrp read-write
        set sysgrp read-write
        set netgrp read-write
        set loggrp read-write
        set fwgrp read-write
        set vpngrp read-write
        set utmgrp read-write
        set wifi read-write
        set cli-diagnose enable
        set cli-get enable
        set cli-show enable
        set cli-exec enable
        set cli-config enable
    next
end

Does someone have an info (link to official documentation) that says that only a super_admin can do restores?

Thanks a lot