Speedfusion / avoid tunnel on the way back to Gateway

Hi there,

the reason of this post is that I have an architecture that was working perfectly until yesterday, but somehow when trying to upgrade the kind of equipments it doesn’t work anymore.

A/ FORMER architecture (working):

A.1. Equipments:
One Balance210 in central site
Several MAX HD2 enabling nomad users to connect to Intranet from various remote locations
ALL firmware the latest (uploaded 2 weeks ago)

B/ Flow of data:

B.1. Standard connection, for users who need to connect directly to Intranet:
User ----> MAX HD2 —(Speedfusion/—> Central site’s router ----> FW --/Speedfusion)–> BALANCE 210 ----> Intranet servers

  • same path on the way back

B.2. Enhanced connection, for users who need privileged services to the Intranet:
Step 1: User ----> MAX HD2 —(Speedfusion±–> Central site’s router ----> FW --+Speedfusion)–> BALANCE 210
Step 2: _______________________________________________________ FW <-------------------- BALANCE 210
Step 3: _______________________________________________________ FW -------------------------------------------> Intranet servers

  • same path on the way back

So, with that type of connection, Balance210 breaks the Speedfusion tunnel on packets’ arrival, sends them UN-TUNNELED back to the interface they came from (WAN1, connected to FW DMZ socket) and the FW processes the traffic before sending it to its final destination (Intranet)

B.3. Protected Internet connection, when users want to benefit the encryption of Speedfusion to the Internet, when they are in a hotel room for example:
Step 1: User ----> MAX HD2 —(Speedfusion±–> Central site’s router ----> FW --+Speedfusion)–> BALANCE 210
Step 2: _______________________Internet <---- Central site’s router <---- FW <-------------------- BALANCE 210

  • same path on the way back

In this configuration, Balance210 breaks the tunnel and then sends back traffic UN-TUNNELED to the FW DMZ, last FW routes traffic to the Internet.

I’d like to stress the fact that I HAVE NO PROBLEM WITH THAT CONFIGURATION, that used to work perfectly with 2-year old HD2 and BALANCE210

C/ Elements of configuration

I’ll try here to explain briefly the configuration of devices:

  1. NO Drop-In
  2. Remote peer’s ID:
    2.1. On HD2: public IP address of the FW (that forwards to the Balance, based on ports)
    2.2. On Balance210: nothing
  3. “Send All Traffic to”:
    3.1. On HD2: (ID of the specific HD2’s Speedfusion tunnel)
    3.2. On Balance: no configuration - this seems pretty obvious to me that Balance keeps persistency of sessions coming from HD2 boxes and send packets back to the appropriate tunnel ; so a specific tunnel SHALL NOT be mentioned here
  4. Appropriate routes to the Intranet servers that are not directly seen by the Balance
  5. Routing Mode = NAT

D/NEW architecture (and problem!)

So the problem has started when I tried to replace HD2 with latest HD4, and Balance210 with latest Balance580 (latest firmware also, downloaded 2 days ago).

B.1. connection works, no problem.
BUT, as soon as, I try to have the Balance send back traffic UN-TUNNELED on the WAN1 interface, it’s very clear that actually the traffic coming from any HD4 on the Balance580 is TUNNELED again, back to the HD4. Indeed, when I log on a HD4, and traceroute to DNS, I have the Private IP address of the HD4 that keeps displaying every 2 increments.

I’d like to mention that the TUNNEL is properly established, only the traffic that should be routed OUTSIDE of the tunnel back from the balance580 is NOT, whereas it was with previous devices.

Also, maybe the most disturbing to me is that I have the symptom, not only when I replace the 2 ends of the tunnel, but also when I replace only 1 end of the tunnel (HD2 replaced by HD4, Balance210 by Balance 580).

Any idea to help? :slight_smile:



Hi, your layout is hard to visualise properly without a diagram showing the relationship between the core peplink device, firewall/internet gateway (or is that function performed by the core peplink device too?) and your intranet servers / network. It might be useful to chuck together a sketch if you have moment with some pseudo IP addressing on it.

A diagram showing how the core network is plugged together would really help I think.

Sure. Here it is.

I insist: this architecture DOES work with HD2 + Balance210.

But Purple and Green flows DO NOT work with HD4 + Balance580.

Thanks. This topology should indeed work fine. The only reason I can think of currently for the Balance at the core to route traffic back down the tunnel to the remote HD device is if the remote device is also advertising the same networks of the privileged network (as PePVPN take priority over all others), however this does not explain why the traffic destined for the internet from the remote HD device does not get there either.

I would focus on solving the internet access traffic first.

If you connect a laptop to the LAN of the core balance can you browse the web?
I assume that the FW has routes in it for the remote networks with a gateway set to the core balance WAN1? Can you ping the LAN interface of the remote HD device from the FW?
if you change the speedfusion profile settings at the core balance end to turn on NAT mode does routing to the internet then work?

Hi Martin,

thanks for your support. I definitely need more time to investigate: I’ll check about what you ask in your email, and also I’ll make tests with other configurations.

Interestingly, yesterday I’ve tried to connect from a Pepwave with previous Firmware (I didn’t uploaded the latest one), and now I go through the network to the server, but I have issues with the service (namely, the user is allowed to use the service but not with the appropriate privileges).

All of this seems very weird, that’s why I’ll take much more time to investigate, on the basis of the appropriate methodology. Among other things, I’ll sniff network traffic in different points of my architecture. I can do it in ‘working’ configuration and compare to ‘non-working’ configuration, so I guess I can find clues there.

Anyway I have devices working already. All of this only delays the integration of latest devices, and, as long as users are happy, everything is fine.

So, talk to you soon,