The short version
How does a Security Gateway connect?
A dedicated Internet handoff connects to a data interface on the gateway or to the customer’s upstream router. In a common routed design, Gaia provides the interface address and route, while the gateway’s installed security policy controls traffic. Network address translation may be needed for private IPv4 clients.
This example uses a single routed Gaia Security Gateway and a static IPv4 address. Clusters, virtual gateways, a separate router, BGP, VLANs, IPv6, or central management require the appropriate design and vendor documentation.
Menus and commands vary with Gaia release, appliance, permissions, and management model. An authorized administrator should preserve management access, save a backup, schedule changes, and prepare a tested rollback before altering a working connection.
01 / Preparation
Confirm the service and ownership.
Obtain the circuit ID, handoff location, interface type, port speed, approved optic and cable, VLAN tagging, MTU, and any required negotiation or FEC from the service order and equipment teams. Ask for the assigned interface address, prefix, gateway or routing instructions, and any separately routed public block. Do not substitute the addresses below.
Determine whether Gaia Portal or centrally managed Gaia settings are authoritative, and whether SmartConsole manages the gateway and policy. For ClusterXL or other clustered systems, coordinate addressing, synchronization, member roles, and failover with the firewall team.
02 / Interface
Connect and configure the correct port.
Connect the designated data port and confirm link state and negotiated settings on both sides. In Gaia Portal, Network Management → Network Interfaces is a starting point for reviewing the physical interface and its IPv4 configuration. Use a VLAN interface only when the service and network design require it. Record changes and apply them according to your deployment’s Gaia workflow.
A sample handoff.
- Interface
eth1- Role
- External data interface
- IPv4 / prefix
198.51.100.2/30- Example gateway
198.51.100.1
Use the address and gateway specified for your service. Interface names and available fields vary.
Address and default route
On a single, non-scalable gateway, this partial example sets an IPv4 address and a default next hop. The addresses are reserved for documentation; use the values and port assigned to your service.
set interface eth1 ipv4-address 198.51.100.2 mask-length 30
set static-route default nexthop gateway address 198.51.100.1 onThese commands change the live configuration and can interrupt access. Plan a change window and recovery access, confirm the route and existing configuration, and follow your deployment’s save and policy-installation procedures. Interface topology, access rules, and NAT are separate steps.
Review Check Point’s Gaia setup sequence and interface reference for your release.
03 / Routing
Provide a route toward the provider.
For a simple static routed service, configure an IPv4 default route through the next-hop address in the service order. Gaia Portal normally places static routes under Network Management → IPv4 Static Routes. In the example, 0.0.0.0/0 would use 198.51.100.1; the actual gateway must come from your provider.
When dynamic routing, multiple gateways, policy-based routing, or an HA cluster is in use, follow the established design. A route shown on the gateway does not by itself verify the return path or that traffic is permitted.
04 / Topology and policy
Keep Gaia and security policy aligned.
Gaia networking and SmartConsole gateway topology and access policy work together. Review the external and internal topology and anti-spoofing settings for the real networks behind each interface. Updating topology can overwrite existing definitions, so review the proposed change with the administrator rather than accepting a discovered topology blindly.
Review a narrowly scoped access rule for the intended users, applications, networks, and direction, then install the appropriate policy through the management workflow. For private IPv4 clients, Hide NAT may be appropriate; routed public addresses and IPv6 have different requirements. NAT does not replace an access policy. Verify the existing rule order and translation before adding anything.
Consult the vendor’s topology guidance and NAT policy reference for the applicable release. Do not disable anti-spoofing or security inspection as a routine shortcut.
05 / Verify
Check the path from both sides.
- 01
Check the physical link
Confirm the expected interface, speed, optics, cabling, and state with the connected device.
- 02
Check the gateway and route
Verify the applied address and route in the correct context. Where permitted, test the provider gateway and an authorized destination.
- 03
Test an internal client
Check DNS, the intended application, policy logs, source translation where required, and the return path. Record IPv4 and IPv6 separately when both are in use.
- 04
Save the baseline
Record the time, policy version, interface status and counters, and acceptance-test results. Validate failover only under the approved HA plan.
06 / Troubleshooting
Compare before changing.
These are read-only Gaia Clish examples. Replace the interface name with the actual port; available commands and contexts vary, especially on scalable or virtual platforms.
show interfaces allReview interfaces and identify the data port. Check link state and the connected device’s counters.
show route static allReview configured static routes, including the intended default and next hop. Verify the active path separately.
Reading an interface check.
gw> show interface eth1
Interface: eth1
Configured IPv4: 198.51.100.2/30
Configured state: onAddress: Compare the configured address and prefix with the service handoff details.
State: An enabled configuration alone does not prove that the physical link is operational. Check link status and counters on both devices.
Compare error, discard, and traffic counters at two recorded times on the gateway and adjacent handoff equipment. Counter increases identify where to investigate, but do not alone establish the cause. Review access and NAT logs for the specific permitted test flow, gateway topology and anti-spoofing events, and the return route. Avoid clearing evidence before recording it.
If names fail while connectivity to known destinations works, examine DNS separately. The business DNS guide offers safe initial checks. A ping test from the gateway may use a different source and route than employee traffic; correlate it with a client test.
07 / Performance
Measure the entire path.
The rated port speed does not establish the gateway’s throughput with the chosen software blades, inspection, VPN, packet sizes, and session load. Review the appliance specifications and resource and interface behavior during the issue. Five-minute averages can hide short bursts.
For a coordinated throughput test, use separate capable hosts across the actual path. The performance guide explains parallel iperf3 testing and its limits. Preserve existing inspection policies during ordinary diagnostics.
08 / Escalation
What to have ready.
- Service address, circuit ID, interface, and handoff location.
- Issue times and time zone, affected clients, and recent changes.
- Interface state, speed, and counter changes from each available side.
- Routing, access policy and NAT observations for the affected flow, with the return path.
- Test source, destination, address family, tool, and relevant logs.
Share diagnostics through an approved channel; they can contain sensitive details. For Stealth service, email support@stealth.net or call +1 212 232 2020. Consult your Check Point administrator or vendor support for gateway-specific behavior.
About this brief
Sources and further reading.
Use the Check Point documentation for your version and management model.
Interfaces and routing
- Gaia getting startedInterfaces and routes
- Gaia interface CLI referenceInterface command options
- Gaia R82 administration guideInterface and static-route commands
Topology and NAT
- Updating gateway topologyInterface topology and overwrite considerations
- Preventing IP spoofingTopology and anti-spoofing
- Configuring NAT policyTranslation methods and rule behavior
Prepared by Stealth Communications, a business connectivity provider. This independent guide does not replace your service documentation or Check Point’s instructions.