We currently run v6.4.10 for our FMG-VM and manage bigger customer's
FortiGates(FGTs) totalling about 600 (soon to be 800+).And one of them
needs one VIP group (two VIPs) at all 500+ locations. We use policy
packages for this customer to standardize ...
I can't easily find this part of FGT-Managed FSW operation in the guid
books or somewhere else. So I decided to post this. I was trying to
figure out how to duplicate Cisco CBS switch's default QoS behaviors
with FSWs and looked like I messed up conf...
I just saw an RSS feed announcing FAC 6.5.0 release. Since other
products around FortiGate has version numbering scheme 6.4, 7.0, 7.2 so
far, it's a little surprise for me to see 6.5.0 as the FAC's new version
number. Then also realize the FAC genera...
The "bandwidth-unit" option described in the KB below (also in CLI
references) doesn't seem to exist at least on FG60E/60E-POE with 6.4.x
while I can see this option on 1000D/1500D we have. Is this limited to
some certain
models?https://community.for...
Not sure if this is because WPA3 SAE's spec is not allowing or making
this combination useless/meaningless. But with our 6.4.10
wireless-controller on a FGT, I don't seem to have an option for
wpa3-sae+captive-portal in the VAP's security setting, wh...
Again, take a look at the policy allowing the Azure access for the users
over MPLS, MPLS->Azure. Is it NATed? And check IP on "Azure" VPN
interface. To NAT that policy, the IP on Azure int have to be within the
/16. If not, you need to remove the NAT...
Your objective is to set up multiple SSL VPN user groups based on groups
on Azure AD, like Group1, Group2, ... Right?Then you just need to create
different groups under "config user group" with the same SAML server
name but different group-names copi...
In other words, there should be policies to allow other sources
accessing to "Azure" including the remote location's VPN. Check those if
those are NATed as well. If so, likely Azure side has route only back to
that Azure VPN interface IP on this FGT....
I meant to sniff the same for the working one sourced from another FGT
location.But if you NAT it it would use the interface IP of the Azure
VPN as the source IP. That's why the outgoing packets don't show up with
your sniff filter "host 10.212.134.2...
So 54.1.1.14 is the real IP configured in SSLVPN_TUNNEL_ADDR1 then. If
you run "show firewall address SSLVPN_TUNNEL_ADDR1", you can see it even
if you didn't configure SSL VPN yourself.But the first problem is the
RDP(TCP 3389) SYN packets are coming...
