Dual connection for dr and test ipsec vpn possible?

RouterOS General
1

I am trying to setup 2 ipsec vpn connection to a destination that accept both the connection. I think they are using fortigate at their end.

I am using Mikrotik CHR running on a cloud instance.

Anyway, we have 2 ipsec connection to setup, DR and testing.

I have done the configuration as below:

[abubin@uatmtik] > /ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 #     P TUN SRC-ADDRESS                                                    
 0 T *       ::/0                                                           
 1  XI  o yes 192.168.11.32/30                                               
 2  A  o yes 192.168.11.32/30              

[abubin@uatmtik] > /ip ipsec proposal print 
Flags: X - disabled, * - default 
 0  * name="default" auth-algorithms=sha256 enc-algorithms=aes-256-cbc,aes-256-ctr,aes-256-gcm 
      lifetime=30m pfs-group=modp2048 

 1    name="client" auth-algorithms=sha256 enc-algorithms=aes-256-cbc,aes-256-ctr,aes-256-gcm 
      lifetime=30m pfs-group=modp2048 

 2    name="clientdr" auth-algorithms=sha256 enc-algorithms=aes-256-cbc,aes-256-ctr,aes-256-gcm 
      lifetime=30m pfs-group=modp2048 


[abubin@uatmtik] > /ip ipsec peer print
Flags: X - disabled, D - dynamic, R - responder 
 0     name="client-peer" address=1.2.3.4/32 local-address=192.168.11.34 profile=client
       exchange-mode=ike2 send-initial-contact=yes 

 1     name="client-peerdr" address=1.2.3.4/32 local-address=192.168.11.33 profile=client 
       exchange-mode=ike2 send-initial-contact=yes

[abubin@uatmtik] > /ip ipsec identity print
Flags: D - dynamic, X - disabled 
 0    peer=client-peer auth-method=pre-shared-key secret="12345678" generate-policy=no 

 1    peer=client-peerdr auth-method=pre-shared-key secret="12345678" generate-policy=no

[abubin@uatmtik] > /ip ipsec profile print
Flags: * - default 
 0 * name="default" hash-algorithm=sha1 enc-algorithm=aes-128,3des dh-group=modp2048,modp1024 
     lifetime=1d proposal-check=obey nat-traversal=yes dpd-interval=2m dpd-maximum-failures=5 

 1   name="client" hash-algorithm=sha256 enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d 
     proposal-check=obey nat-traversal=yes dpd-interval=2m dpd-maximum-failures=5 

 2   name="clientdr" hash-algorithm=sha256 enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d 
     proposal-check=obey nat-traversal=yes dpd-interval=2m dpd-maximum-failures=5 

[abubin@uatmtik] > /ip ipsec profile print
Flags: * - default 
 0 * name="default" hash-algorithm=sha1 enc-algorithm=aes-128,3des dh-group=modp2048,modp1024 
     lifetime=1d proposal-check=obey nat-traversal=yes dpd-interval=2m dpd-maximum-failures=5 

 1   name="client" hash-algorithm=sha256 enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d 
     proposal-check=obey nat-traversal=yes dpd-interval=2m dpd-maximum-failures=5 

 2   name="clientdr" hash-algorithm=sha256 enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d 
     proposal-check=obey nat-traversal=yes dpd-interval=2m dpd-maximum-failures=5

I can connect to the client only on one policy. However, I cannot connect with both policy at the same time.

[abubin@uatmtik] > /ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic 
 0 X  chain=srcnat action=masquerade dst-address=192.168.118.0/24 out-interface=ether1 log=no 
      log-prefix="" 

 1 X  chain=srcnat action=accept src-address=10.15.103.0/24 dst-address=192.168.118.0/24 log=no 
      log-prefix="" 

 2    chain=srcnat action=src-nat to-addresses=192.168.11.34 src-address=10.15.103.0/24 
      dst-address=192.168.118.0/24 out-interface=ether1 log=yes log-prefix="" 

 3    chain=srcnat action=src-nat to-addresses=192.168.11.33 src-address=10.15.103.0/24 
      dst-address=192.168.118.0/24 out-interface=ether1 log=yes log-prefix="" 

 4    chain=srcnat action=accept src-address=192.168.40.32/30 dst-address=192.168.118.0/24 
      log=yes log-prefix="" 

 5    chain=srcnat action=masquerade out-interface-list=WAN log=yes log-prefix=""

