Multi SF tunnel traffic routing

[cdawson]

I’ve already seen this and this thread, of which the latter went nowhere.

I have a similar issue in that I’m trying to split traffic across one of three links at any given time depending on the source/destination. This is currently setup in a lab environment with a B310 and B1350 running 7.0.1FW.

It seems from a status page, things are setup the way I need them to be, though the 2nd and 3rd tunnels are showing inactive, similar to the second link above.

For the purposes of this thread, I’ll be concentrating on route 3 of my configuration. The two images below show the configuration on both sides. Though it shows route 1, you can assume that route 3 has the appropriate config in that it has WAN3 as the priority, and the other WAN interfaces in their respective priority.

The next two are the policies in question. For the sake of brevity, I only show the one side. It’s identical with obvious differences (source network).

And the below shows the status on both sides.

Any traffic initiated from a host on either side of the link goes down route 1, which tells me the policy isn’t actually doing anything. I’ve not configured the full policy that will exist yet, as this is the initial test for this setup.

I’ll open a case if I need to, but wanted to get a more conclusive thread going on this issue.

[Steve]

The 0.0.0.0/0 route looks strange to me. Is there any other devices in the same OSPF domain advertising this route?

Also, what is your test traffics Src and Dst IP address? Just to make sure it can be matched by the outbound policy.

I’d like to have a check with the Diagnostic Report if possible, you can download the Diag. Report following this guide:

Obtaining a Diagnostic Report from a Peplink Balance or Pepwave MAX Device

At times you may be requested by Support to provide a Diagnostic Report. Or, when opening a new ticket, you can also attach one together with descriptions and reproducibility of your issue. Please follow the steps below to obtain a Diagnostic Report from a Peplink or Pepwave device: Connect to the Web Admin Interface with a web browser. Go to Status > Device. Click the Download button next to the Diagnostic Report field. A prompt will appear for saving the file containing the Diagnosti…

Please create a support ticket here and attach the Diag. Report for both devices so we can further investigate for you.
https://contact.peplink.com/secure/create-support-ticket.html

[cdawson]

With regards to the default route, only one device is advertising it. In this case it’s the switch directly connected to the 1350.

Testing is to/from 192.168.1.138 and 172.16.30.10. Only ICMP at the moment as I’m literally just spinning up the environment and have not put up any tools on the hosts in question I’m using to test.

I’ve opened a ticket (777677) but would like to keep the discussion here as well given this would be the second instance of this issue I’ve seen in these forums and would like to have a conclusive answer as to the cause.

[Steve]

No problem, let’s continue the discussion here. Creating the ticket just to make sure you have a private way to send us the diagnostic report.

One question, is this how your Outbound Policy page looks like? All rules located below the “PepVPN Routes” label?

PepVPN sub-tunnel requires it’s related outbound policy rules located above the “PepVPN Routes” label in order to work correctly.

If this is the case, you probably hit an UI glitch in our previous firmware version. The bug will affect devices if the “HTTPS Persistent” rule is deleted.

Please get the latest firmware 7.0.2 on this page:

Peplink firmware and documentation

Firmware 7.0.2 has various improvements including the PepVPN status page for sub-tunnel, no more “Inactive” routes will be shown.

After upgrading, I’d suggest you to delete all the outbound policy rules and recreate them, then try again to test the routing behavior and see if it’s working as expected. Please keep us posted, thank you.

[cdawson]

Yes is the short answer. Though I showed the rule specifics, it does match what you show. The source is the actual source. The destination is the PepVPN Network matching any port/protocol. All above the default rule.

Let me upgrade to 7.0.2 and I’ll retest and report back.

[cdawson]

So it seems that perhaps not the FW update, but the placement of the rules changed the behavior.

I’m unable to place the rule below the PepVPN route section as originally had been. The rule previously automatically populated itself as above. However, this is the new behavior and the message given when I try to move it below the PepVPN section…

However, it seems that it works…I’ve decreased the failure detection to its default to minimize traffic across the links. All that’s going now are two pings in either direction at ~1400 bytes…

Is your suggestion that the policy should be below the PepVPN section? If so, that would seem to be not the case. Additionally, as suggested, the FW upgrade did not change the behavior of the status of the additional tunnels. As you can see, they still show as inactive. This is the same on both sides.

[Steve]

Thanks for the update, nice to hear the problem is solved.

Is your suggestion that the policy should be below the PepVPN section?

Nope, the rules should be above the PepVPN section, and our UI should have restriction on the rules to prevent user to drag them to the lower part. It’s a UI glitch that you previously placed those rules below the PepVPN section.

the FW upgrade did not change the behavior of the status

Oops, sorry for that, I have mixed up some recent changes and after checking the log the status enhancement doesn’t catch the 7.0.2 release time frame, but it absolutely will come in future release.

[cdawson]

One additional question. Will this configuration be able to be controlled/created via InControl? I don’t see any ability to create multiple tunnels from that dashboard.

Thanks!

[Steve]

Not for the moment, but we are definitely working on it for IC2, stay tuned.