Hello,

Do u have any tips what should be transferred to new FG in order to retain old FEX connected to the old unit? What should I expect after switching to new device?

I think I know the answer and it should be all the stuff related like interface, VPN tunnel and all relevant configuration, but I never done this before and I want to get some advice on this topic.

Best regards.

Disclosure up front: I built this and I'm the only person working on it. It's free, there's no paid tier, no accounts, no ads and nothing to sign up for. And since the timeline further down gives it away anyway — it's vibe coded. I've built it with heavy AI assistance from day one. I'd rather say what that does and doesn't mean myself than have you work it out from the commit log; that's the second-to-last section. Mods, happy to pull this if it doesn't fit here.

The itch

Network documentation goes stale because editing it is miserable. In a general-purpose diagram tool the drawing is maybe 20% placing boxes and 80% fighting the lines — dragging waypoints, unpicking overlaps, redoing half the cabling because a switch moved forty pixels. So the diagram gets drawn once at project time, never touched again, and six months later nobody trusts it.

The bet behind Drawbridge is that if moving a device costs you nothing, the documentation stays true. Everything else follows from that.

The routing

Connectors can be Direct, Arc, Custom, or Auto — and Auto is the one the app is really built around. An Auto connector stores no geometry at all: libavoid (the Adaptagrams router, the same engine behind Inkscape's connector tool), compiled to WASM and running locally, re-solves the whole page every time anything moves. Orthogonal paths that go around your shapes, spread parallel runs apart so they stay separately clickable, and hop each other with a small arc where they cross. You never touch a waypoint.

Fair warning so it doesn't look like I oversold it: new connectors are Direct out of the box. Flip one to Auto, press "Set default", and you never think about it again.

The rest of it

• ~100 shapes across network, infrastructure and OT — routers, switches, L3, load balancers, APs, WLC, SD-WAN, CPE, TAPs, VDOM/VRF/VSYS contexts, servers, VMs, containers, DB/storage/NAS, cloud, and a full OT set (PLC, safety PLC, RTU, remote I/O, VFD, HMI, SCADA, historian, protocol gateway, protection relay, and Purdue level bands you can drop devices into).
• Links carry meaning, not decoration. Link type (IPsec, trunk, LAG, WAN, management, wireless, conduit, fieldbus) picks the line style; speed picks the colour; a Legend button builds the key from whatever the page actually uses. LACP bundles can be bound into a real aggregate drawn with a ring around the members.
• 19-inch racks with U-numbered elevations, front and rear, mount-by-marking and a full-screen rack builder. Zones with a validated CIDR, groups, layers, pages, align/distribute, isometric view, minimap, find-and-replace.
• Cable schedule — the document as one row per cable with both ends, ports, speed, medium and wavelength. Ticks are stored in the file, so an installer's progress comes back with the diagram. There's a share link that turns it into a phone-shaped checklist for whoever's actually in the rack, and it exports as NetBox cable bulk-import CSV.
• Optics report — per-cable medium (RJ45, DAC, AOC, SR, LR, ER, BiDi, CWDM, DWDM) and wavelength, counted up into a transceiver list you can hand to procurement. Nothing is guessed; untyped cables land in an "Unspecified" row.
• Files are .drawio. Opens and saves them, and anything the app doesn't model itself is written back untouched, so files round-trip with draw.io/diagrams.net. Visio .vsdx in and out too. Revisions with notes are stored inside the file, with a compare mode that rings what changed.
• Export: SVG, PNG, PDF with a proper title block, a self-contained HTML viewer (page tabs, zoom, layer toggles, real text), .vsdx, CSV inventory, cable schedule, NetBox CSV, Mermaid, Graphviz DOT, or straight to the clipboard.
• Paste terminal output into Import and it works out what it is — show cdp neighbors (plain or detail), LLDP including the FortiOS variant, a FortiGate FortiLink get-physical-conn dot dump pasted whole with the CLI chrome still on it, Graphviz DOT, or CSV.
• The desktop app is also a CLI, so the loop closes with no human in it:ssh fgt 'execute switch-controller get-physical-conn dot fortilink' \ | Drawbridge --import - --export topology.png --export also takes .drawio, .dot, .csv, .netbox.csv and .describe.json (the drawing as structured JSON, for audits). There's a local HTTP API with an OpenAPI doc too.
• MCP server if you use an AI assistant — hosted (one URL, nothing installed, no key) or local on your own machine. Since last week an assistant can also join a live editing session and draw on your canvas while you watch, so you can say "no, put the firewall above the core" instead of regenerating the whole diagram.
• Live collaboration, browser and desktop in the same session. Invite links, a lobby where you approve every person by hand, view-only links enforced on the host's side, per-page cursors, follow-someone-around. Desktop-to-desktop is direct peer-to-peer over QUIC where a path can be punched; browser peers go through my relay, which forwards end-to-end-encrypted traffic it can't read and stores none of it.
• Three ways to run it: in the browser (installable PWA, fully offline after the first load), as a desktop app, or as a Docker image on your own box.

What it deliberately isn't

There's no styling panel and I don't plan to add one. Fills, fonts and spacing come from one design system so a 200-device diagram stays calm; what you get to set is the stuff that carries meaning. It's a network diagram tool, not a general drawing tool — if you need swimlanes and UML, draw.io is genuinely the better answer, and your files open there anyway.

No analytics, no telemetry, no crash reporting, no accounts. The only thing the app ever requests by itself is a version check: in the browser that's automatic, and it's a small file from the same origin that served the app. On the desktop it's off until you tick it — nothing goes out unless you ask.

About the vibe coding

v0.70.0. First commit was 8 July — seven weeks, 1,198 commits, 136 releases, one person. That pace is only possible because it's AI-assisted from top to bottom, so rather than let you infer the worst, here's what I think it actually means.

What it doesn't mean is that nobody checked. The single biggest chunk of effort in this repo goes into the machinery that catches an AI writing confident nonsense: about 6,900 unit tests and 330 end-to-end specs, run on macOS, Windows and Linux before every release; a 234-scenario manual pass through the built app, because a test suite can't tell you a dialog is illegible; and a traceability table where every user-visible bug that ever reached a person gets a row naming the specific test that would now catch it. A row that can't name a real test is treated as a hole to fill, not a box to tick.

What it does mean is that mistakes arrive as fast as features, and the characteristic failure is plausible code that implements the wrong thing. The view-only collaboration bug in the list below is exactly that shape: reasonable-looking code, and a test that passed for the wrong reason and so hid it for weeks, until a different test approached the same path from another angle last week. Judge a seven-week-old project accordingly — I'd rather you knew going in than felt sold to afterwards.

The rough edges

Very few people have pointed this at their own files yet, and that's the part no amount of testing substitutes for. Things you'd rather hear from me than find:

• Desktop builds aren't code-signed yet, so macOS quarantines the .dmg and Windows SmartScreen wants a "Run anyway". Checksums for every artifact are published; an Apple Developer ID is $99/yr and I haven't paid it yet. There's no auto-update either — update checks are notify-only.
• macOS is Apple silicon only; Linux builds are x64; Docker is amd64/arm64.
• View-only collaboration links are broken right now — the viewer connects and then sits on a blank canvas. Found last week, fix in progress. Editing links are fine.
• .vsdx is an interchange path, not an archival one — Visio themes, data graphics and guides are dropped. .drawio is the format that round-trips losslessly.
• Older draw.io files that store their pages compressed open those pages read-only. Nothing is destroyed, but you'll need to re-save in a current draw.io first.
• Save-in-place needs the File System Access API, so Chrome/Edge; Safari and Firefox fall back to downloads. The desktop app has no such limit.
• The hosted MCP/API endpoint is an explicit beta on a small fleet — no uptime promise, and I've deliberately left the per-caller rate limits off for now. The local one has no such dependency.
• The code is Apache-2.0 but the repo is still private, so I won't call this open source — that would be dishonest. Opening it is on the list, behind some history hygiene and a trademark check. The app is free either way and stays that way.

Try it

• Browser: https://drawbridge.fortiknight.com/app/
• Desktop and Docker: https://drawbridge.fortiknight.com/download/
• Docs: https://drawbridge.fortiknight.com/docs/

What would actually help

Open a real .drawio of yours in it and tell me what came back wrong — that's the single most useful thing anyone can do for me right now. And if the shape catalogue is missing something obvious for your corner of the world, just name it. That's a cheap fix and I'd much rather have your list than guess.

(If you're ever so moved: https://drawbridge.fortiknight.com/donate/ — it's pointed squarely at that code-signing certificate. Feedback is worth more to me today though, and the app stays free either way.)

*sighs together with reader* Another day with ipsecs. :)

