SaintAndrew Knowledge

 Problem Each user receives a fixed IP address for the VPN tunnel from the RADIUS server (in this case a FortiAuthenticator). Solution FortiAuthenticator / other RADIUS Server For the RADIUS server, the RADIUS attribute "Framed-IP-Address" must be defined per user. FortiAuthenticator FortiGate On FortiGate side we need the following configuration (expect the default Radius Configuration): config vpn ssl web portal     edit "tunnel-access"          set ip-mode user-group          set ip-pools "SSLVPN_TUNNEL_ADDR1"     next end ip-mode : user-group: Get IP-address from RADIUS Attribute ( Framed-IP-Address ) range: The default option. Define to distribute IP-Addresses from the SSL-VPN IP Range ip-pool : Which IP-Pool is used to distribute IP-address when ip-mode option is "range". If you choose "user-group" the static IP Address from the RADIUS Server has to be in that range. Verify diag debug enable diag debug application fnbamd -1 <-

 Problem Especially in the VPN area, certificates are increasingly used for authentication. But what happens if such a certificate is revoked? How does FortiGate ensure that such a certificate can no longer be used? Solution With OCSP it is possible to check live whether a certificate is still valid or not. For this purpose, when using the certificate, the certification authority is queried via an API whether the certificate used is still valid or has been withdrawn for some reason. The certificate status at the certification authority is checked and not the expiration date or similar. CRL vs. OSCP CRL lists are cached on the system. OCSP is queried live via the certificate authority and thus receives a real-time response. Furthermore, OCSP does not need to check the complete CRL list, but directly requests the required certificate. What can be a disadvantage for websites with a lot of traffic (a lot of traffic at the OCSP server) is a big advantage for the SSL-VPN security. Configurat

 Problem When SSL VPN is set up as usual with Central NAT enabled, login from the client does not work.  The following message appears in the SSL VPN settings: What must be configured differently with Central-NAT enabled? Solution The only difference between enabled and disabled Central-NAT is the handling of the firewall rules. Deactivated Central-NAT: Traffic Control => config firewall policy SSL-Inspection & Authentication => solved by default firewall rules Enabled Central-NAT: Traffic Control => config firewall security-policy SSL-Inspection & Authentication => config firewall policy This difference explains that when Central-NAT is enabled , one or more general rules for authentication and SSL inspection are defined in the " firewall policy ". The actual traffic is filtered in the " security-policy ". However, the SSL VPN requires a valid firewall policy under " firewall policy " in both cases (activiated or deactivated Central-NA

 Problem When the Central NAT function is enabled, the behavior and configuration of the NAT changes. Also this of the Destination NAT.  The question is, how do I configure an inbound NAT when Central NAT is enabled? Solution When Central NAT is enabled, it is not necessary to add the VIP object into the firewall policy as destination address. This is a normal behavior due to the fact that, in a Central NAT status, the DNAT is injected to the kernel since the object is created into the Policy & Objects -> DNAT & Virtual IPs . The only thing you have to do is to create a Virtual-IP object: After that we need an appropriate Firewall Policy : Which IP-Address as Destination is the right one? Bevor FortiOS 6.4.3: -> Use the internal IP Address as destination (in my case: 172.16.51.12) After FortiOS 6.4.3 -> Use the external IP Address as destination (in my case: 10.10.10.250) What's happen with the 'match-vip-only' option? Starting from 6.2 there is a new fe

 Problem Especially in small networks, sometimes you do not have a dedicated DNS server available. For this purpose, the FortiGate can be used as DNS server. For larger installations, all DNS queries should be proxied for security reasons. The FortiGate can also help here. Solution A detail documentation about the DNS Server functionality is in the offical documentation:  Fortinet Doc In this post I would like to clearly present the most important functions and configuration types of the DNS function. DNS-Server In the following example the FortiGate act as DNS Server: Enable DNS Feature Enable the DNS Feature in the GUI: CLI command: config system settings     set gui-dns-database enable end Configure DNS Server Enable the DNS Feature on the interface on which DNS requests should be answered: Select Network Select DNS Servers Select the listen Interface Select the DNS Server Mode (see delecration below) The same on the CLI: config system dns-server     edit DMZ2          set mode recu

 Problem Sometimes it is not necessary to convert the complete internal or external IPv6 traffic to IPv4. What must be done if only individual IP addresses are translated? Solution For translating individual IPv6 from IPv4, the configuration is very similar to when all IP is to be translated. In detail the following configuration is necessary: config system nat64     set always-synthesize-aaaa-record disable end always-synthesize-aaaa-record :  the DNS proxy does not check for AAAA records but rather synthesizes AAAA records. We need a virtual IPv6 address from the DMZ2 Range. With that we are able to define the Virtual-IP object. config firewall vip64 edit "nat64_Server" set extip 2001:db8:211:5c:4000::2 set mappedip 172.16.51.12 set portforward enable set extport 443 set mappedport 443 next end extip : The virtual IPv6 address mappedip : the real IPv4 address As usual by FortiGate, at the end we need a firewall policy to all

 Problem In this scenario, IPv6 is already used internally. So that the whole Internet is available - also websites without IPv6 address. Solution A NAT64 - translation from IPv6 to IPv4 - is performed on the FortiGate unit. We assume that the IPv6 configuration has already been done (otherwise check the following post:asdf). Thus, we focus on the NAT64 configuration and look at it in more detail. The idea All IPv6 addresses from the DMZ2 Network (2001:db8:211:5c:4000::/64) subnet will be translated to the 195.157.52.0/24 IPv4 Subnet. For this the following configuration is needed: config system settings     set gui-nat46-64 enable end gui-nat-46-64 : enable the GUI features for NAT64 and NAT64 feature Next, we need a IP-Pool object. This defines the actual translation as we know it from a classic virtual-IP object. config firewall ippool     edit exit-pool4          set startip 195.157.52.25          set endip 195.157.52.200     next end HINT: You can also use just one IP-address in

 Problem In this scenario you have two ISP connections and learn routes over BGP. You would like to use both ISP connection and would like to configure load-balancing over both ISP-connections. Solution That's an easy thing. :) Enable ebgp-multipath  option in the BGP configuration part. config router bgp     set ebgp-multipath enable end If you would like to do the same in iBGP, than use ibgp-multipath Verify Before enable multipath get router info routing-table all Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default Routing table for VRF=0 B* 0.0.0.0/0 [20/0] via 10.10.10.254, port4, 00:00:45 C 10.10.10.248/29 is directly connected, port4 C 10.10.60.248/29 is directly connected,

 Problem Each cluster has its own HA management interface via which each individual member can be managed. Now it is required that the connection to FortiAnalyzer, SNMP etc. should be done via the respective HA management should be done. Solution With the ha-direct option it is achieved that services (e.g. syslog, FortiAnalyzer, SNMP, Netflow) are routed over this interface. The detail configuration looks as follows: FortiGate Primary HA Member config system ha     set ha-mgmt-status enable     config ha-mgmt-interfaces          edit 1               set interface mgmt1               set gateway 192.169.80.1          next     end     set ha-direct enable end ha-mgmt-statuts : Activate dedicated management interface ha-mgmt-interfaces : Configure the dedicated management interfaces interface : linked physical interface gateway : default gateway to route traffic over the dedicated management interface ha-direct : enable direct HA management interface for FortiGate system services (e.g.

Problem Often you don't use IPv6, but sometime you have too and than I have to search the solution from different internet sources together to find the right solution.  To avoid this in the feature the important commands you have to know. ;) Solution Basic IPv6 Config First of all, we need to enable IPv6 via CLI (this behavior is change in FortiOS 7): config system global     set gui-ipv6 enable end Afterwards you get new GUI options, for example: Basic IPv6 Interface Config Let's take a look to the interface options. In general all IPv6 commands are in config ipv6   Static IPv6 address That's easy: config system interface     edit wan          config ipv6               set ip6-mode static               set ip6-address 2001:db8:2::2/64               set ip6-allowaccess ping          end     next edit lan          config ipv6               set ip6-mode static               set ip6-address 2001:db8:3::1/64               set ip6-allowaccess ping               end     next

Problem How to configure OSPF on two FortiGates to restribute Default GW from HQ to Office 1 and Office 1 redistribute his local Subnets to the HQ (without the Transfer Subnet for Intern VDOM-Links). On top use the OPSF on Office 1 to reach all Subnets in the different VDOMs. Solution OSPF between HQ and Office1-root First start with the basic connection in the Area 0.0.0.0 between the HQ and the Office1 Firewall: FGT-HQ config system interface     edit lback-ospf          set vdom root          set type loopback          set ip 10.0.0.1/32     next end config router ospf set default-information-originate enable set router-id 10.0.0.1 config area edit 0.0.0.0 next end config network edit 1 set prefix 172.17.10.248 255.255.255.248 next end config redistribute "connected" set status enable end config redistribute "static" set status enable end config redistribute &q

Problem Design with two ISPs and an RIPE Routed public IP Ranges. How to solve, that the public Range is available over both ISPs but without asymetric Routing and ISP-1 is the primary. Solution FortiGate Basic BGP configuration First start with basic BGP configuration config router bgp set as 65301 set router-id 100.200.100.254 set keepalive-timer 45 set holdtime-timer 120 set bestpath-med-missing-as-worst enable set graceful-restart enable     config redistribution connected          set status enable     end end bestpath-med-missing-as-worst :  The route without MED is automaticly the worst destination. gracefule-restart :  Advertise reboots to neighbors so they don't see the router as offline, wait before declaring them offline, and how long to wait when they reboot before advertising updates. These commands apply to neighbors and are part of the BGP capabilities. This prevents unneeded routing updates. holdtime-timer: How long the router will wait for