I’ve noticed that it appears by design on the BR1 devices you cannot force local breakout when an SF tunnel is running and the “send all traffic to hub” rule is turned on.
So I have multiple devices (BR1, transits and HD4’s) in use, all of them have the same local rulebase for outbound policy for guest wifi to be on a separate VLAN (inter VLAN routing turned off) and using a separate SSID etc, in turn it has an “enforced” outbound policy to send this client traffic for guest to connections in priority order (ie: local breakout and not down the SF tunnel)
This works fine on the transit and HD4 but not on the BR1, once an SF tunnel is enabled on the BR1 the outbound policy is greyed out and according to support appears to be by design so you cannot edit it and neither does the existing rule have and effect.
It would be ideal if this could work the same on the BR1 as it does on the transit and HD4 models so local breakout for guest but closed tunnel for corporate is possible.
possibly not making myself clear, so I know you can already add but when you then run a speedfusion tunnel on the BR1 the add/edit bit disappears you cannot change it, nor does it have any effect, so an existing rule added as an outbound policy simply gets ignored on the BR1 (but not on other higher range models) I did have a ticket with support on this and the jist of the emails was that this was by design on the BR1 hence asking for it as a feature request.
My last email back from support read “Believe you are referring to those Outbound Policies were “grey out” and can’t make any changes. Do correct me if I am wrong. If my assumption is correct, then this is an expected behaviour. We don’t expect any SpeedFusion related changes on the box since it was managed by InControl2” So I understand this but its not the case on the transit or HD4 models, we’re working on a design which needs guest local breakout as well as corp traffic down speedfusion, this is fine on the HD4 and transit as they honour the local outbound policy rules set, but this isn’t the case on the BR1, on the project we are working on there are expected to be many BR1’s.
BR1 is a special case once it was managed by InControl2. This is because BR1 has one active WAN only at a time. Therefore, Outbound Policy is not needed since all internet traffic will be routed via the active WAN.
Believe you have enabled “Send All Traffic” as below. You may consider disabling this option if local breakout is needed.
Thanks TK, yes thats correct I am using that rule on the SF end config “send all traffic” so on the BR1 it sounds like I’m better off not using that for BR1 SF configs (only HD4/transit) then on the BR1 locally have fixed outbound policy rules to send corp VLAN into the SF tunnel and guest wifi VLAN directly out the WAN interface (local breakout)
So the same end result just done in a different way than the HD4 and Transit, is that right?
Once you disabled “Send All Traffic” on InControl2, traffic destinated to the central site will be routed through PepVPN tunnel. Others traffic will be local breakout. These are automated without defining any Outbound Policy. Below is an example after “Send All Traffic” was disabled on InControl2:-
Central site’s LAN = 192.168.1.0/24
BR1’s LAN = 192.168.2.0/24
User from 192.168.2.0/24 talks to 192.168.1.0/24. Traffic will be routed to PepVPN tunnel.
User from 192.168.2.0/24 browses Peplink website. Traffic will be routed to BR1’s active WAN.
May I know what Outbound Policy you want to define again since all traffic will be local breakout automatically (besides traffic to central site)?
I think I understand now, so on the BR1 I will have to not use “send all traffic” on the SF rule but use local rules on the BR1 itself.
Basically we have corp traffic eg: 10.100.20.0/24 and this must all go via the SF tunnel, no local breakout so the corp internet traffic is forced back to their central gateway (which has policy filtering etc)
However there are other local traffic types which should breakout locally, one is IC2 management itself, so I think I will have to set the default LAN subnet to use this and have a rule to breakout locally, then have another guest subnet say 192.168.1.0/24 for local breakout as well, this way the corp traffic is still forced to go via the SF tunnel (all of it not just specific routes)
What I’ve done so far on the other units (transit and HD4’s) is set the send all traffic rule on the SF tunnel but then have put an exception rule to force the corp (10.100.20.0/24) and IC2 traffic (by a fixed rule to destination using our public IC2 instance address) to breakout locally in a fixed order, so basically the reverse of how I think I need to set it up on the BR1 unit.
I’ll setup a test unit with how you’ve described it above.
As soon as I have a SF tunnel running the local outbound custom rules are greyed out, if I create them before the SF tunnel that works however I am then unable to force the corp VLAN subnet into the SF tunnel (as it doesnt exist yet) I think this was why I originally wanted to set it up the other way (ie: have “send all traffic” on the SF tunnel and then a specific forced local breakout rules for IC2 traffic and also the guest VLAN as a source, all corp still goes via the SF tunnel)
is this likely to change on the BR1 firmware, where editing of local outbound policy is possible when an SF tunnel is running?
Once BR1’s PepVPN was managed by InControl2 with Send All Traffic enabled, all outgoing traffic from LAN will be send over to central site via PepVPN tunnel. So Outbound Policy is not applicable in this situation. Therefore, it was greyed out. HD4 has different situation since it was supporting Expert Mode. I believe you have enabled Expert Mode in your HD4.
Once BR1’s PepVPN was managed by InControl2 without Send All Traffic enabled, all outgoing traffic from LAN to central site (10.100.20.0/24) will be send via PepVPN tunnel. Others traffic (not 10.100.20.0/24) will be local breakout. This was automated without any outbound policy. In fact, this is your requirement. InControl2’s IP definitely is not 10.100.20.0/24, so traffic destined to InControl2 will be local breakout.
Conclusion, you no need to define any outbound policy (leave it blank) once BR1 was managed by InControl2 without Send All Traffic enabled. All traffic (beside destination of 10.100.20.0/24) will be local breakout.
Perhaps I am misunderstanding something, but this doesn’t work either as once the SF tunnel is applied (without “send all traffic” enabled) the outbound policy (I setup a dummy one) is grayed out, I can see it but am unable to make any changes to it nor add any others, so I cannot edit it and create an “enforced” rule to send corp traffic into the SF tunnel (and have everything else breakout locally)
You are right, am using expert mode to do this on all units, I just cant seem to control the routing on the BR1 as I can on the HD4 and transit units?
Hi Chris, as TK mentioned there is no need to create an outbound rule for this. When the SF tunnel gets established, both sides dynamically learn and update the routing tables. The BR1 will automatically send all corporate traffic through the BR1 without the need of any outbound rule, this is the default behavior.
All traffic that is not destined for the corporate side will automatically breakout locally and will not go through the SF tunnel. Again, this is the default behavior and no outbound rule is needed here either.
Thanks Tim, so in order for this to work it sounds like I need to create routing rules on the head end balance instead so corp traffic comes back through the tunnel but all else breaks out locally?
Will it keep all VLAN’s separate on the BR1 locally, we dont want guest being able to access the corp VLAN locally or be able to go across the SF tunnel to the head end, same for IC2 management traffic that needs to breakout locally.
Am just getting my head around this on the BR1 as it works differently to the HD4 and transit models and how we have them setup with this client.
Hi Chris, no routing rules should be needed at the head end Balance side as all traffic coming into it will by default go back through the tunnel. Just disable Inter-VLAN routing on the BR1 and the guest traffic cannot touch the corporate traffic.
Actually, you wouldn’t need to use any custom rules on the HD4’s or Transit’s either.
I can create a "feature request’ if needed as it sounds like this isn’t possible…but if you don’t create the tunnels via InControl2 you can manage the traffic with Outbound Policies. This is important for us as we have a 3rd Party IPSec tunnel off the Balance but they only allow certain application specific ports through that tunnel. They also run a web app in that same IP range that’s in the tunnel but ports 80/443 aren’t available inside that IPSec tunnel. So what we had been doing was just creating an Outbound Policy to force specific IP’s (devices) to go through the PepVPN/SF tunnel but other Ip’s where excluded. This allowed us to access the 3rd parties website when at the remote Max connected site (outside the SF tunnel) but the devices still communicated through SF tunnel. Configuring our tunnels through InControl2 made managing the endpoints (about 15 Max BR1’s that just keeps growing) much easier so we hate to lose this control over the Outbound Policy.
Agreed, I can easily use static setup fusion tunnels but not using incontrol on an estate which could be 800+ routers in time is not really managable hence we want to have IC2 manage tunnels rather than manually build to retain the local outbound policy, in short we just want it to work as it does on HD2, HD4, Max transit series, so only one connection live at a time of course as this is a BR1 but be able to have an IC2 tunnel created and still retain local breakout (or split tunneling if you prefer) and not have the IC2 tunnel override it, as on the higher models you can have local policies above the speedfusion rules so they take precedence.
We haven’t had a PepLink Team response on this in almost a month so I just went ahead and created a new thread in the Feature Requests forum. I think we just have some scenarios that need this that weren’t considered. I’m hoping it’s an easy fix since it’s possible as long as you manually configure the PepVPN/SF. It’s only an issue if you create your VPN with InControl2.
Beyond my edge case of needing some devices to go through PepVPN and some go out the WAN on the BR1, it turns out I have a much more common scenario where this is an issue. We have a 3rd party IPSec tunnel connecting to the head Balance unit. The 3rd party can get to devices ‘below’ the Max BR1. However, when devices below the BR1 connect to IP’s on that 3rd party network traffic does not go through the PepVPN as expected. It seems to me that that IPSec tunnel network on the Balance isn’t being advertised to the PepVPN tunnel. On the Max BR1, if I go to Status and SpeedFusion I don’t see those IPSec tunnel networks in the routes there.
I found that on one Max BR1 that was part of the PepVPN when we manually managed it we had an Custom Outbound Policy defined. Then we added all the BR1’s to be InControl2 managed. On that one unit, the Custom Outbound Policy is still there and devices below that unit work fine. But on the new ones added, we can’t add Outbound Policies so we can’t direct that traffic to the IPSec network up through the PepVPN.
TK, that is great news especially for those Edge cases where we need that flexibility. I do however like the default of it just working by updating the routes so we don’t have to manually add policies to every br1. I think this is a separate issue, but shouldn’t pepvpn advertise the IPSec VPN networks on the Balance to the br1’s automatically. Is that a bug? Should I start a new thread or open a ticket?
