5Gstore Tech Corner: Fixing Asymmetric Routing with SpeedFusion + FusionHub Using Outbound Policy NAT

Every now and then, we run into a networking issue that isn’t caused by “bad VPN settings” or a broken firewall rule.

Instead, it’s caused by something much sneakier: asymmetric routing.

In this Tech Corner post, we’re walking through a real scenario involving:

• A Pepwave MAX BR1 Mini
• A FusionHub in Azure
• SpeedFusion VPN
• A remote device with a default gateway that could NOT be changed
• And the need to NAT traffic correctly so replies return through the Pepwave, not somewhere else

We’ll cover why the problem happens, what it looks like in packet captures, and the exact fix we used to resolve it.

The Network Setup (Customer Scenario)

Here’s the network design the customer shared with us:

Remote Site: Pepwave MAX BR1 Mini

The Pepwave is advertising two networks:

• Untagged LAN: 192.168.50.1/24
• Control VLAN 100: 10.120.2.5/24

Important detail:
✅ No public IP address available at the remote site.

Remote Computer (Behind the Pepwave)

• Static IP: 10.120.2.10
• Default Gateway: 10.120.2.1
  (and this cannot be changed, which is the root of the issue)

Cloud Side: FusionHub in Azure

• FusionHub DHCP subnet configured as: 10.250.32.240/28

VPN Connectivity

• The Pepwave and FusionHub are connected via SpeedFusion VPN
• A local computer connects into the FusionHub via OpenVPN

What They Wanted to Do

They needed the local computer (connected to FusionHub) to communicate with a remote device behind the Pepwave.

A simple test was attempted first:

✅ Ping from local computer to remote computer

• Ping requests arrived successfully on the remote computer

❌ Ping replies never returned properly

• Replies were being sent to the wrong gateway and disappeared

The Problem: Asymmetric Routing (Classic “One-Way Traffic”)

This is a textbook asymmetric routing scenario:

What’s happening?

1. The local computer sends traffic to the remote device through FusionHub
2. The remote device receives it
3. The remote device replies… but sends the reply to its default gateway:
   10.120.2.1 (not the Pepwave)

So even though the remote computer sees the request, the response does not take the same path back.

How we confirmed it

The customer captured packets using Wireshark on the remote computer and saw:

• The ping requests were coming from the FusionHub’s private Azure IP, not an IP address that the remote computer associates with the Pepwave network
• Because of that, the remote computer did what it was configured to do:
  send replies to its default gateway, which is outside of the Pepwave routing control

The remote device simply had no reason to send return traffic back through the Pepwave, because its default gateway dictates otherwise.

Why NAT Was Required

Since the remote computer’s default gateway could not be changed, we needed to “trick” the return path into staying consistent.

That meant:

✅ Make the traffic appear as if it originated from a local IP on the Pepwave network
So the remote computer returns the reply back to the Pepwave (because it sees it as local traffic).

That’s exactly what NAT does here.

The Fix: Use an Outbound Policy to NAT the Source (Recommended Solution)

Instead of trying to use SpeedFusion NAT mode globally, we applied a targeted Outbound Policy rule on the Pepwave.

This forces the traffic coming from FusionHub (Azure subnet) to be:

1. Routed into the correct SpeedFusion tunnel
2. NAT’d so the remote device replies correctly

Step-by-Step Configuration

✅ Step 1: Create an Outbound Policy Rule

Go to:

Network → Outbound Policy → Add Rule

Use the following:

Name:
FusionHub_to_Control_NAT

Source:
10.250.32.240/28 (FusionHub DHCP subnet)

Destination:
10.120.2.10 (remote computer)

Protocol:
Any

Action:
✅ Enforce traffic to SpeedFusion VPN tunnel

What this does behind the scenes

This forces the Pepwave to:

• Translate (NAT) the source IP to 10.120.2.1
• Ensure the remote computer responds back toward the Pepwave

So now, from the remote computer’s perspective:

• The request looks like it came from something inside its own network
• The reply naturally goes back through the Pepwave

✅ Step 2: Verify Rule Order (This Matters!)

Outbound policies are processed top-down, and order is everything.

Make sure:

• Your new rule is above any broad “Default” / “Internet” rules
• There are no competing policies that send this traffic out a WAN interface

If the traffic exits the wrong interface, you’ll still get broken return traffic even if NAT is correct.

✅ Step 3: Confirm Firewall Rules Allow It

Next, ensure the Pepwave firewall allows the traffic needed for the session.

At minimum, allow:

• Source: 10.250.32.240/28
• Destination: 10.120.2.10
• Protocols: ICMP (for testing), plus any required TCP/UDP

This is especially important if you’re accessing services like:

• SSH / RDP
• Modbus / SCADA
• Web interfaces
• Proprietary control software

Why SpeedFusion NAT Mode Didn’t Work Here

The customer originally tried SpeedFusion NAT mode, but noticed something surprising:

Turning on SpeedFusion NAT mode removed the “Remote IP Address” field needed to establish the SpeedFusion tunnel.

That behavior is expected.

Here’s why:

SpeedFusion NAT mode is primarily designed for situations like:

• Dial-out / client-to-hub connections
• Hub-and-spoke deployments
• “Client” devices that don’t have fixed peer definitions

It’s not the best fit for a site-to-site tunnel where both peers need static and clearly-defined settings.

So while SpeedFusion NAT mode is a real feature, it simply wasn’t the right tool for this scenario.

The Key Takeaway

When you’re connecting a remote device through SpeedFusion and:

• The device has a static IP
• The device’s default gateway can’t be changed
• The request arrives, but the response goes somewhere else

You don’t need to rebuild the VPN.

You need to control the return path, and the cleanest way is:

✅ Outbound Policy + NAT source translation + enforced tunnel routing

Quick Troubleshooting Checklist

If you’re implementing this and it still doesn’t work, check:

• ✅ Can the remote Pepwave see the FusionHub subnet in routing tables?
• ✅ Is your Outbound Policy rule above the default policies?
• ✅ Is the traffic being enforced into the SpeedFusion tunnel?
• ✅ Do firewall rules allow the subnet and protocols?
• ✅ Does the remote device have any local firewall blocking the traffic?
• ✅ Are you testing using ICMP first, then your actual application?

Final Thoughts from 5Gstore

This issue comes up a lot in industrial networks, controlled environments, and “fixed gateway” systems where endpoint configuration is locked down.

The good news is:
Pepwave routers give you the tools to solve it cleanly without needing changes to the remote endpoint.

If you run into a similar situation with:

• FusionHub in Azure/AWS
• SpeedFusion tunnels
• VLAN control networks
• One-way traffic or broken return paths

…this Outbound Policy NAT technique is one of the first solutions we recommend. Stuck with some technical issue? Reach out to 5Gstore for assistance.

FAQ: SpeedFusion + FusionHub Asymmetric Routing NAT Fix