I have to configure OSPF neighbouship between my MLS (multilayer switch) and my VPN concentrator for redundancy reasons.
The issue is that the VPN concentrator’s public IP address is in the subnet of a secondary IP address of the MLS as illustrated in the following diagram :
From what I know, OSPF only sends hello packets from the primary IP address. Meaning that even if I declare the 10.10.20.0 network in OSPF and make the interface active, VPN won’t receive any OSPF hello packet.
What is the best way in that situation to form a neighbourship between these two devices?
There are a lot of different ways to do this, but here’s how I personally do it.
I use point to point /30’s on each physical interface between each router/device, and bring up OSPF across these links. Then I’ll put all of the actual subnets into a bundle interface, and advertise that bundle into OSPF.
For those who might come accross this same issue, here’s how I handled this situation : I changed the IP address of the VPN concentrator.
It now has an IP address of the “primary subnet” so they can communicate using OSPF.
I’m now struggling to find a way to advertise the “remote VPN subnets” using OSPF. Has anyone ever done that on a VPN concentrator? I tried using loopback interfaces to see if it would advertise the subnet but it appears that they are not used by OSPF (I can’t run any “ip ospf” / “ospf” commands on the loopback interfaces while it works on the regular gigabitethernet ones).
Well, that would definitely work but for numerous reasons that would be hard to change. My Vlan1 interface has ~20 secondary IP addresses and that would be much better if it could stay in this Vlan.
But thanks for your answer, I’ll keep it in mind if I can’t find better solutions.
Interesting. That’s what I do between my routers but for my VPN concentrators I felt like it would be a bit strange.
The users would directly connect to 10.10.20.2 (VPN public IP address) but the return traffic would be routed to the private /30 IP address of the concentrator. I’m not sure how the VPN concentrator would handle that.
Where is OSPF configured on your concentrator? Look up route redistribution, network statements, and prefix origination for your concentrator’s make and model. I’m sure it’s somewhere in the OSPF hierarchy.
In all fairness, I made a generalization that wasn’t specific to VPN concentrators. I don’t do much with VPNs on this scale, so may be worth verifying further.
The core network has been working perfectly for years. It has been configured this way many years ago (I wasn’t in this company at that time) and we’ve never had any issues with it.
We have a lot of users/departments so we use many private / public subnets. That’s why they decided to use secondary IP addresses instead of creating a way too many VLANs with similar security policies.
It’s maybe not the best way but definitely a working and stable one.
Well, I think it was configured this way a looong time ago where it had 2-3 secondary IP addresses at most. But as the use of the IT became more and more popular, they had to add new subnets one by one which led to where we are now.
No need to get defensive. Certainly you recognize placing all the subnets in the same vlan is not a best practice. Nor is mixing public address space and private address space in the same vlan. It will make any attempt at microsegmentation a nightmare chore one day. Using vlan1 is not best practice. It likely has worked for years, with minimal requirements other than just work. If you suddenly had requirements to add a range for dhcp and needed a helper you would run into issues, and as you are seeing now, adding dynamic routing presents issues. There is a reason industry best practices are considered best practices.
I am sorry, but the three little dots sounded a bit harsh considering I have nothing to do with the current core network configuration.
Thank you for your feedback and let me give you some elements to better understand our situation.
First of all we clearly don’t have all the subnets in the same vlan. These are just “USERS” subnets but besides that we have VLANs for IoT, WiFi, specific departments, VoIP, management, etc.
I am not sure to understand what the issue would be with dhcp. We use ip helper address and often add new dhcp range with no struggles.
But I 100% agree with you that it could and probably should be configured differently for part of it. Unfortunately as said in my previous message, the configuration has been done a long time ago when I wasn’t there. But we are in the process of changing some devices of the core network so it’ll be a good opportunity.
VPN concentrator’s public IP address is in the subnet of a secondary IP address
and
These are just “USERS” subnets
Those two statements are not congruent. Again, no need to be defensive. We ALL have inherited things like this and worse. We all have seen why not to do these things. No one is berating you. We are looking at the design and saying …hrmm.
