basic ipsec server config

RouterOS General
1

Hi,

I’m trying to setup a basic ipsec responder with my mikrotik, running on v6.45.3.
The mikrotik router is the responder, and the initiators will be linux PCs with strongswan. The have to get a dynamic address from the responder.

First, I set up an ip pool:

/ip pool
add name=23-2 ranges=172.23.2.101-172.23.2.150

then a mode config:

/ip ipsec mode-config
add address-pool=23-1 name=cfg1 system-dns=no

then a peer and an identity

/ip ipsec peer
add address=192.168.88.5/32 exchange-mode=ike2 local-address=192.168.88.1 name=test2 passive=yes
/ip ipsec identity
add mode-config=cfg1 peer=test2 remote-id=fqdn:testttt secret=blablabla

and my policy:

/ip ipsec policy
add dst-address=172.23.1.0/24 peer=test2 sa-dst-address=192.168.88.5 sa-src-address=192.168.88.1 src-address=172.23.1.0/24 tunnel=yes

my remote client is now able to connect to my mikrotik, but it does not get an ip from the pool:

[admin@MikroTik] > /ip ipsec active-peers print 
Flags: R - responder, N - natt-peer 
 #    ID                   STATE              UPTIME          PH2-TOTAL REMOTE-ADDRESS                                                                                                 DYNAMIC-ADDRESS                                                                       
 0 R  testttt              established        9s                        192.168.88.5

on the client side, I get a ts_unacceptable error:

charon: 10[IKE] received TS_UNACCEPTABLE notify, no CHILD_SA built

What could be wrong ? isn’t it the way to configure an ipsec server ?

Thanks,

Mathieu

2

TS is Traffic Selector. The (src-address,dst-address[,protocol[,src-port,dst-port]]) tuple (which is the Traffic Selector itself) of a policy at one peer must match the (dst-address,src-address[,protocol[,dst-port,src-port]]) tuple of the policy at the other peer. If they don’t match exactly, no SA is not created for the matching traffic.

With mode-config which assigns an address, it is necessary that one policy was auto-generated per each subnet specified in the split-include list of the mode-config to which the identity at responder side refers as src-address at the responder side and dst-address at the initiator side, and with the address assigned to the initiator by the responder as the dst-address on responder side and src-address at initiator side. But for this to happen, the policy-generate parameter of that identity must be set to port-strict or port-override. If no split-include list is given, by default it means 0.0.0.0/0. So if strongswan gets a mode-config with an IP address and no split-include, it creates a policy with dst-address=0.0.0.0/0 and src-address set to the address it got assigned, but the Mikrotik doesn’t create a corresponding policy and phase 2 fails.

3

Can you clarify in more detail this statement?

With mode-config which assigns an address, it is necessary that one policy was auto-generated per each subnet specified in the split-include list of the mode-config to which the identity at responder side refers as src-address at the responder side and dst-address at the initiator side, and with the address assigned to the initiator by the responder as the dst-address on responder side and src-address at initiator side. But for this to happen, the policy-generate parameter of that identity must be set to port-strict or port-override. If no split-include list is given, by default it means 0.0.0.0/0. So if strongswan gets a mode-config with an IP address and no split-include, it creates a policy with dst-address=0.0.0.0/0 and src-address set to the address it got assigned, but the Mikrotik doesn’t create a corresponding policy and phase 2 fails.

In my case I do not have strongswan. I have two Mikrotiks and one side is Static and other is dhcp. I want an IKEv2 tunnel between the two and I keep getting TS_Unacceptable but am not clear on how to sort it out.

4

I cannot find the post where I explained how the individual items in the IPsec configuration tree are linked to each other, so briefly again:

  • a policy can either be configured statically, or generated dynamically from a template. The policy consists of several groups of parameters:
  • the traffic selector (source and destination address or prefix, possibly an IP protocol, and if the IP protocol supports the notion of ports, also source and destination port)
    • the peer to use (which translates into sa-src-address and sa-dst-address of the SA (security association))
    • the proposal to use to negotiate the SA parameters (encryption, authentication, lifetime)
      Generation of the actual policy from a policy template is used where the exact values of the sa-dst-address and/or the traffic selector are not known in advance because they can dynamically change. To let the actual policy be generated from a template, the identity row must be configured with generate-policy value different from no. The policy-template-group parameter of the identity row can be used to customize the set of policy templates to choose from.
  • the mode-config works in such a way that the initiator requests an IP address to use on its end, and the responder assigns it from a pool. Hence the policy (or multiple policies) must be generated dynamically at both peers; the initiator side address or prefix of the traffic selector is the one assigned by the responder based on the mode-config row used, the responder side address or prefix of the traffic selector is either 0.0.0.0/0 if no split-include value is configured on that mode-config row, or the prefix (subnet) list from the split-include is expanded to multiple policies (the traffic selector can have only a single source prefix and single destination prefix). The identity row links to the mode-config row to use; at the initiator side, it must be one with responder=no (there is a pre-defined one named “request-only”), at the responder side, you define a mode-config row according to the needs of your setup and make the identity row refer to it.

So where only one public IP is static (or at least can be determined using some dynamic DNS system), the system running at that address must act as the responder. The initiator may run even behind a NAT without static port forwarding. At both sides, it is enough to set generate-policy to port-strict at the corresponding identities, but the traffic selectors of the policy templates at both sides must be supersets of the actually required policies, and these templates must use compatible proposals.

If you do not need the internal address of the initiator to be assigned by the responder, because you choose it, you do not need to use mode-config at all; in this case, you configure the policy statically at initiator side (as the traffic selector is known in advance), but you still need to let it be dynamically generated from a template at responder side, because there, the actual address of the initiator is unknown in advance.

It is actually a bit more complex as at the initiator side, the sa-src-address may also be dynamic, but this is overcome by the fact that the statically configured policy is linked to a peer and inherits the local-address from that peer as its sa-src-address. But this doesn’t work (or at least didn’t when I’ve tried last time) for sa-dst-address at responder side as the peer’s address must be a prefix, not a /32 address, if initiator’s address is not known in advance.


The log is your friend (but quite a verbose one):

  • disable the peer (or identity) at initiator side
  • run
    /system logging add topics=ipsec,!packet
    log print follow-only file=ipsec-start where topics~“ipsec”
  • enable the peer or identity at initiator side
  • after the connection attempt fails, break the log print … command, download the file and see what the reason for TS_Unacceptable was (what TS the peer has suggested).
5

@sindy, you available to chat?

6

I have sent you an e-mail yesterday, maybe a spam filter has caught it?