VPN with GCP

RouterOS General
1

I gathered many information in huge GCP documentation about setting IPsec using IKEv2 with BGP.

What I found is that , and this is important

Important: When using IKEv2, your peer VPN gateway must accept all of the CIDRs in each traffic selector using a single Child SA. Not all VPN gateways support this. VPN gateways that create a unique Child SA per CIDR are not compatible with Cloud VPN. See traffic selector strategies for additional details.

https://cloud.google.com/vpn/docs/concepts/choosing-networks-routing#ts-ip-ranges

and also I was struggling with a issue which occurs no ping to remote networks. More about that was described here
http://forum.mikrotik.com/t/ipsec-ikev2-gcp-ping-timeout/129598/8

I was speaking with GCP support for past few days and they notice I receive constantly

{
 insertId:  "1hkfx2ag100glgy"   
 labels: {…}   
 logName:  "projects/casino-front/logs/cloud.googleapis.com%2Fipsec_events"   
 receiveTimestamp:  "2020-06-02T16:56:32.894395202Z"   
 resource: {…}   
 severity:  "NOTICE"   
 textPayload:  "Warning: Remote traffic selectors narrowed for Child SA: vpn_94.237.xx.xx. Configured TS: [0.0.0.0/0  ], negotiated TS:[172.16.18.0/24  ]. Please verify configuration on the remote side."   
 timestamp:  "2020-06-02T16:56:32.831941608Z"   
}

So problem is that first of all I can’t use level-unique because GCP requires single Child for SA negotiation. So I changed it to use but also it is required to set 0.0.0.0 src and dst in IPsec policy. When I do that I loose connectivity
Could someone advise me how to proceed ?

2

I’d prefer require to use for level, but that’s minor. To prevent losing connectivity by setting policy’s src and dst to 0.0.0.0/0, place policies with action=none and dst-address which needs to stay accessible directly (not via IPsec) before (above) the one used for GCP.

3

require - drop packet and acquire SA; <= When I had that in installed-sa I had lot of dead SA which weren’t cleared when the tunnel reconnect itself. After set to use it looks good.
I was referring to the Single Child SA

So let me understand that
you are talking about that?
/ip ipsec policy add dst-address=$here action=none place-before=0 ?

$here is <mikrotik_public_IP> all current networks I have on mikrotik side (leftside) ?

When I’ve set the 0.0.0.0/0 in src and dst the rule become invalid

4

IPsec policies override all routes including those to connected subnets. So a 0.0.0.0/0 → 0.0.0.0/0 policy overrides even the access to the Mikrotik via local subnets. Hence if by “all current networks” you mean all the LAN subnets of the Mikrotik, then yes, this is what I had in mind. But the reference to <mikrotik_public_IP> doesn’t fit to this understanding, so maybe describe the environment at the Mikrotik end in more detail, and describe what exactly you mean by “losing connectivity”. Depending on which remote subnets you really need to be routed through the IPsec tunnel to GCP and which ones to use the “normal” routing, you may even have to generate action=none policies to shadow that 0.0.0.0/0 → 0.0.0.0/0 policy for all destinations except a single address or subnet.

But as you mention BGP, I still wonder whether policy-based traffic selection will be sufficient for the purpose or whether you would need a virtual tunnel interface for IPsec, which is not available at Mikrotik.

5

Still I can’t manage to create a ipsec policy to connect with GCP

/ip ipsec policy
add action=none dst-address=172.16.1.0/24 src-address=0.0.0.0/0
add action=none dst-address=172.16.3.0/24 src-address=0.0.0.0/0
add action=none dst-address=172.16.18.0/24 src-address=0.0.0.0/0
add action=none dst-address=10.0.0.0/13 src-address=0.0.0.0/0
add action=none dst-address=10.13.50.0/24 src-address=0.0.0.0/0
add action=none dst-address=10.99.5.0/24 src-address=0.0.0.0/0
add action=none dst-address=10.254.254.0/24 src-address=0.0.0.0/0
add action=none dst-address=10.255.254.0/23 src-address=0.0.0.0/0