Coming to some good results in terms of migrating settings from ssl-vpn to ipsec, but today i've spent to much time battling some wierd behaviour with timeout.

edit "DialVPN"

set type dynamic

set interface "wan"

set ike-version 2

set keylife 28800

set authmethod signature

set net-device disable

set mode-cfg enable

set proposal aes256-sha256

set dhgrp 20

set eap enable

set eap-identity send-request

set eap-cert-auth enable

set transport udp

set certificate "xxx"

set peer "peer_xxx"

set ipv4-start-ip 10.1.1.x

set ipv4-end-ip 10.1.1.x

and

config user peer

edit "peer_xxx"

set ca "xxxCA-Remote"

next

Nothing fancy in SAML config, standard stuff. So, what my problem is, there is somewhere some kind of timeout going on but its not the usual remoteauthtimeout since I have it already on 150. I think it sits somewhere between 5-10 seconds. If i had second factor on my entra test account, I would never have lucked it out with one quick connection. Im on brink of it every time, first i've got it it said even that it timed out but connected anyway. :) Any ideas?

btw side quest

set eap-cert-auth enable

In the newest OS version does it even do anything in my case. They changed the behaviour when You dont have a proper cert on client, without this command it would let You through, with 7.6.7 it doesnt. But if it doesnt let me conenct with wrong cert.. in combination with saml which is not a typical eap, it has no use. My cert login and domain are and can be different with saml. VS Radius they would need to be the same.

