Our pricing is based on the equivalent daily effort of a single experienced engineer,
plus direct expenses when applicable.
We focus on clear, narrowly scoped engagements and do not pursue long-term,
open-ended projects. Most work is measured in days rather than months.
We do not apply markups on hardware, licensing, or third-party services.
Hardware procurement remains entirely with the client.
Prior to any contractual engagement, we are happy to discuss scope, feasibility,
and design considerations at no cost, in order to avoid critical misunderstandings
or unnecessary expenses.
Our goal is not to maximize billable hours, but to deliver practical, well-defined
designs that can be implemented efficiently and maintained sustainably.
The number of valid solutions is limited.
Therefore, several correct designs are prepared here in advance.
You only need to select one—just like pressing a button on a vending machine.
Proposed Solution 1: Transparent Mode Deployment
Transparent mode: a Layer 2 switch that operates as a firewall.
In practice, this means it can be deployed by simply inserting it into the existing path,
without requiring any network redesign.
In practice, this means it can be deployed by simply inserting it
outside the existing edge router,
without requiring any network redesign.
This solution 1 assumes that customers procure hardware independently (e.g., via Amazon), rather than through our company.
Because we charge only for design and engineering, the overall cost becomes more economical as the scale of deployment increases.
Our design fees do not scale with the number of deployed devices.
This makes large-scale deployments significantly more cost-efficient.
This solution is particularly suitable for environments such as call centers,
where a large number of WAN circuits must be deployed and managed.
***Observed behavior where probes generated by nmap are blocked
(this does not constitute an official penetration test).***
In a transparent mode deployment,
our solution can be integrated by simply connecting it outside your existing router,
especially in Wide Area Ethernet environments.
We focus exclusively on design and configuration.
Hardware procurement remains with the client;
however, prior to any contractual engagement,
we are happy to discuss suitable hardware options and deployment considerations,
including different WAN technologies, redundancy designs, and single-device failure handling,
at no cost.
Proposed Solution 2: Benefits of Building a Redundant Firewall Architecture Using VRRP Across Different Vendors
Disadvantages:
When firewalls from different vendors are configured in a VRRP-based redundant setup, user traffic cannot be preserved when a failure causes the active firewall to switch to the standby device. Existing sessions are terminated and must be re-established after failover.
Advantages:
However, in situations where a firewall vulnerability is disclosed and immediate action is required, this approach allows traffic to be switched—within 100 milliseconds after issuing a failover command—to a firewall from another vendor that is not affected by the vulnerability. This represents a design approach that has not existed in past firewall architectures.
Proposed Solution 3: Overlay-Based Satellite Internet
Why L2VPN Is Required in This Design
In environments where power-line stability cannot be guaranteed, relying solely on BGP convergence is not sufficient.
L2VPN is therefore introduced to compensate for BGP’s slow convergence behavior.
In this context, “overlay-based” refers to a logical network layer built on top of existing terrestrial or wired infrastructure, with satellite connectivity used as one of the underlying transports.
In this model, satellite connectivity is treated as an underlay component of a large-scale L2 network, enabling higher-layer overlays to operate independently of the underlying transport.
Due to licensing considerations, detailed implementation specifics are not included in this document. Additional technical insights will be published separately in a personal blog at a later stage.
Web conferencing applications suitable for Starlink connections
The system architecture is shown below.
The diagram also includes the equipment used for performance validation.
Test Results
Jitter（Video）
Jitter（Voice）
NTP
Why NTP?
Throughput and latency alone cannot describe the true nature of a network.
Satellite networks are not only fast or slow,but temporally unstable.
NTP reveals this hidden instability.
In conclusion, based on these test results, the only recommended web conferencing application is Google Meet.
Even when reach remains stable,offset values fluctuate significantly.
This indicates that Starlink connectivity is not unreliable, but temporally unstable.
This evaluation is not intended to promote Starlink itself, but to clarify its characteristics as an underlay in overlay-based network design.