And tried this approach https://wiki.mikrotik.com/wiki/IKEv2_EAP_between_NordVPN_and_RouterOS#Setting_up_the_IPsec_tunnel

But logs in GCP are with no mercy here
Logs from GCP attached

I don’t kniw what you mean routed through. I don’t wanna route anything through. I want to connect both sides and allow networks in those sides to communicate each other
vpn_gateway_gateway_id_2965042421677708386__logs__2020-06-02T09-42.txt (59.1 KB)

6

The log from GCP side suggests that you use mode-config=request-only in the /ip ipsec identity at Mikrotik side, thus asking the GCP end to assign an IP address to the Mikrotik, but it doesn’t have one on stock. Is requesting an address via mode-config required by their documentation?

7

No it doesn’t and I don’t request anything. I showed a tutorial with nordvpn where there is a way to configure policy with 0.0.0.0/0 and by they way it uses template . And no, I’m not using request-only I created a unnecessary mode-config with different name. I’ve just removed it. But the logs shows the same thing. So.. still no luck. by the way still traffic says that I’m using wrong networks .. it takes SA Addresses. I have a question? E’m I the only one who is trying to set Google Cloud Platform VPN with BGP on MikroTik? Did no one created a proper configuration and can’t share with me ?
vpn_gateway_gateway_id_2965042421677708386__logs__2020-06-02T11-12.txt (59.9 KB)

8

I received answer from Emil, from MikroTik Supportm and he says

Hello,
RouterOS has policy based IPsec only. You can configure 0.0.0.0/0<->0.0.0.0/0 traffic selector, but you will not be able to route specific traffic over the tunnel, so that really is not an option at this time.

Emīls Z.

So right now BGP will not work with local and remote traffic selector set on 0.0.0.0/0

Which means Using GCP VPN along with BGP isn’t possible right now with MikroTik. Maybe a case for MikroTik Developers to fix this.

IPsec IKEv2 GCP ping timeout
9

But I don’t get. I changed cloud vpn to route based mode and it requires 0.0.0.0/0 in traffic selector. Setting 0.0.0.0/0 likewise on local and remote ends up with ping processing but Winbox hangs and I’m waiting when i disconnect me. When it happens I’m checking ping from VM in GCP to mikrotik.. and i works

10

@sindy
The only thing I manage to do this using template



take a picture gif

11

As @emils has told you, RouterOS currently does not support virtual interfaces for IPsec. I’m not sure whether BGP can work with a peer that is not accessible via a particular interface, but if such limitation exists, it might be possible to overcome it using a dedicated bridge interface with no member ports - I’ve never tried that, though.

Other than that, the whole issue with the absence of a virtual interface functionality is that IPsec policy always wins over regular routing results, whereas the remote peer requires an any->any traffic selector; the policy’s traffic selector is not only used locally but also negotiated using IKE or IKEv2, and it is not possible to use one selector for negotiation and another one for the actual traffic selection. So to fulfil the requirement of the remote peer, we need to “save” everything we don’t want to send down the IPsec tunnel to that peer by means of other policies (plus we cannot have more than one such peer, as two identical policies are not supported).

So you have three groups of destination subnets:

  1. the ones local to the GCP site
  2. the ones local to the Mikrotik site
  3. the rest of the whole 0.0.0.0 .. 255.255.255.255 range

And we need that packets for any destination except the first type are matched by some other policy’s traffic selector before they reach the 0.0.0.0/0 => 0.0.0.0/0 one.
It is relatively simple to exclude the local subnets, but it is a headache to match all the networks except the first type, especially if there is more than one subnet. So if the router is not used for regular internet access, you can only take care of the second type using the action=none policies, and blackhole the rest in regular routing (packets to blackholed destinations do not make it to traffic selector matching); otherwise, you need to build a complete collection of policies which match everything except the first type.

In your example, you’ve configured exception policies with destinations 0.0.0.0/1 and 128.0.0.0/1, which shadow the whole 0.0.0.0/0 range, so nothing reaches the policy with destination=0.0.0.0/0.

