Please add outbound policy support on FusionHub. That would be very useful with multiple sub tunnels enabled on the VPN nodes connected to the FH. With FH acting as a hub for several nodes, we should be able to control the outbound traffic coming trough the central site.
Example
Say we have two devices connected to the FusionHub: HD4 and UBR. HD4 has a single VPN tunnel established to the FH, while UBR has 4 sub tunnels. HD4 client streams a video to the PC behind UBR. I need FH to be able to steer the traffic coming from HD4 to a specific VPN sub tunnel between UBR and FH.
Simple diagram:
Camera >>>Wi-Fi>>> HD4 >>>VPN>>> FusionHub>>>VPN with 4 subtunnels>>> UBR
Currently, we can’t take advantage of the sub tunnels on the nodes if we can’t steer the traffic on FusionHub.
Hi @JakubN, what is the traffic type of your data? As long as it is a bidirectional stream (e.g. TCP, or some UDP streams that have control packets), this is already supported without the need of Outbound Policy on FusionHub.
FusionHub is designed to route traffics according to remote PepVPN peer’s choice, any packets in “outgoing” direction will be routed to where the “incoming” packets come from.
Say if the PC is initiating the connection, as UBR (with outbound policy) routed the packets via sub-tunnel 2 to the FusionHub, when Camera replies back, the reply packet will be forwarded to sub-tunnel 2 by FusionHub without the need of Outbound Policy, because the last incoming packet comes from sub-tunnel 2.
So in another case, if the first packet comes from another direction, from Camera to PC, the first packet sending to PC will go to sub-tunnel 1 (the default tunnel), but when the PC send out reply packets in the same session, UBR will route the reply packet to sub-tunnel 2 based on Outbound Policy, and FusionHub will update the record, any further packets coming from the Camera to PC later on, will be forwarded to sub-tunnel 2. As a result, only those packets before the first reply from PC will be sent via sub-tunnel 1, all packets after the reply will be using sub-tunnel 2 as defined in UBR’s Outbound Policy.
thanks for explaining that. If that’s the case, than it’s a big relief - less outbound policies to configure
We’ll do some testing to check if there is bidirectional connection between our streaming device and the receiving one. I’ll come back once we are sure that it works as expected.
I actually have a use case as well… I have a fusionhub that has a default route coming in over OSPF, but I want the appliance to check in to Incontrol via its local link, not over the tunnel.
