FortiWeb 8.0.6 & 7.6.9 KVM (standalone, Proxmox) — Server Policy shows "Running" but port 80 gets instant TCP RST, no listening socket ever created

Forum|Forum|9 days ago
August 1, 2026
3 replies
46 views

Running FortiWeb KVM_PAYG on Proxmox (standalone, not a cloud marketplace deployment). Reproduced this identically on two separate fresh installs — 8.0.6 build0116 and 7.6.9 build1133.

Setup:

Operation Mode: Reverse Proxy, standalone (no HA)
port1 (external): static/DHCP IP, allowaccess includes http/https/ssh/ping
port2 (internal): static IP, reaches backend fine
Server Pool → backend IP:80, enabled
Virtual Server → Use Interface IP enabled, bound to port1
Server Policy → links VS + Pool + HTTP Service (port 80) + a Web Protection Profile, status shows Running
admin-port moved to 8080 beforehand, confirmed no port-in-use conflict when creating the policy
License page: all green (VM License, Support Contract, etc.)

Symptom:
Client (Kali, same L2 segment) connects to the Virtual Server IP on port 80:

curl -v http://<VIP>
* connect to <VIP> port 80 failed: Connection refused

CLI sniffer on port1 confirms FortiWeb itself sends the RST immediately (0ms), not a network path issue:

diagnose network sniffer port1 'tcp port 80' 4
...syn...
...<VIP>.80 -> client: rst 0 ack...

ARP confirms the responding MAC is genuinely FortiWeb's port1 MAC (no IP conflict on the LAN).

diagnose network tcp list shows no listening socket anywhere on port 80 (searched for hex :0050), before or after a full reboot.

Already ruled out:

Virtual IP object conflicts (none — using Use Interface IP)
admin-port/service-port collision (moved off 80 before policy creation)
Monitor Mode on and off — no change
HA/passive node — standalone confirmed
Licensing — all green
Interface allowaccess missing http — added, no change
Fresh VM, fresh config, twice, two firmware versions — same result

HTTPS (443, admin GUI) works perfectly on the same interface/IP, so the interface and TCP stack in general are healthy — this seems isolated to the reverse-proxy data-plane socket specifically never binding despite the policy showing Running.

Has anyone seen the proxy engine (httpsd) fail to actually open the Server Policy's listening socket on KVM specifically? Any known additional activation step for PAYG images outside a cloud marketplace, or a daemon-reload command beyond a full execute reboot?

Jean-Philippe_P

Staff & Editor

Hello mohaawre,

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Regards,

Jean-Philippe - Fortinet Community Team

Yurisk

SuperUser

Looks contradicting to me - running Pay-as-You-Go image on your own infrastructure and thus not paying anyone. I have never seen PAYG images run on premises - you either buy permanent license or you run them in the public cloud where billing is done automatically. There is FortiFlex type of licensing - where you can spin and license instances as you wish, consuming from the total count, but something tells me it is not your case.

I am surprised, actually, that you succeeded to install such image without it logging you out on missing license immediately afterwards.

yurisk.info - all things Fortinet blog, no ads

AEK

SuperUser

Hi Mohaawre

I see the following in your confog

port1 (external): static/DHCP IP, allowaccess includes http/https/ssh/ping
...
Virtual Server → Use Interface IP enabled, bound to port1

Allowing http on the interface admin is probably conflicting with the VS listening on port 80 of the same interface IP.

If you want to use http for your VS, go to admin settings and change WebUI http port from 80 to something like 8080. Or just create a VIP (other IP) and listen on any port you want without conflicting anything.

AEK

Sign up

Login with SSO

Login to the community

Login with SSO