How can we configure Linux/strongswan to advertise remote VPN networks (when established) via RIP


We have a core router (with load balancer functionality) with two ethernet connections to two strongswan based VPN concentrators. The core router accepts RIP advertised routes.

How can we configure the Linux VPN concentrators to advertise established strongswan VPN's via RIP?

Example; the two strongswan VPN concentrators each have a VPN to the same remote network (e.g. When the VPN's to (one on each strongswan concentrator) are up, all is well. The core router randomly establishes sessions to the remote network via either one or the other.

However, when the VPN fails on only the second strongswan VPN concentrator, for example due to an ISP failure etc, only half of any new sessions will work as half get sent via the strongswan concentrator with an established VPN and the other half get sent via the strongswan concentrator which does not have a working VPN to the remote subnet.

The solution is surely to utilise dynamic routing. But how?

For example, as the VPN's on each strongswan concentrator establish they could then advertise that they each have a route to respectively.
Then if the VPN fails on one of the concentrators, it could stop advertising that it has a route to resulting in the core router removing the now invalid route and sending all traffic to via the remaining working concentrator.

When NETKEY based freeswan variations establish VPN's the routes are 'internal', how can I 'export' these VPN based routes such that RIP can then in turn advertise that the box can provide access to the remote VPN connected network? Additionally when the VPN goes down how can I then have RIP stop advertising the remote VPN network.

This is such an incredibly useful and obvious requirement there must be a way of achieving this?

Thank you in advance.
Monitor SupportSupport TeamAsked:
Who is Participating?
Interesting situation. What about the last resort interconnect between the two netgears for the VPN IPs?  
I think I see a problem with the above suggestion since there will be no specific route defined other than the interconnect that could potentially cause a routing loop between the two netgears. When the VPN is established, is there a VPN route added in the routing table?  Trying to see whether adding a static route with a metric of 999 that points to the interconnect that will have no impact as long as the VPN connection is present.  One the VPN connection drops, the interconnect path will route those packets to the other netgear.

RIP through the VPN is also not the most efficient use of network resources and you said that you do not have access to all the firewalls to even be able to setup Network advertising.

With the interconnect in place, you would not need to advertise the VPN IPs.
Searches on your issue keep pointing towards adding KLIPS or recompiling kernels to enable KLIPS.

Not familiar with the equipment you mentioned, but the VPN routing advertising  VPN has to be setup on the VPN server.

You might be able to if you have the option to define the route as relying on the VPN connection.
i.e. route VPN_connection_interface
If the VPN is up the route is added to the routing table.
When the VPN drops, the route is removed from the routing table.
Monitor SupportSupport TeamAuthor Commented:
Hello, thank you for your suggestion.

The Strongswan VPN concentrators are actually Netgear FVX538's (I am working with a Level 3 Netgear engineer and if we can work out a feasible solution they have said they may implement this in the FVX firmware).

Could you please clarify what you mean by 'route relaying' and how you do this?

It is my understanding that you cannot do a 'route add VPN_connection_interface' as there is no Virtual VPN interface!

Virtual VPN interfaces only existed in KLIPS Kernels and not NETKEY Kernels.
KLIPS was in 2.4.x kernels and NETKEY is used on 2.6.x kernels.
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

If dynamic routes based on virtual VPN interfaces is not an option, you would need to setup the VPN server to advertise through the VPN. OSPF is a better approach than RIP.
What is the remote VPN's capabilities? Can it handle VPN with routing ospf,RIP advertisement via the VPN?
Is the core router in front of the Netgears (internet facing) or is it behind the netgears?
The question deals with why would the netgears need to advertise to the core router what IPs they handle.

If you could lay out your network as a network diagram that may shed light on what you have.
Monitor SupportSupport TeamAuthor Commented:
That is a good idea. I will research to see if it is possible to set the remote FVX538 appliances to send dynamic routing advertisements about their locally attached networks via the VPN's and received by our core router in our central office.
However we control only about one third of the remote VPN firewalls and so cannot be a complete solution.

The core router is behind the FVX538's and each FVX538 has its own Internet connection.
Sadly the Netgear FVX538 appliances do not support OSPF, only RIP!
The core router is a Securepoint firewall.
I have attached the network layout. Don't worry about addressing (everything is uniquely addressable), the only thing we are concerned with is advertising the connected networks on the remote sites to the core router in our central office.

So in short; for a complete solution we need to get the local NETKEY based FVX538's to advertise their established VPN's.

So far when researching NETKEY specifically, I have found nothing!
I just don't understand why NETKEY removed anyway of exporting established VPN policies as routes to allow dynamic routing protocols to work!!!
Surely this is a HUGE deal and we can't be the only ones with this problem?!?!

PS. KLIPS is not an option, we are stuck with NETKEY.
Would it be possible to use the command 'ip xfrm state' in a script to create dummy routes, which can then in turn be advertised?

Thank you in advance.
I would have thought that having the two internet connections terminate on the router with the pair of netgears setup as a load-balancing/failover pair for the LAN a better approach.
With this setup you can weigh the routes to the remote VPN to go over one ISP while the Internet traffic goes over the other.

Now back to the existing setup and how to handle  dropped VPN and RIP advertisemant?
Not of any importance just curious: Which RIP are you using RIP1 or RIP2 Broadcast/multicast?

I think I have a solution to your predicament.
Each FVX is dead in the water if the external connection goes down since it is still advertising all routes. The possible cure is to interconnect the FVX's where another lower preference default gateway route is added to each with the Interconnect as the next hop.  Use the other WAN port to connect them together.
I.e. your current default route depends on the WAN1 interface being up? You would add a second entry for a default route but as a failover (lower preference (higher value for the metric) that depends on the interconnected interface (WAN2) being up)

Alternatively, since the FVX supports two WAN connections, do you have the option to connect both FVXs to both ISPs?
(Did not see an option in the FVX manual to have them setup as a failover-pair with a virtual inteface that is used as a LAN default gateway)

Monitor SupportSupport TeamAuthor Commented:
Hi Arnold,
I am familiar with the 'router on stick' style setups but actually there are very specific reasons why the netgears are on the outside, in particular each netgear actually has two Internet connections (1 for Internet and 1 for VPN's, providing 4 links in total). Additionally our core router is actually a router cluster with hot spare running VRRP etc. This is all so there is not a single point of failure anywhere in the whole design.

I have RIP1, RIP2B & RIP2M available to me on the FVX538's. Not OSPF or BGP sadly.

To give a bit more clarity to what I am trying to protect against, the FVX538's themselves don't fail as much as they used to back 'in the old days' on old firmware, but I really don't mind if they do because if the FVX538 did fail itself then it would stop advertising anything and the core router would stop sending anything toward that unit.

Additionally, there are actually about 100 remote networks on around 50 different remote sites all over the country! I was trying to keep the details simple with regards to solving the specific problem of 'dynamic routing based on established VPN's over NETKEY'.

The problematic issue we actually experience regularly is that VPN/s to a remote site on only one FVX might fail for whatever reason (IPSec issues, IKE, Re-keying, ISP to that region etc etc etc).
Whenever this happens we have to set a route on the core router (after people start complaining) to only route traffic to the remote site via the FVX that still has a working VPN.

Usually by the next day the FVX with the failed VPN will have resolved whatever was wrong and the routing can be correct to normal operation again.

Hence the specific need for dynamic routing advertisements based on established VPN's.
Monitor SupportSupport TeamAuthor Commented:
I really thought we might have cracked it with your last suggestion but sadly after testing, it would seem that routing takes precedence over VPN policy matching despite setting the route to the highest possible metric.

I set a route on the FVX with the highest possible metric to 'hop' to the other FVX. I was hoping that when the VPN is up, the policy would get matched first and the traffic would go down the tunnel, then when the VPN goes down the policy would not match and instead route via the other FVX.
However this was not the case, the routing table is matched first, so regardless of whether the VPN was up or not, the traffic was always going via the other FVX!

When the VPN is established, no route is added to the routing table as NETKEY is used on the FVX538 units which performs traffic policy matching, instead of creating a virtual interface and routing entires as is the case with KLIPS. Annoyingly KLIPS is not an option though.

This problem is really frustrating! NETKEY was supposed to supersede KLIPS, so I just don't understand the decision to effectively abandon any form of dynamic routing support :(
Do you have an option to contact netgear and see what options they offer?

An even worse alternative could be to setup a VPN between the two FVX using the interconnect where the VPN LANs are the last in the VPN policy.
I.e. if the VPN is not present the packet check will fall through to the next one until it hits the interconnected VPN.
Monitor SupportSupport TeamAuthor Commented:
Hi, yes I have been talking to Netgear about this.
If I was able to figure out a simple way of doing it then Netgear said they may possibly implement it (get the user to do all the work!).

I have just emailed them in relation to this and asked about programming a backup route instead as an alternative to VPN route advertisements.

It may take a couple of days before I get a response but I will post here as soon as I have some news.
Thanks again for all your help on this. We will get this one cracked.
Monitor SupportSupport TeamAuthor Commented:
Netgear have come back to us and confirmed the issue. The support engineer has kindly said he will talk to engineering at their next meeting tomorrow and bring up both subjects, of advertising VPN's via RIP, and programming backup routes that will be used if the VPN is down.

I will let you know we we get a response.
Monitor SupportSupport TeamAuthor Commented:
Engineering did not throw the request out, and have taken it on board to see if they can program a solution to the problem.
This will obviously take a couple of months so I will close this question.
However your idea to program alternative routes was in my view a complete solution with regards to my initial problem.
Thank you very much for all your help.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.