A 4G modem, cellular router or CPE used with an enterprise firewall should hand the cellular connection downstream without quietly creating an unnecessary second routing layer. The real task is not simply enabling a setting called Bridge Mode. The project has to prove what address reaches the firewall, where NAT still occurs, and whether the WAN returns correctly after the cellular session changes state.
This matters when the firewall or SD-WAN appliance already owns routing, VPN termination, access policy, logging and WAN failover. Internet access alone does not prove that the cellular handoff is correct. A firewall can reach the internet while still sitting behind modem-side NAT, carrier-grade NAT, or both.
A useful commissioning question is therefore: what should the firewall WAN receive, and will it receive the right state again after an outage or reconnection?
Configure the intended cellular profile and APN first. Then enable the exact bridge or IP passthrough behaviour supported by the cellular device, connect the documented Ethernet handoff to the firewall WAN and configure that WAN for the address-assignment method the device actually uses. Record its IP address, gateway, DNS information and lease behaviour. Next, determine whether private addressing originates locally or in the carrier network. Finish by testing DNS, MTU, failover and automatic recovery rather than stopping after the first successful connection.
Do not diagnose the handoff from one screen
Bridge and passthrough problems become easier to locate when the project records what the cellular side sees, what the enterprise firewall receives and what the outside network sees.
Record the active APN and cellular-side addressing exposed by the device while the connection is established.
Capture the IP address, gateway, DNS and lease information actually delivered to the downstream firewall.
Compare the address observed by outbound traffic to identify whether another translation layer exists upstream.
Define what a successful 4G modem handoff should look like
Before changing either device, define the result the project expects. Bridge mode and IP passthrough are often treated as if they automatically mean “the firewall receives a public IP.” In practice, the local handoff and the carrier addressing model are separate parts of the connection.
A cellular device may hand its session downstream correctly while the mobile operator still uses private or shared addressing farther upstream. The reverse can also happen: the carrier service may be suitable, but the local device still creates another routed subnet before the firewall.
The acceptance condition should therefore be observable. The cellular device establishes the LTE data session, the firewall receives the intended WAN handoff, and no unexpected routing or NAT boundary appears between them.
1. Confirm what bridge mode or IP passthrough actually does
Start with the documented behaviour of the exact cellular platform rather than the wording of one configuration option. A feature labelled IP passthrough can solve the same architectural problem as bridge-like operation without behaving identically internally.
Establish how the downstream firewall receives its WAN address. The firewall configuration must match that handoff rather than a generic assumption about bridge mode.
Confirm which physical port participates in the handoff and whether that port has a fixed WAN/LAN role or a configurable role on the selected device.
Determine how engineers will reach the cellular device after passthrough is enabled. This becomes important when a remote site later needs SIM, registration or cellular troubleshooting.
Verify from the firewall side whether translation remains active instead of assuming the feature name proves that NAT has disappeared.
Understand what happens to the downstream WAN address when the LTE session drops and reconnects. Recovery behaviour matters as much as the initial lease.
Verify which local services remain available after passthrough is enabled. NAT, firewall, VPN, QoS, routing, Wi-Fi and management behaviour can vary by model and firmware, so the production design should follow the documentation for the exact selected device.
2. Set the cellular profile and APN before troubleshooting the firewall
The APN belongs early in the diagnostic sequence because the mobile service can influence the addressing available to the cellular session. If a project uses a specific carrier APN, private APN or managed addressing service, confirm that configuration before changing downstream firewall routes or NAT rules.
Confirm that the cellular session is registered and using the intended profile before interpreting the firewall WAN result.
Capture the device-side address information exposed by the interface while the session is working.
Avoid changing APN, passthrough and firewall WAN settings in the same troubleshooting attempt.
This order prevents engineers from spending time on enterprise firewall rules when the upstream cellular session does not match the service the project intended to use.
3. Inspect the firewall WAN instead of trusting a green connection icon
Once the cellular session is stable, connect the intended Ethernet handoff to the firewall WAN and configure that interface according to the cellular device’s documented behaviour. Do not assume DHCP, a static address or another assignment method unless the selected platform documents that handoff.
At this point, the firewall becomes the most useful source of evidence. A green WAN indicator shows that some connectivity exists; it does not establish whether the expected address arrived or whether hidden NAT remains upstream.
Capture these four values before testing an interruption
Inspect the same fields again after failover or cellular recovery.
If no address appears, stay at the handoff boundary. Check the Ethernet link, cellular session, passthrough state and expected address-assignment method before changing unrelated firewall security policies.
4. Decide whether the private address comes from the device or the carrier
This is the diagnostic step that separates an unexpected local routing layer from a carrier-side addressing condition.
Compare the address visible on the cellular side, where available, with the WAN address received by the firewall and the address observed by outbound internet traffic. The objective is not to make every address identical. It is to identify where translation occurs.
The firewall may be receiving the cellular-side address through the intended passthrough mechanism.
A public-looking address alone does not prove every required inbound service is reachable. Check the carrier service where inbound access matters.
The cellular device may still be acting as a routed NAT boundary between LTE and the enterprise firewall.
Compare device-side and firewall-side addresses and identify whether a separate private subnet exists locally.
The local passthrough may be correct while the mobile operator performs carrier-grade NAT farther upstream.
Confirm the SIM, APN and carrier addressing service rather than repeatedly changing firewall NAT rules.
This distinction matters most when the project expects externally initiated VPN traffic, remote access or another inbound service. A successful outbound session proves that traffic can leave the site. It does not prove that the WAN address can accept unsolicited connections from the public internet.
5. Test DNS, MTU, failover and recovery after the connection changes state
The first successful connection is often the easiest part of commissioning. Integration problems become visible after the LTE session reconnects, the primary WAN fails or the firewall has to obtain a fresh WAN lease.
Test the whole recovery path, not only cellular registration
Trigger the relevant primary-WAN or cellular failure in a controlled test.
Allow the LTE session to return using the intended production configuration.
Compare the new address, gateway, DNS and lease state with the baseline.
Test the VPN, SD-WAN route or application traffic that the site actually needs.
DNS: separate name resolution from WAN failure
Test direct IP connectivity and DNS resolution independently. If IP connectivity returns but names do not resolve, the LTE path may already be working while DNS state remains wrong.
MTU: test real application traffic
Basic traffic may succeed while larger packets or encapsulated VPN traffic expose an MTU problem. Test the applications and tunnels that will actually cross the cellular WAN rather than applying a universal MTU value by habit.
Failover: prove that packets move to LTE
Where cellular is the backup WAN, interrupt the primary connection and confirm that required traffic actually uses the LTE interface. A firewall reporting the backup interface as “up” is not the same as proving the production route.
Recovery: watch for stale addressing
When the cellular session returns, inspect the WAN lease again. If an engineer must manually renew the firewall interface every time, the connection has not demonstrated unattended recovery.
Match the cellular hardware to the firewall handoff you actually need
The configuration work above gives procurement a much clearer requirement. For an enterprise firewall that expects Ethernet, the useful question is not which cellular device has the longest feature list. It is which platform can provide the required Ethernet handoff, IP passthrough behaviour and recovery path for the project. The options below represent different deployment conditions rather than a simple good-better-best ranking.
H820t IoT 4G Router
H820t is a practical direction when the existing enterprise firewall needs cellular WAN delivered through Ethernet while routing, VPN and protected-network policy remain on the downstream security platform. The H820 platform includes IP passthrough and wired WAN-to-LAN passthrough functions.
H900t 4G Router
H900t becomes more relevant where the cellular edge has a broader role than a basic Ethernet handoff. The H900 platform includes IP passthrough, Gigabit Ethernet connectivity and dual-SIM support for projects with more complex WAN or redundancy requirements.
H820QOt 4G Outdoor CPE
H820QOt addresses a different physical deployment problem: the cellular device needs to be positioned outdoors while Ethernet carries the WAN connection back toward an indoor firewall. The platform includes Ethernet connectivity and IP passthrough functionality.
Which product direction matches the site?
Accept the deployment only after the firewall survives a real state change
A commissioning record should make the architecture understandable to another engineer without requiring the installation to be rediscovered. Save the working WAN state, identify where translation occurs, and document how the connection behaves after failover and recovery.
Go-live checklist
- Confirm the intended APN and cellular registration.
- Confirm bridge or IP passthrough behaviour on the exact selected device.
- Record the firewall WAN address, gateway, DNS and lease state.
- Identify whether a local NAT layer remains between the cellular device and firewall.
- Separate local private addressing from carrier-side CGNAT.
- Test required VPN, SD-WAN and application traffic over the cellular WAN.
- Check DNS and MTU behaviour under production-like traffic.
- Trigger the intended primary-to-LTE failover condition where applicable.
- Restore the connection and confirm that the firewall recovers without an unplanned manual WAN renewal.
Use the firewall requirement to narrow the cellular hardware
If the project needs a different interface or integration method, continue through the industrial 4G router options for project deployment rather than choosing a device only because it can connect to LTE.
For Ethernet firewall projects, confirm the exact passthrough behaviour, address handoff and recovery method before ordering. The device should fit the existing network architecture rather than forcing the firewall design to adapt around it.
Explore the industrial 4G router range if the project needs a broader comparison before model confirmation.
Frequently asked questions
Is IP passthrough the same as bridge mode on a 4G modem?
Why does the firewall still receive a private IP address?
How can the firewall confirm it received the intended WAN address?
What should be tested after the cellular connection recovers?
Turn the firewall requirement into a model-confirmation request
The most useful enquiry does not simply ask for a 4G modem. It explains what the enterprise firewall needs to receive, how the cellular device should hand over the WAN connection, and what must happen after an outage.
With those details defined, E-Lins can confirm which hardware and configuration should be evaluated before the project commits to a specific cellular edge device.
