dynamic ipsec mode-config configuration

xlito · February 16, 2021, 2:06pm

Hello,

I’m trying to repeat on RouterOS the following Cisco’s configration:

interface Tunnel0
ip address negotiated
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source
tunnel mode ipsec ipv4
tunnel destination
tunnel protection ipsec profile profile

using the following configuration, I have connectivity, but few issues exists:

## this is my "external" address (got from DHCP)
/ip firewall address-list add address=192.0.2.177 list=local
## this is my LAN
/ip firewall address-list add address=192.168.56.0/24 list=local
/ip ipsec profile add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=ike-2k256
/ip ipsec proposal add auth-algorithms=sha256 enc-algorithms=aes-256-gcm pfs-group=modp2048 name=sa-2k256
/ip ipsec proposal set [find default=yes] disabled=yes
/ip ipsec mode-config add name=mc-abitc responder=no use-responder-dns=exclusively src-address-list=local
## excluding LAN traffic from ipsec
/ip ipsec policy add comment="LAN" src-address=192.168.56.0/24 dst-address=192.168.56.0/24 protocol=all action=none
/ip ipsec policy move [find comment=LAN] 0
/ip ipsec policy set [find default=yes] disabled=yes
/ip ipsec policy add template=yes dst-address=0.0.0.0/0 src-address=0.0.0.0/0 proposal=sa-2k256
/ip ipsec peer add address=x.x.x.x exchange-mode=ike2 name=xxx profile=ike-2k256
/ip ipsec identity
add auth-method=eap certificate="" eap-methods=eap-mschapv2 generate-policy=port-strict mode-config=mc-abitc peer=xxx remote-id=fqdn:xxx username=doka password="xxx"

After implementing this config, I have the following configuration:

Note here no dynamic-address for the peer

[admin@MikroTik] /ip firewall nat> /ip ipsec active-peers print detail
Flags: R - responder, N - natt-peer
0 N id=“x.x.x.x” local-address=192.0.2.177 port=4500 remote-address=x.x.x.x port=4500 state=established side=initiator uptime=4m24s last-seen=16s ph2-total=1 spii=“37a77a55b607f5fe” spir=“1492e5e2a633f26e”

while VIP address from mode-config (100.100.0.2) received and installed in the NAT rule:

/ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 D ;;; ipsec mode-config
chain=srcnat action=src-nat to-addresses=100.100.0.2 src-address-list=local dst-address-list=!local

policy seems to be what I’m looking for:

/ip ipsec policy print detail
Flags: T - template, B - backup, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 ;;; LAN
peer=“” src-address=192.168.56.0/24 src-port=any dst-address=192.168.56.0/24 dst-port=any protocol=all action=none
1 T X* group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes
2 T group=default src-address=0.0.0.0/0 dst-address=0.0.0.0/0 protocol=all proposal=sa-2k256 template=yes
3 DA peer=xxx tunnel=yes src-address=0.0.0.0/0 src-port=any dst-address=0.0.0.0/0 dst-port=any protocol=all action=encrypt level=unique ipsec-protocols=esp sa-src-address=192.0.2.177 sa-dst-address=x.x.x.x proposal=sa-2k256 ph2-count=1

Issues are:

since my external IP is DHCPed, it’s not permanent and if it will change, this will stop working
despite routing rules, for some reasons mikrotik don’t pass traffic from LAN to outer world (e.g. traceroute 1.1.1.1 from LAN connected PC shows no hops)

So the question is at the beginning of the topic - his it possible to implement “routed VPN” on RouterOS, having a generic IPSec-protected tunnel like I can do using Cisco IOS/XE?

Thank you.

sindy · February 16, 2021, 3:58pm

Currently it is not, i.e. you cannot use the “normal” routing to send packets via the IPsec tunnel, they have to be matched by a policy.