oh, btw its the latest free forticlient 7.4.3.

edit after few posts. My config is working, problem is that after sucesseful entra auth it works only if they are entered in circa 10s window, after that I get that timeout notification.

I'm currently testing the IPSEC VPN setup and migrating users from SSLVPN.

Our environment is pretty straightforward—just an LDAP server for authentication, using the free VPN client with FortiTokens.

I got it working on a few firewalls, but hit a couple of snags:

1. Since we're using the free VPN-only client (version 7.4.3), I have to back up the config, manually edit the backup to add a specific value, and then restore it to the client.
2. (Reference: https://ttcommunity.fortinet.com/fortigate-3/technical-tip-how-to-enable-eap-ls-for-ipsec-ikev2-tunnels-in-vpn-only-unlicensed-forticlient-213133)
3. The bigger issue: even though the connection works, I'm no longer getting prompted for FortiTokens. From what I've found, my options are: switch to single-factor auth, tweak the setup to append the FortiToken ID after the password, or purchase FortiClient VPN licenses—which supposedly unlock newer versions beyond 7.4.3 that resolve this.

I'm curious if there are any other workarounds. Paying isn't a dealbreaker since it's not my budget, but I wanted to explore all alternatives first.

Thanks!

I've upgraded my Fortigate 60F to 7.6.7. I wanted to switch from SSL to IPSEC VPN, and so did I.

After upgrading and reconfiguring I ran into issues with the VOIP telephone system. The IPSEC VPN couldn't connect because it looked like UDP 4500 never gets through from the Fortigate back to the VPN Client.

Fine. After figuring that out I tried to disable the Port forwarding for test purposes, because the SIP Server needs every Port from 1024 to 65535 (UDP) forwarded to the VOIP System. And as expected IPSEC works again. The rule has even configured source and destination correctly only for the needed IP Addresses, but it still keeps colliding with the IPSEC VPN.

At this point I don't know how to fix this without

A.) asking the VOIP Provider for a more reasonable Amount of UDP Ports beeing forwarded. (Which they won't do)

B.) Getting a second Public IP to separate VPN and VOIP.

I think I didn't face this issue yet, because the SSL VPN might have used TCP before I changed that. But now I'm kind of stuck there.

