Redistribute IKE2/IPSec Client Pool Address into OSPF

Hi All,

Is there a method in VyOS to redistribute IKE2/IPSec client pool address into OSPF?

Thanks!

Hi,

sure there is, just add the network into your area.

set protocols ospf area 0 network 10.0.0.0/22

The network statement might introduce individual /32 LSAs, which come and go on each client connect/disconnect.
Maybe better to add 10.0.0.0/22 as a blackhole route, and redistribute it. ( use distribute list to only advertise this network)

Hi All,

I tried several ways to include the route (for vpn client pool) into OSPF, results are shown below:
first, says the network condition under evaluated:
IKE2 VPN Client Pool: 172.16.200.0/24
Outside Interface: eth0
Outside IP Address: 1.2.3.4

  1. Direct use network statement include 172.16.200.0/24 into OSPF: failed.
    The route was not included in OSPF and not advise.

  2. Add static route use “set protocols static route 172.16.200.0/24 next-hop 1.2.3.4”: failed
    The route is not installed into VyOS routing table.

  3. Add static route use "set protocols static route 172.16.200.0/24 interface eth0: success
    static route is installed into VyOS routing table,
    “S>* 172.16.200.0/24 [1/0] is directly connected, eth0, weight 1, 00:00:24”
    so OSPF can redistributes the route to other OSPF hosts and it works in this particular case.

I want to check does VyOS provide function like “reverse route injection” for remote access vpn clients? Since I am not sure this action (force static route inject) is a correct way or not? And will it cause other side effects I still not discovered… :sweat_smile:

ps
What is the possible reason (or nature) to explains why #2 failed, but #3 success? :pray:

As next-hop for #2 isn’t directly connected, #2 doesn’t make it into the routing table, and there’s nothing to redistribute into OSPF.
Like a black-hole route, #3 does end up in route table, but next-hop-interface on eth interface is bad practice. It will start ARP-ing for destinations that aren’t there. That’s why I suggested black-hole route. As soon as VPN client is up you will end up with more specific routes, so don’t be afraid wanted traffic will be blackholed.

Something like reverse route injection only comes handy when you share client address space with another VPN server. If there’s only one , I’d prefer static advertising the entire pool. This way, vpn clients connecting/disconnecting won’t affect routes all over the entire network.

If connected VPN clients end up in connected routes, redistribute connected (filtered), might do the reverse route injection

Hi 16again,

Thanks for your response and advise.

I may understand your meaning, next-hop “1.2.3.4” is the ip address of eth0, it will not be considered as directly connected.

Use static route with outgoing interface is just a workaround on this issue, I also wonder is it a correct solution? But I cannot find an official way to inject vpn client route into routing table and then used by OSPF… :sweat_smile:

Since this workaround inject whole /24 prefix into routing table, so black-hole route cannot be used. Really, traffic to non-existed 172.16.200.0/24 host, may be accidentally send out via eth0, but it should be dropped by ISP router. I considered that internal hosts (from different networks) should not initiated connection to vpn client host address. So, accident traffic should be seldom happens…

I just hope to find out is there a method to inject these vpn client host routes (with /32 prefix) into routing table when they connects to VyOS? :pray:

A black-hole route also injects a /24 route in the routing table, so it can be used.

Look into routing table when vpn clients are connected. Depending on VPN type, some insert connected /32 routes for vpn clients, if so redistribute connected could do the trick.

Yes, I found this behavior (inject vpn clients as connected) in L2TP/IPsec, but nothing in IKE2/IPsec.

As I want the remote-access work together with DMVPN, L2TP/IPsec cannot co-exists. So, I tried IKE2/IPsec works together with DMVPN…