So as an experiment, you can configure the exceptional policies only for the local subnets, disable the default route in regular routing, and add only routes to the GCP’s public IP (so that the tunnel could establish) and to the IP at which the GCP’s BGP instance is listening. In this setup, establishing the tunnel should not kick you out from the router management, and it should still be possible to ping through the IPsec tunnel. Only once that works properly, it makes sense to configure BGP and additional exceptional routes and policies.

If your Mikrotik is resourceful enough to support the Metarouter functionality, it will be much simpler to use one instance of RouterOS configured as above, effectively imitating the IPsec virtual interface functionality, and run the BGP and the rest of the routing functionality on the basic instance. If it doesn’t, the complexity of creation of the exceptional policies depends on the number of subnets at the GCP end, and whether they are static or change over time - in that case, the exceptional policies would have to be generated using a complex script from the routes learned via BGP.

12

what do you mean by first type?

I di literally studied your answer but it hard to understand without practical example

I would be very grateful if you could show examples

13

There was a numbered list of destination subnet groups/types/categories right above that. So “first type” means “the ones local to the GCP site”.


There is a simplified example in this post. If it still doesn’t explain the idea:

Imagine you have two subnets, 172.16.3.0/24 and 172.16.8.0/24, at the GCP end, and your local subnets are 172.16.5.0/24 and 172.16.71.0/24, and that you don’t care about internet destinations at all.

There are 256 /24 subnets within 172.16.0.0/16, and you need to prevent just two of them from being matched only by the “any=>any” policy, because those which are neither local to the Mikrotik nor local to the GCP end will never be used (unless you have a more complex topology of your internal network). So for this case, leaving internet aside, the following “exception policies” are sufficient:

/ip ipsec policy
add action=none dst-address=172.16.5.0/24 src-address=0.0.0.0/0
add action=none dst-address=172.16.71.0/24 src-address=0.0.0.0/0
add action=encrypt dst-address=0.0.0.0/0 src-address=0.0.0.0/0

But if you need that hosts in the two local subnets can access internet, you need additional policies with action=none, covering all the public address ranges, as follows:
dst-address=0.0.0.0/1 (0.0.0.0-127.255.255.255) (actually, this includes also 0.0.0.0/8, 10.0.0.0/8 and 127.0.0.0/8, which are not public address ranges, but it doesn’t matter as we do not want the “any=>any” IPsec policy to match these anyway),
dst-address=128.0.0.0/3 (128.0.0.0-159.255.255.255)
dst-address=160.0.0.0/5 (160.0.0.0-167.255.255.255)
dst-address=168.0.0.0/6 (168.0.0.0-171.255.255.255)
dst-address=172.0.0.0/12 (172.0.0.0-172.15.255.255)
<— here is the gap for the private address range 172.16.0.0/12 (172.16.0.0 - 172.31.255.255) —>
dst-address=172.32.0.0/11 (172.32.0.0-172.63.255.255)
dst-address=172.64.0.0/10 (172.64.0.0-172.127.255.255)
dst-address=172.128.0.0/9 (172.128.0.0-172.255.255.255)
dst-address=173.0.0.0/8 (173.0.0.0-173.255.255.255)
dst-address=174.0.0.0/7 (174.0.0.0-175.255.255.255)
dst-address=176.0.0.0/4 (176.0.0.0-191.255.255.255)
dst-address=192.0.0.0/2 (192.0.0.0-255.255.255.255) (like above, it doesn’t matter that 192.168.0.0/16 is not a public address range, as it doesn’t matter that we protect it from IPsec as well)

If it is not clear why the above looks the way it looks, you may be missing the concept how subnet mask works. Say, we have a range from 128.0.0.0 to 191.255.255.255. This can be expressed as 128.0.0.0/2, because this means “the most important three bits of the most important byte must be 10, the rest can be anything”. So the most important byte may be anything from 1000 0000 (0x80, 128) to 1011 1111 (0xbf, 191). If you want 168.0.0.0/5 (168.0.0.0-175.255.255.255) not to be included, you have to split the above into several ranges. But instead of 8 individual /5 subranges within that /2 range, you can group them where possible:

128/5 \
       > 128/4 \
136/5 /         \
                 > 128/3
144/5 \         /
       > 144/4 /
152/5 /

160/5

(168/5)

