IPsec configuration... am I missing something?

RouterOS General
1

So, here's the situation:
I have two locations, my parent's home where I use ADSL connection and I don't have a static public IP address. Then, there's my home where I have a public IP address assigned to my router. So to tell a long story short - I would like to establish an IPsec connection in order to be able to access both networks without the need for an openVPN client or something like that. That's the plan.
Browsing the documentation for possible solutions I found maybe what I was looking for:

in the section Road Warrior setup with Mode Conf I think it's exactly what I was looking for, but apparently... something is missing from my config, as it does not work as I expect it to..
A little bit more details about my setup:

  1. The router connected to the ADSL connection... It does not have a public IP address as I've already mentioned, so we can consider that every time I switch it on or off the public IP address will be different. It has only one LAN network configured - 192.168.88.0/24
  2. The router at my home has a public IP address, which is statically configured on the outbound interface. It also has only one LAN configured - 192.168.99.0/24.
    The set up looks quite straight forward so I've modified the configuration from the above mentioned link, this is how it looks like on both devices:
    Server Side Configuration
    [admin@MikroTik_main] > /ip ipsec export

dec/26/2013 17:07:58 by RouterOS 6.7

software id = 2DWW-HXRL

/ip ipsec mode-cfg
add address-pool=dhcp name=ipsec-cfg split-include=192.168.99.0/24
/ip ipsec policy group
add name=ipsec-group
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=3des
/ip ipsec peer
add auth-method=pre-shared-key-xauth generate-policy=port-strict mode-cfg=
ipsec-cfg passive=yes policy-group=ipsec-group secret=123
/ip ipsec policy
add dst-address=192.168.99.0/24 group=ipsec-group src-address=192.168.99.0/24
template=yes
[admin@MikroTik_main] > /ip ipsec user print

NAME PASSWORD

0 MikrotikDz sample-password
[admin@MikroTik_main] > /ip pool print

NAME RANGES

0 dhcp 192.168.99.10-192.168.99.50

Client Side Configuration

[admin@MikroTik] > /ip ipsec export

dec/26/2013 17:10:20 by RouterOS 6.7

software id = AJE8-F43C

/ip ipsec proposal
set [ find default=yes ] enc-algorithms=3des
/ip ipsec peer
add address=77.[admin@MikroTik_Dupnitza] > /ip ipsec export

dec/26/2013 17:10:20 by RouterOS 6.7

software id = AJE8-F43C

/ip ipsec proposal
set [ find default=yes ] enc-algorithms=3des
/ip ipsec peer
add address=77.70.67.28/32 auth-method=pre-shared-key-xauth generate-policy=port-strict secret=123 xauth-login=
MikrotikDz xauth-password=sample-password=70.67.28/32 auth-method=pre-shared-key-xauth generate-policy=port-strict secret=123 xauth-login=
MikrotikDz xauth-password=sample-password

The end result is:
[admin@MikroTik_main] > /ip ipsec remote-peers print

[admin@MikroTik_Dupnitza] > /ip ipsec remote-peers print
0 local-address=192.168.1.2 remote-address=77.70.67.28 state=message-1-sent side=initiator

Empty! Which to me means I don't have IPsec conncetion established... What I am missing here? And the issue is, I haven't yet figured out how to troubleshoot this... In the document mentioned above the author recommends to use /ip ipsec policy dump-kernel-policies to troubleshoot IPsec connection establishment but.. when I try it on my routers, the command does not seem to be supported:
[admin@MikroTik] > /ip ipsec policy dump-kernel-policies
bad command name dump-kernel-policies (line 1 column 18)

What do you think guys? I'm a bit stuck on this...

2

This looks like a typical site-to-site with the only difference that one of your end-points does not have static IP address. That means you do not need mode-cfg and xauth.

Remove this.

Change ‘pre-shared-key-xauth’ to ‘pre-shared-key’. You can also add ‘send-initial-contact=no’ but that does not seem to be strictly necessary.

Change src-address to 192.168.88.0/24.

Remove this (both ipsec users and pool).

Again, change ‘pre-shared-key-xauth’ to ‘pre-shared-key’. Also remove ‘xauth-login’ and ‘xauth-password’.

And you also need to setup client-side policies (not policy templates!!!). This part is tricky, since you need to specify your client’s outer-tunnel IP address, which as you wrote is not static. The solution is to specify an arbitrary IP address in your policy and then use some script that will update your policy any time your public IP address changes. This policy should look like this:
/ip ipsec policy
add dst-address=192.168.99.0/24 sa-dst-address=77.70.67.28 sa-src-address=x.x.x.x src-address=192.168.88.0/24 tunnel=yeswhere x.x.x.x is the IP address to be changed by the script. I’ve seen a ready to use script somewhere either on this forum or on Mikrotik wiki, try using search.

3

andryis thank you for your quick and detailed reply…
I’m just wondering… doesn’t the configuration you propose break the concept of the mode-cfg and template configuration? I mean… the way I understand it - it allows me to have a device working like a VPN concentrator where I can terminate IPsec tunnels from clients whether other MikroTik routers or hosts with a VPN app configured on them.

4

