Dear Sirs,
How can i prevent a LAN subnet to be advertised on the PepVPN?
On the backbone area ( 0.0.0.0 ) i’ve enabled the OSPF only on Default LAN subnet ( untagged VLAN) but the tagged VLAN subnet is advertised on the routing process as well.
This is not suppose to work like it is, there are any fix to change this behavior on routing?
Waiting your reply,
Best regards,
Adelio Moreira
Hi,
All LAN subnets will be advertise to PepVPN peer. This is the design and expected behavior for PepVPN. You can’t prevent this at the moment. Anyway I understand where you come from. We will look into this.
Possible to enable NAT mode for PepVPN? Will this meet your requirement?
NAT mode for PepVPN - By selecting this option, the remote unit VPN will be assigned with an IP address from the local DHCP server. All the remote side traffic via this VPN will go through Network Address Translation (NAT) using the assigned IP address.
Hi,
The NAT mode as it’s design is not a solution or a workaround to this routing issue on my enviroment.
When will PepLink do fix for this issue on LAN side, because it’s not making sence since i don’t enable the OSPF on this subnet it’s suppose it will not be advertised for anywhere!
Waiting your reply,
Best regards,
Adelio Moreira
Hi,
PepVPN is using OSPF to advertise all LAN segments to remote peer by default.
If you enable Untagged Vlan in OSPF as below, it will listen and deliver OSPF packets with OSPF neighbor at Untagged Vlan side. However Vlan 2 will not listen or deliver any OSPF packets.
We have no ETA on “Selected Vlan to be advertise to remote PepVPN peer”. I will move your post to feature request.
Thank you.
Any news regarding this feature request?
Hi adelini,
This is in our roap map. Stay tuned.
+1 from Onwave as well!
This is an interesting topic, and a very useful thing to be able to have control over. It should be easy because OSPF has supported these capabilities for decades. Can we have and OSPF that behaves by default however you think best, but also offers us the option to take some more control?
Network summarization, (without having to use NAT)
Selective subnet advertisement.
The ability to make an interface passive.
The ability to control which interfaces are included in the OSPF process.
Thanks,
Dana
+1 from me as well. I’m all for all routes being advertised by default (keeping PepVPN’s inherent setup simplicity), but sometimes a remote route is not valid for certain local hosts. The ability to enable/disable remote routes would save me a ton of workaround effort. Thanks!
Hello, will this come in 6.2.x? Or will it be 6.3?
Thank you,
Dana
+1 - is there any update on this feature?
Hello,
This feature will be included in the upcoming 6.3.2 firmware which we currently have a RC build available.
You may obtain full release notes here (See 5. Feature Improvements for SF route advertisement)
Well, rats. I need this to be separate on a per-PepVPN basis. Thanks anyway!
I would like to revist this topic. We are an MSP and it would be nice to select which VLANs are advertised between speedfusion peers.
Client A might have 4 speedfusion VPNs (10.101.1.0 (in datacenter), 10.101.2.0 (site a), 10.101.3.0 (site b), 10.101.4.0 (site c).
it would be nice if I could isolate them to their IPs and no other IPs. Client A only sees client A IPs and client B only sees client B IPs.
I know this can be accomplished with individual fusionfubs but that adds overhead and I already have a nice Peplink router on my edge so I feel that would be better to use.
Hi Peter, we have solved this issue “partialy” by using the internal firewall, where some segments might not talk to others,
So basically you say allow 10.101.1.0 to talk to 10.101.2.0, or you could even state a /28 so you “segment” who can talk to who. I know this is not ideal, and for a very large MSP can be challenging to properly achieve, but it is working for us so far.
that is what we currently do but all of the remote subnets are advertised so somebody snooping around the speed fusion status would be able to see all of the remote networks even though the firewall policies only allow their subnet
That is correct…
This should be very easy. Just like IPSec, you should be able to configure the subnets that are advertised over the tunnel to the remote peer. Peplink already does this with IPSec.
So Peter, basically your request is kind of VRF on FusionHub (available in firmware 8), to isolate each client’s networks from each other? I don’t think manipulating route information will work because route filtering will never allow you to have route conflicts, if you go for VRF, you can allow client A and client B to use the same subnet and no conflict at all.
But in anyway, this is not comparable to IPsec, IPsec is using static routing information, but PepVPN is using OSPF for automatic route exchange, technically all PepVPN peers meshed together are within the same OSPF domain (unless using VRF on FusionHub), filtering some of the routes from some of the peers is not that kind of easy as IPsec does.
