This function itself　リンク先スレッド　We have already touched on this feature,
but we will conduct more in-depth validation testing.

We plan to conduct various intrusion tests
(penetration testing)
to verify whether attacks can be successfully blocked.
(The general approach has already been published
on our personal blog.)

We will also configure known C&C IP addresses
(IP addresses classified as malicious)
on other network devices
within the local environment,
and verify that communication
is blocked in both directions
—outbound and inbound.

In addition,
we will test defenses
against stealth scans,
as well as alerting functions
that generate email notifications.

Our previous experience
has been limited to SMTP-based methods,
so we will challenge ourselves
to explore alternative approaches.

We will conduct validation testing
by launching attacks over Wi-Fi
and verifying that communications
can be properly blocked.
We are currently studying Kali
for this purpose.

① Rogue AP detection
We will verify the function
that detects access points
broadcasting the same SSID/PSK
as those under the control
of a FortiGate configured as a WLC,
but not actually managed by it.
Additional notes will be added
when time permits.

② The function shown
in the image below
has caught our interest.
We will test it by combining
FortiWiFi and FortiAP units
(both already obtained).

We will connect the FortiWi-Fi
under another access point.

First,
apply Wireless-Client Mode
from the pane shown below.

After this,
a reboot will be required,
so restart the device when prompted.

Then,
in the pane shown below,
you will be able to select
the access point
to connect to.

After selecting the SSID
you wish to connect to,
click Connect.

If you choose a Security Mode
other than “Open,”
you will be prompted
to enter the PSK
(Pre-Shared Key).

Enter the key,
then click Connect again.

From the Dashboard CLI,
we were then able to successfully ping
the default gateway
via the connected access point.

At this stage,
connectivity is limited
to the default gateway only.

There is no connectivity
to the Internet
beyond the uplink access point.

Therefore,
we manually configure
the default gateway.

We were able to successfully ping
the Internet.

In the pane shown below,
if you enable “Retrieve default gateway from server,”
the Wi-Fi interface loses its IP address.
Therefore, this method is not recommended.

We will also verify
that the device functions properly
as a network appliance,
ensuring that traffic for specified classes
does not exceed
the configured bandwidth limits.

Performance evaluation of QoS
is one of our core strengths.

In addition,
we will demonstrate through testing
how the legacy priority control method
known as PQ
can indefinitely delay
the transmission of long packets.

Lack of awareness
of this anti-pattern
often leads to configurations
where everything is placed into PQ.
This reflects a broader issue:
many network engineers
are not sufficiently familiar
with the underlying principles
of CPU scheduling behavior.

In the era of Web-RTP,
there is little reason
to rely on the legacy
“SIP-specific NAT handling” anymore.

Regarding VoIP,
we have repeatedly challenged
questionable claims
made by so-called
“Web-RTP providers.”
Key findings are listed below.

“The cause is electromagnetic interference.”
→ We monitored
with a spectrum analyzer
for several days
across the 40 MHz–6 GHz range.
No transient emissions
capable of explaining the issue
were detected.

“The packet payload is not RTP.”
→ When decoded in Wireshark
as RTP, the payload
was confirmed to be RTP.
It was possible
to reconstruct audio files
from the packets.
However, spectrum analysis
showed full-band dispersion,
indicating encryption.
Therefore, in that case,
we were unable to identify
the root cause
of the reported noise.

This should perhaps belong
in the QoS section,
but many Web-RTP providers
do not understand
excess burst
or committed burst parameters.
Some even claim
that “the peer router is Cisco,
so it will handle it properly.”
In practice,
they often do not understand
RSVP at all.
A short two-way discussion
usually reveals
the technical gaps immediately.

Noise in VoIP audio
may be caused by
AI-based noise cancellation.
Voices from other operators
in the background
are not always removed effectively.
In some cases,
traditional phase-inversion
techniques
(overlaying an inverted signal
from the rear direction)
can be more effective.

Cloud services may “move” servers geographically
during an active session.
As a result,
the destination IP address
can change while communication is in progress.

Because of this behavior,
there are cases
where Web filtering
cannot be enabled.
The cause is outlined below.

When packet fragmentation occurs
during communication,
two well-known domestic UTM vendors
(both Y and N)
lose connectivity.
FortiGate, however,
continues communication
without issue.

Both vendors confirmed
that the root cause
is the same.
(We verified this directly
with the manufacturers.
The fact that they were not fully aware
of the issue in real operations
was somewhat concerning.)

• They perform Web filtering
  by inspecting strings
  inside packet payloads
  rather than using DNS.
  When packets are fragmented,
  the payload cannot be read.
• Allowed IP addresses
  are internally cached.

FortiGate performs Web filtering
based on FQDN,
so this interruption
does not occur.

For vendor Y,
we confirmed the algorithm
through the reseller.
For vendor N,
we reproduced the issue ourselves
and escalated it
to the manufacturer.