176/5 \
       > 176/4
184/5 /

So you end up with 128/3, 160/5, and 176/4 as exceptions from the complete 128/2, and only 168/5 is not covered by any of those.

14

Ok basically what bothers me are two things.

  1. I’ve set it like this (so we exclude two IP classes. 10.x and 172.16-31)

/ip ipsec policy
set 0 disabled=yes
add action=none dst-address=10.99.6.0/24 src-address=0.0.0.0/0
add action=none dst-address=10.0.0.0/13 src-address=0.0.0.0/0
add dst-address=0.0.0.0/0 proposal=GCP_phase2 src-address=0.0.0.0/0 template=yes

Bu the tunnel isn’t connecting

10:19:52 ipsec,info new ike2 SA (I): 94.237.xx.xx[4500]-35.204.xx.xx[4500] spi:9df288f54d6e746b:0d8da2bdab6b7d67
10:19:52 ipsec,info,account peer authorized: 94.237.xx.xx[4500]-35.204.xx.xx[4500] spi:9df288f54d6e746b:0d8da2bdab6b7d67
10:19:52 ipsec,info killing ike2 SA: 94.237.xx.xx[4500]-35.204.xx.xx[4500] spi:9df288f54d6e746b:0d8da2bdab6b7d67

I manage once to get this working but I don’t remember what was it.

15

You’ll need detailed IPsec logging to see why the tunnel doesn’t come up.

  1. Disable the peer
  2. Switch detailed logging on:
    /system logging add topics=ipsec,!packet
  3. Start copying the log into a dedicated file:
    /log print follow-only file=ipsec-startup where topics~“ipsec”
  4. Enable the peer
  5. Wait until the connection fails
  6. Break the /log print …
  7. Download the file and analyse it
16

I must say that logs don’t give me much information what’s going beside that there is a timeout

jun/29/2020 11:27:13 by RouterOS 6.45.9

software id =

