IPSec static routing

RouterOS General
1

Hi all!

Need a help to setup static route via IPSec VPN. Have the following configuration:

router - 192.168.5.105

other_subnet - 192.168.6.0/24

from router I can ping other_subnet. Static route was added like that:

/ip route add dst-address=192.168.6.0/24 gateway=192.168.5.115

Static route also was pushed to VPN client, due to split-include option (see below)

$ netstat -rn
...
192.168.5          192.168.77.253     UGSc            1        2  ipsec0
192.168.6          192.168.77.253     UGSc            0        3  ipsec0
...

From VPN client I can ping 192.168.5.0/24, but can’t ping 192.168.6.0/24.

VPN setup:

/ip pool add name=rw-pool ranges=192.168.77.2-192.168.77.254
/ip ipsec proposal add name=rw-proposal pfs-group=none

/ip ipsec mode-conf add name=rw-conf system-dns=no static-dns=192.168.5.104 address-pool=rw-pool split-include=192.168.5.0/24,192.168.6.0/24
/ip ipsec policy group add name=rw-policies
/ip ipsec policy add template=yes src-address=192.168.5.0/24 dst-address=192.168.77.0/24 group=rw-policies proposal=rw-proposal

That’s almost all configuration. No firewall, etc…

What should I add to make route happen?

Thanks,

2

Without testing it practically, I’d say you need another policy template to match the one the client asks for based on the mode-config it gets:

/ip ipsec policy add template=yes src-address=192.168.6.0/24 dst-address=192.168.77.0/24 group=rw-policies proposal=rw-proposal

3

Yeah, I’ve tried that also, but did’t work :slight_smile: even tried to move that rule up. I guess I’m missing something here, like correct configuring routing while VPN

4

In that case:

  • keep that template policy in the configuration
  • /system logging add topics=ipsec,!packet (if not done yet)
  • disconnect the client
  • /log print follow-only file=ipsec-start where topics~“ipsec”
  • let the client connect
  • break the /log print…
  • /ip ipsec export hide-sensitive file=ipsec-cfg
  • /ip ipsec policy print file=ipsec-policies
  • download the files, anonymize the public addresses in them if any, and post them here
5

Here you go:
ipsec-cfg.rsc (797 Bytes)
ipsec-policies.txt (816 Bytes)
ipsec-start.txt (42.5 KB)

6

Hm, the log says one interesting thing which I cannot decipher:

14:59:47 ipsec TSi in tunnel mode replaced with config address: 192.168.77.0/24 
14:59:47 ipsec TSr in tunnel mode replaced with split subnet: 192.168.5.0/24 
14:59:47 ipsec canditate selectors: 192.168.5.0/24 <=> 192.168.77.253

So either use of mode-config causes RouterOS to ignore the traffic selectors (policies) suggested by the peer (which has learned them from the RouterOS via mode-config anyway) and to replace them by those locally generated from the split-include data, and due to a bug it only takes into account the first subnet in the list, or the remote peer doesn’t ask for the second subnet in the list. It’s unfortunately not visible from the log whether the client sends any traffic selector list at all and I’m not that deep into how exactly mode-config works (i.e. whether it just delivers the subnet list to the client and the client sends back the selector list like when mode-config is not used or whether the mode-config data are used locally and no selector list from the client is expected to come).

I would suggest to send those files along with supout.rif to support@mikrotik.com.

7

You’re right! I’ve just tried to change

split-include=192.168.6.0/24,192.168.5.0/24

and 6.0/24 network start working, but 5.0/24 doesn’t. Looks like some bug, that it takes the very first one. Thanks @sindy for help!

8

Maybe it’s not that it only takes the first one but that it doesn’t take the last one, so try to add one bogus subnet to the end of the list and see what happens :slight_smile:

9

I’ve asked support, they said that my client doesn’t support split mode, though it’s obvious that routes was pushed successfully.
But I found a workaround how to deal with it.

split-include=192.168.4.0/22

Don’t know why it doesn’t work with 5.0/23, got an error

value of subnet4 must have all host bits zero, as in 192.168.4.0/23

.
But anyway, it works now!

10

It’s easy:

. 192.168.5.0 = 11000000.10101000.00000101.00000000
.         /23 = 11111111.11111111.11111110.00000000
.   	        ++++++++ ++++++++ +++++++X ++++++++

So 192.168.5.0 is not a subnet address for a /23 mask, for such mask it is a device address in the middle of 192.168.4.0/23 - which in turn does not include 192.168.6.0/24. On the other hand 192.168.4.0/22 covers the range from 192.168.4.0 till 192.168.7.255, and as you have specially asked for 192.168.5.0/24 and 192.168.6.0/24, I ws expecting that 192.168.4.0/24 and 192.168.7.0/24 are used for different purposed on one of the ends of the tunnel and therefore should not be routed into the tunnel.

11

Got it. Thanks for explanation!!

Yes, actually I was needed only those 2 networks, but since 4.0/24 and 7.0/24 is not used now, that workaround works.

Thanks again for your help!