I have a MAX BR1 MK3 running FW 8.1.0. Behind NAT
There is a PepVPN tunnel built automatically (using IC2) between it and a Fusionhub (acting as a hub in a star profile) which is connected and green and good.
I want to add a firewall rule set to kill the active tunnel and block future tunnels (pushed by IC2) from being established.
Basically I want local device level control over whether IC2 pushed profiles can be built.
I have added Local Service Firewall Rules to block the inbound traffic:
Would you able to provide more info for what you want to achieve ? What you want to do here, seen weird to me. If you want to bring down a SpeedFusion Tunnel, suppose you should disable the profile instead ?
Why you need to do this ? If you decided PepVPN profile to be manage by IC2 ? Why you still want the device not to follow the profile push by IC2 ? This is somethings weird to me.
The company that hosts the fusionhubs and configures the dynamic tagged IC2 VPN profiles (The IaaS provider) is different to the company that adds tags to the end devices in IC2 to create the VPNS (MSP), and its another company (the end user) that gets the benefit of the services provided over the VPN tunnel.
Think of it as the end user needing a local safety switch or tap, because everything upstream is owned and managed by someone else. They want to be able to call the MSP tell them they need them, then go and flip the switch to allow the MSP to access their equipment.
Then when they are done, they want to flip the switch again to block access.
For Outbound firewall rules won’t able to block the device level outbound traffics. It’s same like IC2 , NTP, DNS traffics and those are necessary traffics for the device that we have no way to block it.
For Local Service Firewall Rules, it’s more like blocking the inbound traffics. For your case, i believe the BR1 is the client device that initiate the handshaking & data connection. So it won’t be block by the rules.
Don’t think we have feature that can help your requirement now and let me move this post under feature request to allow Engineering team to consider the feasibility.
Personal thinking , i don’t like this feature because suppose if you have the profile defined, the SpeedFusion Connection should allow to connect without a control. This feature may good for the expert user like @MartinLangmaid Guru but may be a pain point for others that may simply kill all the SpeedFusion connection by accidentally added a unwanted rules .
Another option could be that once the SpeedFusion settings are pushed out from IC2, use the “InControl Options” (found under the group settings) to restrict the IC2 changes allowed, allowing the visibility of the device, just not the control.
How about locally changing the Handshake port ? That should break all of the existing tunnels, without changing them. I’m not sure if this would ic2 device details page may override this.
Add a local dns entry and have the ic2 profile use the dns entry instead of the ip address. Then you can block the change the local dns entry when you want to disconnect it.
Put another device that you control in front of the peplink to control it connecting in or out.
Perhaps instead of being concerned about the tunnel itself use firewall rules or OBP to block the traffic that normally goes out the tunnel and/or direct to another tunnel.
While you are in “MSP access mode” you could disable ic2 config (locally on device), do your changes , allow msp access, and then revert the config manually or from a backup when completed.
This would truly allow you to disable the tunnels, prevent new ones from being pushed and temporarily allow access.
If any of these are acceptable then setup some device api scripts to easily turn it off or on.
system → incontrol2 → Controller
Either Disable , or try “Restricted to Status Reporting Only” (have not tried that one)