11:27:17 ipsec ike2 init retransmit
11:27:17 ipsec,debug ===== sending 424 bytes from 94.237.xx.xx[4500] to 35.204.xx.xx[4500]
11:27:17 ipsec,debug 1 times of 428 bytes message will be sent to 35.204.xx.xx[4500]
11:27:22 ipsec ike2 init retransmit
11:27:22 ipsec,debug ===== sending 424 bytes from 94.237.xx.xx[4500] to 35.204.xx.xx[4500]
11:27:22 ipsec,debug 1 times of 428 bytes message will be sent to 35.204.xx.xx[4500]
11:27:27 ipsec ike2 init retransmit
11:27:27 ipsec,debug ===== sending 424 bytes from 94.237.xx.xx[4500] to 35.204.xx.xx[4500]
11:27:27 ipsec,debug 1 times of 428 bytes message will be sent to 35.204.xx.xx[4500]
11:27:32 ipsec ike2 init timeout
11:27:40 ipsec ike2 starting for: 35.204.xx.xx
11:27:40 ipsec adding notify: NAT_DETECTION_DESTINATION_IP
11:27:40 ipsec,debug => (size 0x1c)
11:27:40 ipsec,debug 0000001c 00004005 0f3e2c4d c2745b24 83e70b68 8a30dbc2 7782d6e7
11:27:40 ipsec adding notify: NAT_DETECTION_SOURCE_IP
11:27:40 ipsec,debug => (size 0x1c)
11:27:40 ipsec,debug 0000001c 00004004 428c292b def2043e d7d6f8dd e6b91a68 09e073b2
11:27:40 ipsec adding payload: NONCE
11:27:40 ipsec,debug => (size 0x1c)
11:27:40 ipsec,debug 0000001c d99c3f3a bbcbda75 f1b3c1d7 7b543984 30f99f55 4e42eb41
11:27:40 ipsec adding payload: KE
11:27:40 ipsec,debug => (first 0x100 of 0x108)
11:27:40 ipsec,debug 00000108 000e0000 ed668335 36c9d9cc b88ad1a8 e96e6a9d 1037f7a0 1869128a
11:27:40 ipsec,debug 91a07568 998f38d9 1a76efff c1657e93 62be84ab b57b5ef9 8a1bdde4 039b6312
11:27:40 ipsec,debug 22c25e34 3ed385f1 cabd3c2f b0e2831d 42ddddb6 4d421532 eab70fa6 695e4f50
11:27:40 ipsec,debug 02f81a4c 15885dfe 37d9d641 b0282f9a 7e620794 f6483a47 b2980ccd d7d585e2
11:27:40 ipsec,debug d29286d5 4ffe1355 c4322e1e 35fef7ed c8450460 79d3cdf1 11334dcd 314fc420
11:27:40 ipsec,debug bf9c435e 0a3c2a2e af7356da b2f44be8 a1dfa554 28300ae7 e3f49f06 4b6ce481
11:27:40 ipsec,debug d8c702ca 9bcf6cc2 59b63898 c0a3aaa9 47a53360 753e21ad 5595b7bc 217fdf68
11:27:40 ipsec,debug 0defde63 d4d43ab1 818143fa 6c64c7cb 1273172c ca370a4f cd3bfd5f b1187685
11:27:40 ipsec adding payload: SA
11:27:40 ipsec,debug => (size 0x30)
11:27:40 ipsec,debug 00000030 0000002c 01010004 0300000c 0100000c 800e0080 03000008 02000002
11:27:40 ipsec,debug 03000008 03000002 00000008 0400000e
11:27:40 ipsec ← ike2 request, exchange: SA_INIT:0 35.204.xx.xx[4500]
11:27:40 ipsec,debug ===== sending 424 bytes from 94.237.xx.xx[4500] to 35.204.xx.xx[4500]
11:27:40 ipsec,debug 1 times of 428 bytes message will be sent to 35.204.xx.xx[4500]
11:27:47 ipsec ike2 init retransmit
11:27:47 ipsec,debug ===== sending 424 bytes from 94.237.xx.xx[4500] to 35.204.xx.xx[4500]
11:27:47 ipsec,debug 1 times of 428 bytes message will be sent to 35.204.xx.xx[4500]
11:27:52 ipsec ike2 init retransmit
11:27:52 ipsec,debug ===== sending 424 bytes from 94.237.xx.xx[4500] to 35.204.xx.xx[4500]
11:27:52 ipsec,debug 1 times of 428 bytes message will be sent to 35.204.xx.xx[4500]
11:27:57 ipsec ike2 init retransmit
11:27:57 ipsec,debug ===== sending 424 bytes from 94.237.xx.xx[4500] to 35.204.xx.xx[4500]
11:27:57 ipsec,debug 1 times of 428 bytes message will be sent to 35.204.xx.xx[4500]
11:28:02 ipsec ike2 init timeout
11:28:10 ipsec ike2 starting for: 35.204.xx.xx
11:28:10 ipsec adding notify: NAT_DETECTION_DESTINATION_IP
11:28:10 ipsec,debug => (size 0x1c)
11:28:10 ipsec,debug 0000001c 00004005 a5cc0ab1 7dfedc3b 6fa7b1cb 4d6fe469 61c0622b
11:28:10 ipsec adding notify: NAT_DETECTION_SOURCE_IP
11:28:10 ipsec,debug => (size 0x1c)
11:28:10 ipsec,debug 0000001c 00004004 56d2815f 3c6ebb24 2e003140 20e47d9e e5122910
11:28:10 ipsec adding payload: NONCE
11:28:10 ipsec,debug => (size 0x1c)
11:28:10 ipsec,debug 0000001c f0eb685e 91029382 2b2fd701 54bb6824 6d078d5e 71f503f5
11:28:10 ipsec adding payload: KE
11:28:10 ipsec,debug => (first 0x100 of 0x108)
11:28:10 ipsec,debug 00000108 000e0000 6f7c20b1 f6471ccf fba103f9 7c1bd7be f29f2519 4a872134
11:28:10 ipsec,debug 85664a1f a9aa4e39 cee2e703 4e18c774 785f1bf3 616938fb 096ac1eb 007d98f2
11:28:10 ipsec,debug 48fcd14e 35fa6c78 51b28d29 f77abceb af777fbd cb1c03cd 7cafbec9 4a9e80e7
11:28:10 ipsec,debug 0f5bfb2d 7ceb1c1f 25f70b44 96dca1e1 c6d11b16 39f93464 fa81438a 6f41f3ca
11:28:10 ipsec,debug a09f2c65 d967094e 7379f3c5 30b0aecb af26d72d ca016b9e fb9eb749 473bb5a6
11:28:10 ipsec,debug 1b0aa968 a039ff69 254f9281 77e24132 6ddc6d34 de3e7cab b7196669 30a136cd
11:28:10 ipsec,debug f7b39258 64b2a194 283e2bc3 805fa1c5 dc85012c a6010f6a 6e49c03c dd536aa8
11:28:10 ipsec,debug 1f4c557c ca1d540e 838adb54 84ba8973 a424eeef 24daf19b 304310da 38e5c199
11:28:10 ipsec adding payload: SA
11:28:10 ipsec,debug => (size 0x30)
11:28:10 ipsec,debug 00000030 0000002c 01010004 0300000c 0100000c 800e0080 03000008 02000002
11:28:10 ipsec,debug 03000008 03000002 00000008 0400000e
11:28:10 ipsec ← ike2 request, exchange: SA_INIT:0 35.204.xx.xx[4500]
11:28:10 ipsec,debug ===== sending 424 bytes from 94.237.xx.xx[4500] to 35.204.xx.xx[4500]
11:28:10 ipsec,debug 1 times of 428 bytes message will be sent to 35.204.xx.xx[4500]