Mode-cfg is mostly for road-warrior configurations, when the client is an IPsec software running on the end-user’s computer. It is not intended for cases like yours, when you have a separate network hidden behind your client device. Having said that, it is still possible to use mode-cfg + templates in your case, I just don’t see any points/benefit in doing that.

5

andriys,
I guess the whole point of the mode-cfg configuration is that I won’t have to create a script for the dynamically changing IP address :wink:
In the mean time I’ve changed the configuration on both routers. Now, I have the IPsec connection listed as established at both ends:
[admin@MikroTik_main] > /ip ipsec remote-peers print
0 local-address=77.70.67.28 remote-address=46.10.36.211 state=established
side=responder established=8m30s

[admin@MikroTik] > /ip ipsec remote-peers print
0 local-address=192.168.1.2 remote-address=77.70.67.28 state=established
side=initiator established=7m50s

The SAs are also installed at both sides:
[admin@MikroTik_main] > /ip ipsec remote-peers print
0 local-address=77.70.67.28 remote-address=46.10.36.211 state=established
side=responder established=8m30s
[admin@MikroTik_main] > /ip ipsec installed-sa print
Flags: A - AH, E - ESP, P - pfs
0 E spi=0x2ECECA9 src-address=46.10.36.211 dst-address=77.70.67.28
auth-algorithm=sha1 enc-algorithm=3des replay=4 state=mature
auth-key=“04a8924a813ab0fb44490097fcf34ecb43e35345”
enc-key=“b25e3c69d8bdd19cf320a592d2a02212c9612fabc54b9e00”
add-lifetime=24m/30m

1 E spi=0x7B984D1 src-address=77.70.67.28 dst-address=46.10.36.211
auth-algorithm=sha1 enc-algorithm=3des replay=4 state=mature
auth-key=“902fd02ebaad49981354ca8b63923a853fb62eac”
enc-key=“28d5a7eac21deb3e4b068b1566caf7a1ee7a48304b15c98b”
addtime=dec/28/2013 21:15:57 expires-in=23m2s add-lifetime=24m/30m
current-bytes=672

[admin@MikroTik] > /ip ipsec installed-sa print
Flags: A - AH, E - ESP, P - pfs
0 E spi=0x2ECECA9 src-address=192.168.1.2 dst-address=77.70.67.28
auth-algorithm=sha1 enc-algorithm=3des replay=4 state=mature
auth-key=“04a8924a813ab0fb44490097fcf34ecb43e35345”
enc-key=“b25e3c69d8bdd19cf320a592d2a02212c9612fabc54b9e00”
add-lifetime=24m/30m

1 E spi=0x7B984D1 src-address=77.70.67.28 dst-address=192.168.1.2
auth-algorithm=sha1 enc-algorithm=3des replay=4 state=mature
auth-key=“902fd02ebaad49981354ca8b63923a853fb62eac”
enc-key=“28d5a7eac21deb3e4b068b1566caf7a1ee7a48304b15c98b”
add-lifetime=24m/30m

So it looks good… but I still cannot ping the networks behind the routers 192.168.88.0/24 and 192.168.99.0/24. And I figured, that maybe the NAT is to blame for this. According to my understanding the IPsec tunnel is established between the devices and it’s working. I’ve got back to the document I mentioned in my first post, and indeed such a situation is discussed there. So I added the following configuration:
/ip firewall nat
add chain=srcnat dst-address=192.168.88.0/24 src-address=192.168.99.0/24

/ip firewall nat
add chain=srcnat dst-address=192.168.99.0/24 src-address=192.168.88.0/24

With the above configurations both routers should exclude the locally originated traffic send towards the partner router’s network from the NAT rule.
But again…no ping! Do you have an idea how I could monitor whether there’s any traffic sent over the IPsec tunnel? The output of /ip ipsec statistics print shows only error counters, and they’re all zero…

6

I believe mode-cfg is the responder-side setting only in RouterOS. So no, mode-cfg won’t let you avoid using that script.
Let Mikrotik support guys correct me if I’m wrong.

7

Are there any dynamic policies listed on both responder and initiator side?

8

No, I don’t have any other policies besides the one we’re discussing here…
I still believe that the issue is not the IPsec though. According to the outputs - it’s established. But I guess the firewall is blocking the traffic, or the NAT…

9

I’ve asked about dynamic policies. They should be created during connection at least on the responder side. Initiator usually has ordinary (static) policies preconfigured, but if you’re are right and mode-cfg + templates can be used on the initiator side as well, then dynamic policies should also appear on the initiator side.

Policies is what tells your router what traffic should be encrypted, so without them you VPN tunnel won’t work.

10

andriys… I think I’m starting to get the IPsec configuration piece by piece in my head. I think I’m missing this. I only get output in the /ip ipsec remote-peer print section. But at least until now, I haven’t seen any dynamic policies forming. I’ll double check in a couple of days, I’m a bit on the road at the moment and I don’t have direct access to one of the routers to test it…

11

So finally I’ve got a time to test this once again. and the IPsec tunnel is working. Thank you andriys.
Now I’ve got a pretty got idea on how to configure IPsec in RouterOS. I’ll still have to look for a dynamic way of establishing the IPsec tunnel though. I’ll check again the documentation…