Your /ip ipsec policy print detail shows that the remote peer has suggested a policy “0.0.0.0/0 to 0.0.0.0/0” and your peer has accepted it, which means anything that reaches that policy in the list is redirected to the tunnel. You’ve excluded only the LAN subnet from that “everything to everything” policy by the action=none policy before (above) it. But I assume (as you haven’t posted the complete configuration) that you haven’t defined any actual item in the address list named local, which means that the outgoing connections don’t get src-nated by the dynamically added rule, so the remote peer has no route for the responses, or it maybe drops already the requests as they come from an unexpected address. So try first adding a route to 192.168.56.0/24 via the VTI at the remote peer, and if that doesn’t help, add an address-list item list=local address=192.168.56.0/24 at the Mikrotik end.

xlito · February 16, 2021, 10:44pm

Hi sindy,
in fact, remote side has all the required routing:

ip route |grep xfrm2

100.100.0.2 dev xfrm2 scope link
192.168.56.0/24 dev xfrm2 scope link

and locally originated packets reach destination:

/ping 1.1.1.1 src-address=192.168.56.102 count=1
SEQ HOST SIZE TTL TIME STATUS
0 1.1.1.1 56 58 20ms
sent=1 received=1 packet-loss=0% min-rtt=20ms avg-rtt=20ms max-rtt=20ms

passing though remote side in original form:

00:31:26.068623 IP 192.168.56.102 > one.one.one.one: ICMP echo request, id 64000, seq 0, length 36
00:31:26.069176 IP one.one.one.one > 192.168.56.102: ICMP echo reply, id 64000, seq 0, length 36

I added the following debug rule (the ONLY rule in the filter table) to the config:

chain=forward action=log in-interface=ether2

and see an interesting thing:

when I switch off IPSec (and regular routing is in action - you see the NAT to 192.0.2.177 in debug below), I see incoming packets on the LAN interface:

feb/17 00:04:33 firewall,info forward: in:ether2 out:ether1, src-mac 0a:00:27:00:00:00, proto ICMP (type 8, code 0), 192.168.56.1->100.100.0.1, NAT (192.168.56.1->192.0.2.177)->100.100.0.1, len 84
feb/17 00:04:34 firewall,info forward: in:ether2 out:ether1, src-mac 0a:00:27:00:00:00, proto ICMP (type 8, code 0), 192.168.56.1->100.100.0.1, NAT (192.168.56.1->192.0.2.177)->100.100.0.1, len 84

but as soon as I enable IPSec peer and policies/NAT are installed:

[admin@MikroTik] > /ip firewall nat print detail
Flags: X - disabled, I - invalid, D - dynamic
0 D ;;; ipsec mode-config
chain=srcnat action=src-nat to-addresses=100.100.0.2 src-address-list=local dst-address-list=!local
1 chain=srcnat action=masquerade out-interface=ether1
[admin@MikroTik] > /ip ipsec policy print detail
Flags: T - template, B - backup, X - disabled, D - dynamic, I - invalid, A - active, * - default
0 ;;; LAN
peer=“” src-address=192.168.56.0/24 src-port=any dst-address=192.168.56.0/24 dst-port=any protocol=all action=none
1 T X* group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes
2 T group=default src-address=0.0.0.0/0 dst-address=0.0.0.0/0 protocol=all proposal=sa-2k256 template=yes
3 DA peer=xxx tunnel=yes src-address=0.0.0.0/0 src-port=any dst-address=0.0.0.0/0 dst-port=any protocol=all action=encrypt level=unique ipsec-protocols=esp
sa-src-address=192.0.2.177 sa-dst-address=x.x.x.x proposal=sa-2k256 ph2-count=1

these records stops in the log (while no changes on the LAN PC neither in routing nor in ping) and I do not understand where they are.

So, it seems something wrong with the system configuration. I’m playing with ROS 6.48.1 and my full config is:

/ip ipsec mode-config
add name=mc-abitc responder=no src-address-list=local
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=ike-2k256
/ip ipsec peer
add address=x.x.x.x exchange-mode=ike2 name=xxx profile=ike-2k256
/ip ipsec proposal
set [ find default=yes ] disabled=yes
add auth-algorithms=sha256 enc-algorithms=aes-256-gcm name=sa-2k256 pfs-group=modp2048
/ip cloud
set update-time=no
/ip dhcp-client
add disabled=no interface=ether1
add add-default-route=no disabled=no interface=ether2 use-peer-dns=no use-peer-ntp=no
/ip firewall address-list
add address=192.0.2.177 list=local
/ip firewall filter
add action=log chain=forward in-interface=ether2
# This is NAT rule for regular routing
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
/ip ipsec identity
add auth-method=eap certificate="" eap-methods=eap-mschapv2 generate-policy=port-strict mode-config=mc-abitc peer=turbat remote-id=fqdn:x.x.x.x username=doka
/ip ipsec policy
add action=none comment=LAN dst-address=192.168.56.0/24 src-address=192.168.56.0/24
set [find default=yes] disabled=yes
add dst-address=0.0.0.0/0 proposal=sa-2k256 src-address=0.0.0.0/0 template=yes
/system clock
set time-zone-autodetect=no time-zone-name=Europe/Kiev
/system ntp client
set enabled=yes primary-ntp=82.193.104.168 secondary-ntp=193.106.144.6

and I will appreciate if you or somebody else can help me with this issue.

Thank you.

sindy · February 17, 2021, 7:54am

Oh yes, I forgot about this aspect. You have to change your “shield” policy from the current
action=none comment=LAN dst-address=192.168.56.0/24 src-address=192.168.56.0/24
to
action=none comment=LAN dst-address=192.168.56.0/24 src-address=0.0.0.0/0

The reason is that the IPsec RFC, as part of its overall security model, mandates not only that a packet matching a traffic selector of a policy must be sent using the SA associated to that policy, but also that a packet “reverse-matching” a traffic selector of a policy must be dropped if it has arrived any other way than via the SA associated to that policy. All those Virtual Tunnel Interface implementations of Cisco, Juniper, Fortinet, … actually break this part of the RFC. RouterOS strictly follows this requirement, so it silently drops such packets at ingress. This stage of packet handing is missing on the packet flow diagram.

So currently, an incoming packet from 192.168.56.1 to 100.100.0.1 doesn’t reverse-match the “shield” policy, hence it makes it to the 0.0.0.0/0->0.0.0.0/0 one, and as it has arrived in plaintext via ether2 rather than via the SA, it is dropped.

xlito · February 18, 2021, 8:26am

Sindy, thanks for the response. See my comments below.

This doesn’t work in fact. As soon as I set src=0.0.0.0/0, the picture changes to the following:

20:28:53 firewall,info forward: in:ether2 out:ether1, src-mac 0a:00:27:00:00:00, proto ICMP (type 8, code 0), 192.168.56.1->1.1.1.1, NAT (192.168.56.1->192.0.2.177)->1.1.1.1, len 64
20:28:53 firewall,info forward: in:ether2 out:ether1, src-mac 0a:00:27:00:00:00, proto ICMP (type 8, code 0), 192.168.56.1->1.1.1.1, NAT (192.168.56.1->192.0.2.177)->1.1.1.1, len 64

you see, that any incoming on LAN (ether2), being skipped by modified “shield” policy, processed in another way - it is directed by the default path (which is active when IPSec is off) and, after NAT’ed by WAN address, catched by policy and sent over the IPSec to remote side, where I see it as NAT by unknown (from VPN point of view) address:

20:28:54.676929 IP 192.0.2.177 > one.one.one.one: ICMP echo request, id 40075, seq 33041, length 44
20:28:54.747748 IP 192.0.2.177 > one.one.one.one: ICMP echo request, id 40075, seq 33042, length 44

Note that I don’t need it to ba NATed by dynamic IPSec policy - I need to see LAN traffic inside VPN with original addresses.
So, finally, what I need to have is the following diagram:

+-------+
|       |
| Site2 |
|       |
+---+---+
    |
+---+---+      +-------+
|       | NAT  |       |
|  VPN  +----->+ Inet  |
|       |      |       |
+---+---+      +-------+
    |
+---+---+
|       |
| Site1 |
|       |
+-------+

where Site1’s and Site2’s LANs are directly visible to each other and traffic inside every LAN do not go outside it’s LAN, while NAT is common for all sites and on VPN egress.

In general, I use protected tunnels to build BGP between every site and VPN - you say it’s impossible but at least static routing as I use it now (ip route over xfrm interface on VPN side) is ok.

Is it possible to achieve with RouterOS?