Ok I manage to change routing and suddenly more connectivity started to log as something fall out

11:40:02 ipsec peer selected tunnel mode
11:40:02 ipsec mode change not supported

And I see this.

17

The “ipsec,info,account peer authorized” message which you’ve posted before is missing in this log, so the timeout is a different issue than in the previous case.

18

Yeah but as you see can figure it out why. And timeouts are gone now now I have issues with mode and also when settings mode (my-id to fqdn)

[konrad@MikroTik] /ip ipsec policy> ..identity pr
Flags: D - dynamic, X - disabled
0 peer=ike-gcp_casino auth-method=pre-shared-key my-id=fqdn:94.237.xx.xx secret=“xxxx” generate-policy=port-override



12:08:39 ipsec → ike2 reply, exchange: AUTH:1 35.204.xx.xx[4500]
12:08:39 ipsec payload seen: ENC (48 bytes)
12:08:39 ipsec processing payload: ENC
12:08:39 ipsec,debug => iv (size 0x10)
12:08:39 ipsec,debug a0028764 00a8d9d7 669c6e9f e13afa7b
12:08:39 ipsec,debug => plain payload (trimmed) (size 0x8)
12:08:39 ipsec,debug 00000008 00000018
12:08:39 ipsec,debug decrypted
12:08:39 ipsec payload seen: NOTIFY (8 bytes)
12:08:39 ipsec processing payloads: NOTIFY
12:08:39 ipsec notify: AUTHENTICATION_FAILED
12:08:39 ipsec,error got fatal error: AUTHENTICATION_FAILED

Or should I set my new template ?

GCP sends

insertId: “c7lbfvg25fd285”
labels: {…}
logName: “projects/casino-front/logs/cloud.googleapis.com%2Fipsec_events”
receiveTimestamp: “2020-06-29T09:24:10.998457933Z”
resource: {…}
severity: “DEBUG”
textPayload: “generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]”
timestamp: “2020-06-29T09:24:10.972873297Z”

@sindy I have no idea why it stopped working

Ok the issue was with Firewall. I had previously in firewall raw some prerouting entries which I removed and I don’t know why they don’t add again although I set here

/ip ipsec identity
add generate-policy=port-strict notrack-chain=prerouting peer=ike-gcp_casino secret=xxxx

notrack-chain=prerouting


and how to proceed with BGP ?

19

So are you saying that now you have a running tunnel, i.e. there is an installed-sa generated from the template?

20

Ok to make some clearness what’s going on now.

