Outbound policy and schedules

Greetings.

I’m using a Balance One Core to administer a shipboard network. I’ve found a lot of useful information for restricting access to the expensive Sat link and have implemented them. Thanks for all the great guidance I’ve found on the board so far.

Now, I have some questions regarding priority of the various rules which I haven’t found elsewhere on the boards.

The general goal is this:

I have a shipboard network, entirely wired. I can administrate, but don’t really have the ability to change the existing network architecture (controlled by company policy).

We have 3 WAN sources.

WAN 1: Dockside Wifi AP, wired to the WAN 1 port (preferred for cost and speed, but only available at the dock)
WAN 2: Fleet Broadband connection (expensive, but available whenever the Wifi is not)
Mobile WAN: A verizon card that is used for the rare cases when the other two are not available.

I would like to allow the senior management and the email server access to FBB, and restrict access for the rest of the network to only WAN1 and Mobile. I first accomplished this using the Firewall Access rules and just manually enabling an “Allow All” rule while connected to Wifi. By learning more about the Outbound Policy I have been able to replace these rules with policy and all seems to be working well. However, there are still a couple of outstanding questions I’d like some guidance on if possible.

  1. Just by luck, the machines I want to give access to fall into a convenient CIDR range (10.x.x.9 - 10.x.x.15). I entered 10.x.x.9/29 in the Source IP Network setting. This is a basic question, but everywhere I look up CIDR it only talks about netmasking for purposes of subnetting. Will it work correctly like this, only allowing the IPs between 9 and 15 inclusive? Or would I be better served by just entering the IPs individually? It seems to be working fine from watching the Client List, but I’d like to get things to a set and forget status, so no one will have to mess with (and potentially break) the rules in the future.

  2. I would like to put one of these IPs onto a schedule, only allowing access to the FBB for a few hours a day to get naviagation updates. I did this before using firewall rules, and enabling an “Allow All” rule placed above the schedule while on WAN 1 (in port). But now with the policy, I’m not sure how to accomplish the same thing. My concern is that if I put the policy on a schedule, it will only allow access during those hours even when we are connected to WAN 1. I’ve thought perhaps I could do this with the Firewall Access rules, but I’m not sure how priority is determined given a conflict. For example, if the outbound policy is set to priority for the three connections, but the access rule says it is only allowed on a schedule, which will take precedence. In my testing so far, it seems like the outbound policy is winning.

My goal is to create a set of rules that will restrict this IP to a few hours while on WAN2 (FBB), but leave it open while on WAN1, without anyone needing to access the Balance Admin.

Can anyone offer suggestions on how to solve this issue, or some guidance on how the different rulesets interact with each other?

Thanks very much for all the responses I’ve already seen, this board has been extremely useful.

I do it this way a lot don’t see any issue with it at all.

I’ll have a bash at your ruleset when I’m back at my desk.

2 Likes

Point 1 should be working like you described.
Bear in mind that with an IP range of 10.0.0.9/29 that 10.0.0.15 becomes the broadcast address and is not useable.

You can assign 6 hosts:

2 Likes

You can do it all with outbound policies, a schedule and a cheeky fake VPN profile.

Lets list the logic

  1. All users can access the internet via cellular and dock wifi (wifi is a preference)
  2. Senior Management Team can use any internet connection (SMT devices are identified by subnet)
  3. One IP in that SMT subnet doesn’t have the same level of internet access.
  4. It can use Fleet Broadband if its the only connection available but only for a couple of hours a day.
  5. If there is WIFI this special device can access the internet (but not over cellular).
  6. If any device has use of multiple WANs keep the https traffic destined for the same server on the same WAN.

Whats useful about writing it out like that is that those become the outbound policies:

1. All users can access the internet via cellular and dock wifi (wifi is a preference)
I’m using a priority rule here so that the wifi connection is used if its available to save costs on the cellular link.

2. Senior Management Team can use any internet connection (SMT devices are identified by subnet)
We identify the source traffic from the Senior Mangement Team by subnet (hosts are 10.0.0.9 - 10.0.0.14). Have chosen to use fastest response time to give the SMY the best experience so we get a pay rise. In the real world I would likely treat the Fleet Broadband connection differently - perhaps have it only used by SMT if wifi and cellular fail.

3.One IP in that SMT subnet doesn’t have the same level of internet access.
So this is a trick. We need to ‘reset’ one IPs access (10.0.0.14 in the example). Best way to do this is have a rule that catches the requests from the IP and kills them - then add the rules above it to allow specific access.
Normally I do this by setting up a fake VPN profile that can never connect to anything and use the enforced rule to send all traffic via that fake VPN. One day Peplink will add a ‘drop traffic’ option so I don’t have to do this I’m sure.

4. It can use Fleet Broadband if its the only connection available but only for a couple of hours a day.
I have created a schedule and applied it to the traffic from the special host IP then forced that out via Fleet Broadband.

5. If there is WIFI this special device can access the internet.
If there is wifi the host will use that all the time without time limits.

6.If any device has use of multple WANs keep the https traffic destined for the same server on the same WAN.
This is the default https persistence rule.

3 Likes

Martin: Love this, thanks.

I should be able to make this work and you’ve given me some new tricks.

Just to try to improve my knowledge, do you have any insight to how the Outbound policy and the Firewall Access Control rules interact? In my experimenting it seems like they can both be active and have an effect, but I’m not sure how precedence is handled. I can see in your example that it can all be handled in the Policy section and this is likely preferred in most cases. I’m just trying to get my head around all of it.

Also, in my real world FBB is our only option 25 days out of the month as the cellular and Wifi coverage in the middle of the ocean is terrible :slight_smile:

Thanks for taking the time to help me understand. I knew this device could handle it if I could just understand the details.
REO

1 Like

Outbound policies and firewall rules can be combined to do some interesting things but they are for different purposes.

Outbound policies control the direction of flow of traffic LAN -> WAN.
Firewall Rules control the flow of traffic itself - either blocking or allowing communication LAN<>WAN.

Picture passport control at an airport. Each booth is a WAN connection.
Outbound policy is the person distributing traffic between the booths, and traffic flow direction is based on where they are coming from and where they need to go to.

The firewall is the officers in the booths who check the list to see if you are allowed to pass or not.
On outbound traffic the list (firewall rules) is the same for every booth. On inbound traffic each booth (WAN) can have separate lists.

Most of the time we will use outbound policies to manage traffic flows because in a multi-wan environment that is generally the most important piece of the puzzle. Firewall rules are then layered on top and become about securing certain LAN clients or blocking some traffic flows.

4 Likes