sindy · February 18, 2021, 10:21am

Exactly, since you have a route to 192.168.56.0/24 on the Cisco, there is no point at all in doing the NAT to the address assigned using IKEv2. So the correct thing is to place a static chain=srcnat action=accept src-address=192.168.56.0/24 rule before the action=masquerade one, and remove the address-list setting from the mode-config, as the IP address assigned via the mode-config is actually not necessary for anything at the Mikrotik side. And unless the Cisco needs that the initiator requests an address using the mode-config, you can even set mode-config on the identity row to none.

The thing here is the absence of Virtual Tunnel Interface for IPsec in RouterOS. So whereas you can use “normal” routing at the Cisco end, you must use IPsec policy matching at the RouterOS end. This is not a big deal if there is just a single IPsec tunnel, you just need one “shield” policy for each local subnet, but it is impossible to do for multiple tunnels like this (out of multiple policies 0.0.0.0/0 to 0.0.0.0/0, RouterOS will make only a single one active).

To use BGP, there is one more point - I hazily remember you have to create a tunnel interface and assign an IP address to it as the BGP requires an interface and an address attached to it to work. The remote-address of the tunnel interface is irrelevant as the packets routed via that interface will be intercepted by the IPsec policy anyway, but the keepalive parameter of the interface must be unset so that the interface was up all the time.

xlito · February 19, 2021, 6:43am

Well, summarizing everything The combination of modified “shield” policy and adding “exclusion” rule to srcnat (or removing masquerade at all):

/ip ipsec policy:
0 src-address=0.0.0.0/0 src-port=any dst-address=192.168.56.0/24 dst-port=any protocol=all action=none
/ip firewall nat:
1 chain=srcnat action=accept src-address=192.168.56.0/24 comment=“exclusion rule”
2 chain=srcnat action=masquerade out-interface=ether1

makes it working (incl even BGP) until IPSec is active. As soon as IPSec became inactive, “exclusion” rule prevents LAN to access Internet (thanks to exclusion rule).

To be frank, this is unsatisfactory result. Probably, it can be automated in some ways e.g. add exclusion rule upon IPSec establishing and remove it upon IPSec disconnection, but the more components that can fail, the greater the probability of failure.

Is there something I missed?

Yeah, RouterOS needs VTI. Topic started more than 8 years ago - Feature Request: IPSEC Improvements - and no VTI since then.

I think, we need to consider other options e.g. OpenWRT.

Thank you.

sindy · February 19, 2021, 8:02am

Not exactly.

The “exclusion rule” does its job no matter whether IPsec is active or not. So either there is another src-nat between the Mikrotik’s WAN and the internet, or you have used connections that already existed before you’ve added the “exclusion rule” for the test (only the initial packet of each connection is handled by srcnat and dstnat chains; the decision is memorized in the connection context and same or mirror treatment is applied to all subsequent packets of the same connection).

Once the 0.0.0.0/0 to 0.0.0.0/0 policy gets created, it diverts everything not matching the “shield policy” to the tunnel. I was assuming this was what you required as you’ve mentioned the NAT at the VPN box (Cisco), but from what you wrote now it seems that you want to access internet also directly via Mikrotik’s WAN, i.e. some internet destinations should be available via VPN and other ones via WAN - is this a correct understanding?

Well, rather I have missed the real goals of your setup. There could still be a way:
IKEv2 mandates that the recipient of the traffic selector offer may restrict that offer, and the offerer should accept that. Whether Cisco follows this requirement is a question, but you can try. As the Cisco offers 0.0.0.0/0 ↔ 0.0.0.0/0, you can restrict the policy template to src-address=192.168.56.0/24. If the session establishment succeeds after you disable and re-enable the peer or identity and the dynamically created policy will show src-address=192.168.56.0/24 dst-address=0.0.0.0/0 (it must be either that or no policy at all, otherwise you haven’t modified the correct template), you can put the whole approach upside down and use mangle rules or /ip route rule rows to assign routing-mark values, but instead of using them to choose a route, you would use them to let a src-nat rule match or not.

