1

I have a fairly simple network setup as seen in the attached image. The network is spread across two more or less similar data centers which are connected via a static OpenVPN tunnel. Both the VPN servers and the gateways are running BIRD OSPF, configured as the backbone area 0.

Each "client" consists of an OpenVPN client and a number of hosts behind it that all belong to a common /64 block. The OpenVPN client opens two connections (primary and backup) to one of the DCs. What I need is that all the client hosts can talk to any application server in either DC and vice versa, but no "client" should have any knowledge of any other "clients". My initial though was to put OSPF running also on the OpenVPN clients and have them advertise their /64 blocks that way, but that would mean all the clients would see all the other clients.

What I want to do is prevent the "inter-client" communications preferably at the routing level, both from a security standpoint and also to prevent any excess network traffic since some of the clients may be behind very slow links. So essentially the clients only see the DC networks and the DCs can see all of the client networks. Can this somehow be done with BIRD's filtering capabilities (and if so, how?), or should I perhaps be looking into some other routing protocols?

Note: I asked this question on Network Engineering where they directed me to ask this question here, and also told me to look into BGP as a possible solution. However I have zero experience with BGP and briefly looking into it, it seems rather complex to setup.

Teemu Karimerto
  • 111
  • 1
  • If you simply want to prevent communications between the clients, then you can use access lists to block the communications. That really has nothing to do with a routing protocol. The clients could still know the routes to the other clients, but be unable to communicate because the ACL will block the traffic. If you really want to block the prefix advertisement, then you are looking at separate ASes, and BGP is the tool designed for that, but it will not block communications, only route advertisement. – Ron Maupin May 27 '18 at 20:09
  • There will be a firewall/iptables rules for blocking any unwanted traffic, but I would also like to keep any unnecessary routes from being advertised to the other clients as it means unnecessary network traffic. – Teemu Karimerto May 27 '18 at 21:06
  • "_I would also like to keep any unnecessary routes from being advertised to the other clients as it means unnecessary network traffic._" Barely. You would probably not be able to notice it. What you want is BGP. Set up each client with a different AS, then only advertise what you want to advertise between the ASes. Also, as I suggested before, a statically configured default route will eliminate all routing protocol traffic, not just the few packets for the routes you do not want to advertise. – Ron Maupin May 27 '18 at 21:09
  • What you're looking for is BIRD import filter for OSPF on clients, where you can match routes for import based on subnet or LSA type (that's what I'd do given your limitations). Please note, that OSPF process itself would still carry on all the prefixes though, as it needs to do so in order to converge. – Peter Zhabin May 27 '18 at 22:22
  • @PeterZhabin, that doesn't actually solve the, "_I would also like to keep any unnecessary routes from being advertised to the other clients as it means unnecessary network traffic._" The routes will still need to be propagated for OSPF because OSPF needs each router in an area to have an identical understanding of the area. It would prevent the routes from being installed in the routing table (useless if the traffic is blocked, anyway), but it doesn't prevent the routing update traffic (minimal as it is). – Ron Maupin May 27 '18 at 23:35
  • From what I gathered, BGP uses TCP to talk to its peers, right? And I'd also need to know the peer addresses as well as the AS numbers in advance? That sounds like quite a few (pretty much idle) connections from the clients to the VPN server(s), and quite a lot of configurations to maintain. It also doesn't sound very dynamic given that the clients can connect to either DC. So I think the import filters are the way to go here? – Teemu Karimerto May 28 '18 at 04:38
  • "_So I think the import filters are the way to go here?_" If you simply want to prevent communication, then ACLs are the way to go. If you want to prevent route updates being sent, then the filters will not do that. The route updates will still be sent (every OSPF route _must_ have the full area topology), they just will not be installed in the routing table, and that really does nothing for anything about which you are asking. I think you are trying to hammer a nail with a screw. BGP filter will actually prevent routes from being sent, but OSPF simply cannot. – Ron Maupin May 28 '18 at 07:05
  • "_BGP uses TCP to talk to its peers, right?_" Yes, BGP uses standard TCP to communicate with its peers. OSPF has its own transport protocol (all the routing protocols use some transport protocol, for example, RIP uses UDP). "_That sounds like quite a few (pretty much idle) connections from the clients to the VPN server(s)_" OSPF will be no different, it just uses a different transport protocol. "_quite a lot of configurations to maintain._" That depends. You want some low-level filtering, and either BGP or OSPF will need some serious maintenance for that. – Ron Maupin May 28 '18 at 07:09
  • "_It also doesn't sound very dynamic given that the clients can connect to either DC._" You simply don't understand it. BGP is very dynamic. The entire public Internet is based on BGP, and it dynamically reroutes traffic. Remember that the Internet started as a DoD project to automatically route around damage in the event of nuclear war. I really think that someone with your level of understanding should hire an expert to guide you in something so vital to your company. – Ron Maupin May 28 '18 at 07:12
  • Unless you keep updating the OSPF filters, as you add other clients, it will automatically send updates and install the new routes in the routing table. BGP is easy to configure to send only specific prefixes, and not any others, even when new routes are added. You can easily have much more (ignored, thus useless) routing traffic with OSPF than with BGP. – Ron Maupin May 28 '18 at 07:15
  • Think of it this way, OSPF is going to send every rout in the area to every router. Period. You may filter the routes from RIB to FIB, but they are still going to be sent everywhere in the area. With BGP, you can configure BGP to never send the prefixes between ASes in the first place, so one AS only knows what the other AS tells it (this sounds like what you want), and you do not need to filer on every client router the way you would need to for OSPF. – Ron Maupin May 28 '18 at 07:24
  • Apologies, I am indeed not very experienced with advanced networking issues like this. My concern with BGP not being "dynamic" was that since the clients can connect to either DC, I'd need to update the configurations everywhere any time a new client is created. However as you pointed out, I would anyways need to update the OSPF filters so this is really a moot point :) I do need to automate the whole setup in any case, so it does sound like BGP is then the way to go. – Teemu Karimerto May 28 '18 at 07:59
  • One more option might be leveraging the OpenVPN scripts and adding/removing the routes as clients come and go. That way I could theoretically manage the whole system without having any kind of routing protocol installed on the VPN client machines. Though with two tunnels I guess that is just asking for problems. – Teemu Karimerto May 28 '18 at 08:05
  • @TeemuKarimerto That'll be the best way IMO. If you run BIRD on your OpenVPN server systems, you can even script this route injection into your main OSPF process. – Peter Zhabin May 28 '18 at 09:28
  • @PeterZhabin How would that work though? On the server side I can simply add the route(s) whenever a primary or a backup VPN tunnel is opened and OSPF would pick those up and redistribute to the DCs. But what about the client side, i.e. the return path(s)? Any ideas how I could handle that? Keep two routes to the VPN server and let kernel pick which it uses? – Teemu Karimerto May 28 '18 at 10:19
  • It isn't clear how you handle these two connections, is there a common network DC-side behind them and they just connect to it via VPN servers at different DCs? Is one primary and other is a backup? I'd rather install routes to DCs when OpenVPN is getting up, and tune metrics if needed. – Peter Zhabin May 28 '18 at 10:42
  • As you can see in the image, I have two pretty much identical DCs and the client connects both primary and backup tunnels to one or the other (but both to the same one). The DCs handle routing using OSPF between them. You are right, some kind of dynamic metric tuning (based on ping/bandwidth) on the client side is probably best. – Teemu Karimerto May 28 '18 at 11:21

0 Answers0