Appreciate any help on this matter. Is it possible to do this with mikrotik or are my configs wrongly done?


mtik ---------> 192.168.11.34 (test) & 192.168.11.33 (dr) -------------> client (192.168.118.0/24)

2

Hah…got it working.

Here is what I changed,

[abubin@uatmtik] > /ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 #     P TUN SRC-ADDRESS                                                    
 0 T *       ::/0                                                           
 1  A  o yes 192.168.11.34/32                                               
 2  A  o yes 192.168.11.33/32
3

I am facing another problem now. Even though I manage to have 2 of that VPN connection established, I cannot get the routing to work.

It is the problem with the routing.

/ip route print
lags: X - disabled, A - active, D - dynamic, 
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, 
B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADS  0.0.0.0/0                          10.15.66.253              1
 1 ADC  10.15.66.0/24      10.15.66.220    ether1                    0
 2 ADC  192.168.40.33/32   192.168.40.33   ether1                    0
 3 ADC  192.168.40.34/32   192.168.40.34   ether1                    0
 4 A S  192.168.118.152/32 192.168.40.33   ether1                    1
 5   S  192.168.118.245/32 192.168.40.34   ether1                    1

The problem I think lies at rules 2 and 3. Routing for 2 will only work if routing 3 is disabled and vice versa.

Another strange thing is, I am getting a lot of unknown 0 error in the logs. I have no idea what are those about. Please advice!

4

unknown 0 is used in firewall log messages as the name of in-interface for packets which have been sent by the router itself, as no in-interface actually exists for such packets. Similarly, received packets for the router itself have out-interface set to unknown in a firewall log message.

These log rows show protocol 50, which is the ESP protocol from the IPsec suite.

5

Is that something to worry about? Cause telnet works but right now I am facing some issues communicating with the other side. Maybe it is not related to this error but it is concerning to have this showing in the logs.

6

No, it is normal that your machine sends and receives the IPsec transport packets if there is an IPsec tunnel on it.


Not everything which is in a log is an error - these messages’ severity is info as you can see in the relevant column. Your action=src-nat rules have a log=yes parameter, which causes the first packet of an ESP connection to be logged. No one else but you can explain why you have set log=yes in these rules.

And yes, the issues you encounter with use of the tunnel are not related to the fact that ESP is being sent; you would have issues if it wasn’t.

I’m a bit suprised that the tunnels work even though you change the source address of ESP packets by src-nat, most likely it actually doesn’t change as the source address before the src-nat is the same. Can’t say without seeing the complete export of the configuration (minus sensitive information, see my signature).

7

Thank you for the reply. Appreciate your sharing of knowledge.

I have encountered another issue on this VPN. Just this morning connection to the other side suddenly failed. Upon checking, I can see the IPsec connection still showing “established”. So I tried a quick telnet (from the mikrotik) to the other side and it sure enough is unable to connect. I went on to check on other things like connection configurations and everything looks normal. After like a few minutes I went back to telnet again and this time it works. Yes, it worked without me actually doing anything. Upon checking with the “other side” they said they are receiving a lot of encryption error from us. They did not say if they did anything to resolve it. I am assuming they didn’t do anything on their side as well.

From the log, I can see something different when it failed:
mtik-error-20200812.png
There are 3 lines in the log under the red square:
Line 1. the public IP of client is censored.
Line 2. 100.100.2.136 is the internal IP of cloud provider.
Line 3. 159.148.147.196:443 - unknown IP and don’t know why port 443.

Appreciate if anyone can shed some light. Why it suddenly fail and how to prevent it from happening again.

8

The symptoms you describe occur when the renegotiation of the SA results in a mismatch of the ephemeral encryption keys. I had this occurring randomly with IKEv2 and Mikrotik has fixed it at least a year ago in 6.43.something, what RouterOS version do you run?

9

I am using Mikrotik CHR RouterOS 6.45.9.

10

The bug happened again yesterday. It is causing problems on our side as we have data transactions by the seconds. Anyone can help shed some light into how to resolve this issue? I have already emailed Mikrotik support but they responded with some setting for us to try which does not work. No response since then.