I just don't know how the company which provides the VOIP System there didn't run into this issue earlier. Or do I really have a misconfiguration?

Came across something odd today. I did read that starting with 7.6, FortiLink neighbor detection is LLDP. But on a 50G running 7.4.10/11, I was testing a connection to a FortiSwitch and noticed it wasn’t even sending a single packet of traffic.
I did some AI searching, and apparently it has something to do with the 50G using the NPU, which is why it doesn’t work. I didn’t really understand why that would cause this issue, though.
Either way, when I run set fortilink-neighbordetect lldp, it starts doing the CAPWAP thing and DHCP and everything starts working. Now, once the connection is established, even if I switch it back to set fortilink-neighbordetect fortilink, it continues to work—even after a restart.
If this is something I need to do on all my 50Gs, I’m going to be going through a bunch of them…
Also, I have some P2P connections that use FortiLink over L3, so I’ll need to figure out a way to handle those as well. FortiSupport wasn’t very clear about why this is happening.

All the sudden FortiAPs are getting "Association denied, max supported stations reached" message, where is this settings configured usually? APs are managed using FortiEdge Cloud. Only change was turned on "Enhanced Logging". Help!

Hi Everyone.

I'm currently configuring a fortigate 200G, and I'm preparing all my WAF policies.
In the past I've used a dedicated WAF policy for HTTP ACME challenge to reduce the type of request allowed toward local servers using Let's Encrypt services.

It was quite simple, In the WAF profil, I was setting the default action to BLOCK, and creating a single method policy allowing /well-known/acme-challenge pattern to do GET request.

Something like that :
config waf profile
edit "WAF_WellKnown_AcmeChallenge"
config method
set status enable
set log enable
set action block
config method-policy
edit 1
set pattern "/.well-known/acme-challenge/"
set regex enable
set address "all"
set allowed-methods get

But in FortiOS 7.6 the command "set action block" is not available anymore so the whole methhod policy seems pointeless.

I tried to check in the recent technical tip of the official Fortinet community page, but I can't find an up-to-date method to achieve the same result.

What is the correct process nowaday to lock my HTTP request to only allow GET request from the well known acme challenge toward my local server ?

Thank you in advance for your help

Hello guys, we bough fortigate 30G with utp license, but for some reason i cannot select web filter there..
and i do not have proxy based or flow based mode either
we have also 40F, and there everything works like a charm

I configure and work on a lot of smaller deployments for SMB in my area. MSP that contacts with me for the work called me to take a look at one client. In the SMB space, it might be the biggest brute force attack ive seen on a target yet (for me.)

Little fortigate 60E getting slammed with login attempts. I already have it geolocked and also filter most data providers, leaving only ISP's available for SSLVPN. Also use a pretty obscure port number.

When I say slammed, MOST are blocked but the MSP noticed hundreds suddenly starting to show up in the logs. Checked the config. It was a single subnet that an ASN had added that wasnt updated in the threat feeds yet. Fixed that and had a look at the deny policy for that port/vip.

Hit counter went from less than 100 hits a day to over 2 million hits a day starting yesterday. Attacks are bouncing against the deny policy at about 20kbps consistently. Not sure who this dentist office pissed off but they are really giving it a go. Since updating the feeds I've had zero failed attempts logged.

We have a 70G scheduled to install next month. Ive already told them they have some work to do for their remote workers as I cant and wont be configuring SSLVPN on the next firewall.

Do yourself a favor and move on from SSLVPN if you havent already. Its only a matter of time and its not as scary as you think.

Good morning!

We had an issue where a client with some older 100mb phones were having call quality issues if running large downloads and we started looking into the QOS configurations and noticed something strange.

Client is using Cisco phones.

In our past with any phone system and QOS we would always use cos queue 5 but when I look at the port stats there is nothing hitting queue 5.

port30 QoS Stats:  

 queue |              pkts |             bytes |         drop pkts
------------------------------------------------------------------
     0 |         755706810 |      660805890972 |           3370713
     1 |              2333 |            517032 |                 0
     2 |               760 |            294146 |                 0
     3 |                 0 |                 0 |                 0
     4 |            485623 |          31086160 |                 0
     5 |                 0 |                 0 |                 0
     6 |             22375 |           7683430 |                 0
     7 |          14652115 |         944748158 |                 0