/ip ipsec policy
add action=none dst-address=10.99.6.0/24 src-address=0.0.0.0/0
add action=none dst-address=10.0.0.0/13 src-address=0.0.0.0/0
set 2 proposal=GCP_phase2
add dst-address=169.254.1.2/32 peer=ike-gcp_casino proposal=GCP_phase2 sa-dst-address=35.204.xx.xx sa-src-address=94.237.xx.xx src-address=169.254.1.1/32 tunnel=yes

That’s what I added

[konrad@MikroTik] /ip ipsec identity> ..policy pr
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default
 #     PEER                                            TUNNEL SRC-ADDRESS                                                                           DST-ADDRESS                                                                           PROTOCOL   ACTION  LEVEL    PH2-COUNT
 0                                                            0.0.0.0/0                                                                             10.99.6.0/24                                                                          all        none
 1                                                            0.0.0.0/0                                                                             10.0.0.0/13                                                                           all        none
 2 T *                                                        ::/0                                                                                  ::/0                                                                                  all
 3  A  ike-gcp_casino                                  yes    169.254.1.1/32                                                                        169.254.1.2/32                                                                        all        encrypt require          1
 4  DA  ike-gcp_casino                                  yes    0.0.0.0/0                                                                             35.204.xx.xx/32                                                                      all        encrypt unique           1

I had to add BGP like that to establish connections
( Received entries
3 ADb 10.101.0.0/16 169.254.1.2 20
)
but when I want to ping for instance from
10.99.6.2 (which is mikrotik) to a host in GCP 10.101.13.250
I get timeout.

[konrad@MikroTik] /ip ipsec identity> /tool traceroute address=10.101.13.250
 # ADDRESS                          LOSS SENT    LAST     AVG    BEST   WORST STD-DEV STATUS
 1 94.237.xx.xx                     66..   31     0ms   197.6       0   988.7   395.2 host unreachable from 94.237.xx.xx

I think that without ipsec policy it will not go through tunnel like the BGP didn’t went through.. and this is something we cannot do as this is the main reason we try to push 0.0.0.0/0 <=> 0.0.0.0/0
And answering finally your questions
Yes tunnel is up

Flags: H - hw-aead, A - AH, E - ESP
0 E spi=0x1D64599 src-address=35.204.xx.xx dst-address=94.237.xx.xx state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=256 auth-key=“f36938f75178530fa65600cabde1015f9ca9733e9e7f8158910f0a2fb60cbb46”
enc-key=“71a695dd8e04c2117c1f672c1386ab237791ead7e596b7fbff79a6aa26f5b71d” addtime=jun/29/2020 14:36:21 expires-in=1h10m22s add-lifetime=2h24m19s/3h24s current-bytes=189600 current-packets=3160 replay=128

1 E spi=0xD1C79D38 src-address=94.237.xx.xx dst-address=35.204.xx.xx state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=256 auth-key=“f38ced110cb246b66eeab648b2cafe709a4f215a4ee46d47dabab3d9f346ea9f”
enc-key=“85205ae97a803ec5f1f6a29316d83e533c7009d37e6232d40ca4ca1d456ff26e” add-lifetime=2h24m19s/3h24s replay=128

2 E spi=0x93CFCD7 src-address=35.204.xx.xx dst-address=94.237.xx.xx state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=256 auth-key=“0408aac30d5f47d8122e18ce59c51610883c47f9c0205a5324736280a206545c”
enc-key=“e25b17c33ecf846ff3ea40bfa5e44d2dce5418731bbbfb111f670b3e2475463f” addtime=jun/29/2020 15:02:52 expires-in=1h36m57s add-lifetime=2h24m22s/3h28s current-bytes=489017 current-packets=5964 replay=128

3 E spi=0x2013652C src-address=94.237.xx.xx dst-address=35.204.xx.xx state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc enc-key-size=256 auth-key=“bbe1a9483bd32acc69c10453541ed253c8c265305c2bdd064510badb4c4afc10”
enc-key=“3e09b65774d4c95ffa8ffdf0e4ed615aedd2512c78b0291916837c53d15ca1a8” addtime=jun/29/2020 15:02:52 expires-in=1h36m57s add-lifetime=2h24m22s/3h28s current-bytes=35991 current-packets=574 replay=128