In the case of vendor N,
out of roughly 50 tests,
the issue occurred
in more than 5 out of 6 attempts.
For FortiGate,
after 6 consecutive successful runs,
we concluded the test.

We will reproduce this behavior
in our own environment
and publish the results.

For reference,
we list the tools
to be used.

Tools used

Httping

Cisco 800
(used as a Web server,
with multiple IP addresses
assigned via secondary IP)

FakeDNS

This is not a particularly advanced technique,
but there are still cases
where deployments are abandoned
simply because
the cloud environment
and the on-premises LAN
use the same IP subnet.

The original designer
is the same as that of the SSG line,
although it is not widely known
that Juniper merely acquired
the NetScreen company.

Since implementation
is not guaranteed
in every environment,
we will actually deploy it
and verify through testing.

For high-volume traffic
such as Office 365 updates,
it is generally preferable
to use a dedicated circuit
or an internal WSUS server
(although WSUS itself
may now be considered legacy).

However,
when the IP addresses
returned by DNS change,
routing cannot be controlled
reliably using conventional methods.

For this reason,
routing is performed
based on DNS information
(FQDN routing).
We will verify this behavior
in practice
and publish the results.

The configuration
looks like this:
when creating an address policy,
there is a checkbox labeled
“Use in static route.”
Once enabled,
the static-route creation pane
appears as shown below.

When multiple circuits are available,
this enables high cost-performance
Active/Active operation.
We will build an intentionally unbalanced setup
in which one circuit
is consistently lower in quality,
and verify the behavior in practice.

Inbound load balancing
is also possible,
but only with basic health checks.
Therefore, it is not suitable
for full Web server load balancing.

It is worth noting
that by combining multiple DNS servers,
a form of wide-area load balancing
can be achieved.
Since FortiGate itself
can operate as a DNS content server,
we will also test
whether wide-area load balancing
can be implemented
using FortiGate alone.

Using another network device
to perform Twice NAT
—so that the load-balanced destination
and source are translated simultaneously
before querying FortiGate for DNS—
would technically work,
but that approach
does not feel aligned
with the design intent.

We often see organizations
applying IPsec
on top of already encrypted traffic
such as Office 365,
SNMP over TLS,
and DNS over TLS,
resulting in unnecessary
performance overhead.

We will verify in practice
how encryption can be applied
only to selected traffic
—for example SMB
used by NAS systems—
and publish the results.

Organizations with ample budgets
often resolve such issues
by replacing equipment
with larger, more expensive models.
However, since our service
does not rely on SI-style resale
or pushing high-cost hardware,
we believe this is a strong case
demonstrating the value
of an optimization-focused approach.

This idea came from a separate discussion
about “dumping server memory via Telnet
for quarantine and inspection.”

Since SSH is encrypted,
it would normally be difficult
to detect malware
contained in server memory.
However, by combining it
with inspection features,
it may become possible,
so we will verify this behavior.

We will also test
whether it is possible
to block SCP/FTPS/SFTP
while allowing SSH itself
by using inspection features
on the network device side,
rather than disabling
file transfer functions
on the SSH server.

The results of these tests
will be published here.

While it is obvious
that the device does not have
sufficient power
to accelerate Web servers,
we would still like to attempt
SSH certificate interception.
From the image below,
it is not yet clear
how the SSH private key
would be installed.

There should be a function
to prevent the device
from behaving statefully.
We will verify
whether this can be achieved
by combining it
with transparent mode.

However,
since FortiGate alone
is capable of capturing packets
while applying filters,
it may be sufficient
to perform filtering
directly in transparent mode.

Only during specified time periods
are selected applications
(or their traffic) permitted.

In the example below:

• From 06:00 to 10:00, all traffic is allowed.
• During all other hours, video (YouTube) is blocked.

The parent IPv4 policy
is set to allow,
and a child application-control policy
is applied
to block Video/Audio.

In this configuration,
only video traffic is blocked,
while other communications remain permitted.

YouTube is blocked,
but video content
embedded in news sites
is not blocked.

When used in combination with Wi-Fi,
it is unclear whether there is a function
that converts destination MAC addresses
from multicast to unicast
or performs load balancing.

However, the following type of control
appears to be possible.

Rather than conducting exhaustive tests
using tools such as VNC,
we plan to perform validation
after Hikari TV is installed in our home.

Testing with real multicast traffic
is more meaningful
than relying solely on synthetic simulations.

Deploy one unit
in transparent mode
at each teleworker’s home,
and have IPS/WAF
inspect traffic
in the WAN-to-LAN reverse direction.

Validation is likely unnecessary.

This may be achievable
in transparent mode.
We will verify this
on actual hardware later.

It is unclear
how meaningful the results will be,
but we may also test
using a VM-based virtual appliance.