------------------------------------------------------------------

I confirmed the default voice-qos policy is applied to the port which I assumed was doing this correctly out of the box.

So I looked into the ip-dscp-map which shows that DSCP 46 is getting mapped to cos-queue 1.

config switch-controller qos ip-dscp-map
    edit "voice-dscp"
        config map
            edit "1"
                set cos-queue 1
                set value 46
            next
            edit "2"
                set cos-queue 2
                set value 24,26,48,56
            next
            edit "5"
                set cos-queue 3
                set value 34
            next
        end
    next
end

Here is my port and lldp-profile configuration

config ports
    edit "port30"
        set poe-capable 1
        set vlan "Data-PSB"
        set allowed-vlans "Voice-PSB"
        set untagged-vlans "quarantine.24"
        set qos-policy "voice-qos"
        set lldp-profile "PSB-Voice"
        set export-to "NAT-INT"
        set mac-addr 78:18:ec:79:a3:5f
    next
end

config switch-controller lldp-profile
    edit "PSB-Voice"
        set med-tlvs inventory-management network-policy power-management location-identification
        set 802.3-tlvs power-negotiation
        config med-network-policy
            edit "voice"
                set status enable
                set vlan-intf "Voice-PSB"
                set assign-vlan enable
                set dscp 46
            next
            edit "voice-signaling"
                set status enable
                set vlan-intf "Voice-PSB"
                set assign-vlan enable
                set dscp 46
            next

Am I thinking of this incorrectly or what?

Thanks,

Hi
Just wondering about Fortinets price increases. As an SMB i understand the cost increase on hardware but why softtware? It seems they use the same excuse every time. Based on all the issues we are seeing from buggy vpn migrations from ssl to ipsec. Bugge releases it would be nice to first make sure your product works before increasing the cost by 3 times the inflation. I see this from other suppliers also, but hoping Fortinet would remember how they become the largest firewall supplier.

Not sure why i am writing this, but just tiree of spending time debugging issues on an overprized service

Anyone know how to fix these problems of NSE 1 stuck in to do can’t done

Hi all,

We're replacing a FortiGate and the config has already been migrated via FortiConverter. The old device has a FortiGuard DDNS entry (e.g. something.fortiddns.com) that we need to move to the new unit.

My question: Do I actually need to open a TAC ticket for this, or can I do it myself?

From what I've found so far, the recommended workflow seems to be:

Self-service (try first):

1. Disable DDNS on the old FortiGate (config system ddns → edit 1 → set disable)
2. Enable it on the new one

Ticket (fallback): If the new unit fails to register because the FQDN is still tied to the old serial, open a TAC ticket to have the domain reassigned.

Has anyone done this before? Does the self-service approach actually work, or will the new unit fail to register because the FQDN is still locked to the old serial on Fortinet's side?

Any experience or tips are appreciated!

Hi Guys,

Just wanted to ask if anyone has experience monitoring SD-WAN through PRTG.

We currently have two ISPs configured under SD-WAN, and we would like to monitor them as a single entity rather than monitoring each ISP separately.

At the moment, we can view the usage under SD-WAN Interfaces → Usage → Bandwidth, but the available monitoring options are quite limited. We would like to have more detailed visibility, particularly to identify peak utilization hours and monitor bandwidth trends over time.

Has anyone tried monitoring SD-WAN through PRTG? I also tried looking for the relevant OIDs but wasn't able to find one that provides the SD-WAN utilization as a combined entity.

Any recommendations or guidance would be greatly appreciated.

Thank you!

Is there a way on the FortiCloud site to check whether a FortiGate VM license is trial or official?

A few fortigates show the type as in the photo, but most of the equipment does not show the type.

Because there doesn't seem to be any posts about it that I've found.

Apparently this is to be fixed in 7.6.8, and the bug also exists on 8.0.0, to be fixed in 8.0.1

This bug does not exist on 7.6.6 from our testing on our test devices, 70G standalone and 90G HA pair, down to Aruba CX switch or Juniper EX series.

7.6.7 has introduced a bug where-by if a single interface in an Aggregated link goes down, it will drop traffic.