So a packet from e.g. 192.168.56.3 would be matched by the “exclusion rule”, and thus not src-nated, if marked with “use-tunnel”, and src-nated to the WAN IP if marked with another (or none) routing-mark value. So for connections via the tunnel, the original source addresses would be preserved, and for connections which should not get to the tunnel, the src-nat would make the packets invisible to the dynamically created policy.

But this can work only for a single prefix. That prefix may be short/wide enough, e.g. 192.168.0.0/16, but I don’t think you can convince the Cisco to request multiple SAs to cover multiple prefixes, so adding 172.16.0.0/12 as well is unlikely to work.

So the whole setup would look as follows:

/ip ipsec policy
add action=none comment=LAN dst-address=192.168.56.0/24 src-address=0.0.0.0/0
set [find default=yes] disabled=yes
add dst-address=0.0.0.0/0 proposal=sa-2k256 src-address=192.168.56.0/24 template=yes

/ip firewall nat
add chain=srcnat action=accept src-address=192.168.56.0/24 routing-mark=use-tunnel comment=“exclusion rule”
add chain=srcnat action=masquerade out-interface=ether1

/ip route rule
add dst-address=192.168.0.0/16 action=lookup table=use-tunnel
add dst-address=172.16.0.0/12 action=lookup table=use-tunnel
add dst-address=10.0.0.0/8 action=lookup table=use-tunnel
add dst-address=8.8.4.4 action=lookup table=use-tunnel

So traffic towards private ranges, plus towards one of the Google DNS addresses, would go through the tunnel; the rest would go via the regular gateway.

vikinggeek · February 19, 2021, 8:19am

Have you considered Using IPsec in transport mode? Since MT doesn’t provide virtual interface for IPSec, we create that via L2TP (or GRE or whatever you need). You will be able to have multiple “tunnels” and use e.g. OSPF to manage the routes. The downside is that the IP address is exposed, but since the traffic that needs to be protected is internal only, a 10.x/172.16.x/192.168.x address doesn’t give away too much.

At the moment the larger challenge is the performance of IPSec. Other threads have more details…

xlito · February 22, 2021, 4:33pm

Hi sindy, thanks for the response.

Let’s step back. My VPN hubs (Linux/Strongswan) built with VTI in mind, having unified configuration for all clients we’ve tested which are both end-customer systems (e.g. Windows 10) and routers (e.g. Cisco IOS). Routers use BGP to announce their local prefixes and receive other prefixes, which give us the plenty of benefits: (1) we do not need to reconfigure IPsec whenever prefixes change on any particular remote and (2) we can use two BGP sessions to failover wherever this possible and required. That is why we do not use traffic selectors, using 0.0.0.0/0 everywhere instead - on hub side we match by interface’s id (if_id_*) and routing table, while on remote side - dynamic tunneling as it implemented by remote operating system (e.g. protected tunnel on Cisco) and corresponding routes. Everything else should access Internet locally.

So, on Mikrotik, such kind of configuration can’t be handled dynamically and need to be described statically by various policies and access lists:

encryption local policy
shield policy
route rules (well, these can be common RFC1918 and some specifics)
nat firewall rules

e.g.

/ip ipsec policy
add comment=shield_policy src-address=0.0.0.0/0 dst-address=192.168.56.0/24 protocol=all action=none
move [find comment=LAN] 0
set [find default=yes] disabled=yes
#-- NOTE here - if I set src=192.168.56.0/24, session isn't establishing (because hub configured to 0.0.0.0/0 for both sides TS)
add template=yes dst-address=0.0.0.0/0 src-address=0.0.0.0/0 proposal=sa-2k256

/ip route rule
add dst-address=192.168.0.0/16 table=use-tunnel
add dst-address=172.16.0.0/12 table=use-tunnel
add dst-address=10.0.0.0/8 table=use-tunnel
add dst-address=8.8.4.4/32 table=use-tunnel
add dst-address=100.100.0.0/16 table=use-tunnel

/ip firewall nat
add action=accept chain=srcnat comment="exclusion rule" routing-mark=use-tunnel src-address=192.168.56.0/24
add action=masquerade chain=srcnat out-interface=ether1

At the end of the all, the entire configuration is:

/interface bridge add name=lan protocol-mode=none
/ip ipsec mode-config add name=mc-abitc responder=no
/ip ipsec profile add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=ike-2k256
/ip ipsec peer add address=f.q.d.n exchange-mode=ike2 name=my-peer profile=ike-2k256
/ip ipsec proposal set [ find default=yes ] disabled=yes
/ip ipsec proposal add auth-algorithms=sha256 enc-algorithms=aes-256-gcm name=sa-2k256 pfs-group=modp2048
/interface bridge port add bridge=lan interface=ether2
/ip cloud set update-time=no
/ip dhcp-client add disabled=no interface=ether1
/ip dhcp-client add add-default-route=no disabled=no interface=lan use-peer-dns=no use-peer-ntp=no
/ip firewall nat add action=accept chain=srcnat comment="exclusion rule" routing-mark=use-tunnel src-address=192.168.56.0/24
/ip firewall nat add action=masquerade chain=srcnat out-interface=ether1
/ip ipsec identity add auth-method=eap certificate="" eap-methods=eap-mschapv2 generate-policy=port-strict mode-config=mc-abitc peer=my-peer remote-id=fqdn:f.q.d.n username=doka.ua@gmail.com
/ip ipsec policy add action=none comment=shield_policy dst-address=192.168.56.0/24 src-address=0.0.0.0/0
/ip ipsec policy set 1 disabled=yes
/ip ipsec policy add dst-address=0.0.0.0/0 proposal=sa-2k256 src-address=0.0.0.0/0 template=yes
/ip route rule add dst-address=192.168.0.0/16 table=use-tunnel
/ip route rule add dst-address=172.16.0.0/12 table=use-tunnel
/ip route rule add dst-address=10.0.0.0/8 table=use-tunnel
/ip route rule add dst-address=8.8.4.4/32 table=use-tunnel
/ip route rule add dst-address=100.100.0.0/16 table=use-tunnel
/system clock set time-zone-autodetect=no time-zone-name=Europe/Kiev
/system ntp client set enabled=yes primary-ntp=82.193.104.168 secondary-ntp=193.106.144.6

Which do not work at all Neither 8.8.4.4 (which have to be accessible though VPN) nor 1.1.1.1 (which have to be accessible using local internet) aren’t accessible.

[admin@MikroTik] > /ip ipsec active-peers print terse
 0  N id=f.q.d.n local-address=192.0.2.177 port=4500 remote-address=x.x.x.x port=4500 state=established side=initiator uptime=22m21s last-seen=1m37s ph2-total=1 spii=0724906dccfd72a3 spir=1ea613f67208c0c2

[admin@MikroTik] > /ip ipsec policy print terse detail
 0      comment=shield_policy peer="" src-address=0.0.0.0/0 src-port=any dst-address=192.168.56.0/24 dst-port=any protocol=all action=none
 1 T X* group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes
 2 T    group=default src-address=0.0.0.0/0 dst-address=0.0.0.0/0 protocol=all proposal=sa-2k256 template=yes
 3   DA  peer=my-peer tunnel=yes src-address=0.0.0.0/0 src-port=any dst-address=0.0.0.0/0 dst-port=any protocol=all action=encrypt level=unique ipsec-protocols=esp sa-src-address=192.0.2.177 sa-dst-address=x.x.x.x proposal=sa-2k256 ph2-count=1
 
 ==== My LAN
root@iLito:~# traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
 1  192.168.56.102 (192.168.56.102)  0.784 ms  0.247 ms  0.137 ms
^C
root@iLito:~# traceroute 8.8.4.4
traceroute to 8.8.4.4 (8.8.4.4), 64 hops max, 52 byte packets
 1  192.168.56.102 (192.168.56.102)  0.540 ms  0.229 ms  0.223 ms
^C

it seems, I’ve lost completely

sindy · February 22, 2021, 7:36pm

If the design of your solution is based on VTI and all the other components of your network support it, there is little point in adding Mikrotik to the mix. As @vikinggeek has suggested, you could use IPsec just to encrypt a “traditional” tunnel, but it would require to use specific handling of the Mikrotik spokes at the VPN hubs.

xlito · February 22, 2021, 9:17pm

Sure.

Thanks a lot for clarifications and help!