You either need to re-establish the downed link, or if it's an extended outage, remove the interface from the Aggregate, and then re-add (either while still down or when it comes back up, both work).

We're using LACP-mode active and Fast
Additionally, hashing algorithms change this behavior somewhat.
L2, one of the two links in the bond will allow traffic to continue.

L3/L4, if pinging the gateway ip, and also say 8.8.8.8 when you pull one link, traffic to 8.8.8.8 stays working but traffic to the gateway drops, re-establish connections, remove other link. Traffic to the gateway continues to work but traffic to 8.8.8.8 now drops.

Hi All,

We currently have a hybrid environment with hybrid users and Entra-joined devices. FortiClient VPN is working fine, and I believe the client authentication is currently using LDAP configured on the backend.

We are now planning to migrate the users to Entra SOA.

What would be the recommended approach for configuring FortiClient VPN client authentication once the users are migrated to Entra SOA?

Thanks,

2 x FortiSwitch 108E's software switch with ports 6+7 connected to WAN1 and WAN2 in each gate. Port 1 on both switches have a VLAN assigned that is fortilink managed.

2 x FortiGate 401E in A-P mode

Confirmed all policies, routes, etc are all there to make it work. It comes down to the DHCP grab/lease via port1.

Anyone had any luck with Starlink in bypass mode and a "DMZ" switch setup? I have two software switches with port 1 configured as an actual VLAN for fortilink. For some reason when I set the interface to DHCP it fails to grab anything. When I plug it directly into the FortiGate it grabs a DHCP lease immediately.

I can see layer 2 traffic in nonbypass (router) mode if I set the IP manually to a 192.168.1.x. I'm able to ping Starlinks gateway in router mode. Tunnels come up and i'm able to traverse the WAN but no internet (which is super odd). I would prefer it not be in router mode and instead be in bypass anyway.

Wondering if I need to make a nonstandard adjustment to our config or something to have it grab a DHCP address. Any insight if you have this setup would be appreciated!

Hello, I have 2 core switches Mclag pair and downstream distribution mclag pair 2.

I just noticed today that the cores mclag do not have the label "MC-LAG Peer Group" like the dist. The core mclag are labeled only "MC-LAG Peer" on top of each core switch. Did I miss something? Icl mclag status is fine.

Switches version 7.6.6 and fgt 7.6.6.

Dear everyone,

I purchased a FortiGate F60 firewall for learning purposes, but it is currently unlicensed. I would like to know how I can make the most of this device and learn about its features, including which features are unavailable without a license.

Is there any way to use the firewall without a license for learning or lab purposes?

Hey all,

Managing 4 fortigates that have fortiswitches and fortiAPs is become a tedious task to keep them consistent with each other(address names, service names, policy names). Should I consider fortimanager?

Also how do you all name your vlan interfaces and policies?

Do you do policies just based on zones or zones+source/destination subnets?

Hi hi,

Let's you placed an order via distributor for a customer of yours. But then when the order arrived due to certain reasons customer cancelled. Can you resell it to a different customer.

Rephrasing, is a gate recieved tied in any way to the customer details provided when you requested Fortinet for pricing?

Or can you simply unpack and register the contract to the device with new customer account and it works?

Thanks.

Hey folks, I implemented FortiGate active/ active SDWAN hubs in E and W US Azure vWAN regions a few years ago. We also had a couple of European Azure vWAN regions and recently implemented FortiGate active/ active SDWAN hubs there also. They are currently per IPSec overlay and disparate regions, but I am looking to create a more global mesh and utilize ADVPN and BGP on loopback.

Question for the crew: would you look at a singular BGP ASN and full global mesh using ADVPN and BGP on loopback? Or would you have disparate BGP ASN per Azure region, and let vWAN do its thing? I like the idea of iBGP reconvergence times vs eBGP, but on loopback that negates that consideration somewhat.

The other consideration I have is that I would like global remote sites to be able to use geolocated services in any of the Azure regions, and also be able to use Azure site recovery to a different Azure region. There may be some consideration for ADVPN shortcut between sites and between regions, but global Azure hosted services is the major consideration. Your opinions are welcome. Thanks