Hello everyone
After spending a lot of hours trying to config the server (Ubuntu) and client (Router 4011 (behind NAT-dynamic ip)) it's finally established the tunnel and it's automatically create a NAT rule and there is no internet on devices (I tested the vpn on android client and it's working fine the android phone which is using the same internet as the router) and also I can't ping the server public ip with router. I know firewall and other part should be configurate but I don't know how. I want all of the traffic of the router (all of my devices) route through this IKEV2 vpn. so I would highly appreciate it if any of you can help me with this. also be able to route the traffic of some IPs out of that vpn, for example all traffics are going through VPN except for ip 222.222.222.222. I opened a topic before and got the solution for it but in that time I was using L2TP I don't know if it's the same or not.

I tried setting the address list and set it for mode configs as been said in manual but no difference.

Any idea?

My router configurations:

You are kind of mixing things together (or maybe you don't but it is hard to find out because elements related to both ways are disabled in the config you've posted).

So one way is to ask the responder for a single IP address using the mode-config=request-only on the /ip ipsec identity row; the address will be added as a secondary one to the interface through which the IPsec "session" will establish, and if the src-address-list or connection-mark items are set on the mode-config row, an action=src-nat rule will be dynamically created. But in order that this could happen, generate-policy must be set to something else than no on the respective /ip ipsec identity row, and the default policy template used to generate the policy must not be disabled. And the src-address-list mentioned on the mode-config row should contain IP addresses of devices whose traffic should go via the tunnel (by means of getting src-nated to the address assigned by the responder so that it would match the corresponding policy); the name you use for that list, "Allow Local DNS", suggests you didn't get its purpose properly.

The other way is to set the policy manually and configure the responder to accept it, but in that case, the mode-config setting is redundant; also, when you set the manual policy to 0.0.0.0/0 <-> 0.0.0.0/0, it intercepts even the traffic from the LAN hosts to the router itself, so the devices cannot talk to the router any more.

So describe your what you want to get in plain words, and we can adjust the configuration to fulfil that requirement.

You are kind of mixing things together (or maybe you don't but it is hard to find out because elements related to both ways are disabled in the config you've posted).

I disabled them cause when they are enable I don't have internet on my devices and I simply forgot to turn them back on when I was exporting my settings.
I know what that Src. Address List does but the rule was from before for my firewall filter rules so instead of making another one with the same 192.168.11.0/24 I just simply set the Src. Address List to use it that's why it's name was "Allow Local DNS" from before.
I tried with /ip ipsec policy add dst-address=0.0.0.0/0 peer=ubuntu.xentoo.info proposal=ubuntu.xentoo.info src-address=192.168.43.1/32 tunnel=yes too but same, also like I said in the first post I got that dynamically generated action=src-nat rule before too and now I can ping the ip server too but no data is coming (Rx) but I got (Tx) As you can see here: My Route List: Also I tried with /ip ipsec policy set 0 proposal=ubuntu.xentoo.info the default policy which generate a dynamic one as you can see here: I also tried with port override /ip ipsec identity add auth-method=eap certificate=ca-cert eap-methods=eap-mschapv2 generate-policy=port-override mode-config=request-only password="XXXXX" peer=ubuntu.xentoo.info username=XXXXX and port strict /ip ipsec identity add auth-method=eap certificate=ca-cert eap-methods=eap-mschapv2 generate-policy=port-strict mode-config=request-only password="XXXXX" peer=ubuntu.xentoo.info username=XXXXX
and this is the dynamic action=src-nat: and this is my whole ipsec settings: /ip ipsec mode-config set [ find default=yes ] src-address-list="Allow Local DNS" use-responder-dns=no /ip ipsec profile set [ find default=yes ] dh-group=ec2n185,modp1024 enc-algorithm=aes-256,aes-192,aes-128,3des,des add dh-group=ecp384 dpd-interval=10s enc-algorithm=aes-256 hash-algorithm=sha256 name=ubuntu.xentoo.info nat-traversal=no prf-algorithm=sha256 /ip ipsec peer add address=server public ip/32 exchange-mode=ike2 name=ubuntu.xentoo.info profile=ubuntu.xentoo.info /ip ipsec proposal set [ find default=yes ] auth-algorithms=sha1,md5 enc-algorithms="aes-256-cbc,aes-256-ctr,aes-256-gcm,aes-192-cbc,aes-192-ctr,aes-192-gcm,aes-128-cbc,aes-128-ctr,aes-128-gcm,3des,des" add auth-algorithms=sha256 enc-algorithms=aes-256-cbc,aes-256-ctr name=ubuntu.xentoo.info pfs-group=ecp384 /ip ipsec identity add auth-method=eap certificate=ca-cert eap-methods=eap-mschapv2 generate-policy=port-strict mode-config=request-only password="XXXXX" peer=ubuntu.xentoo.info username=XXXXX /ip ipsec policy set 0 proposal=ubuntu.xentoo.info

I was checking the server and just reboot it (server) and then vpn on router start working: But two question to ask:
1. how can I route an ip or ips out of that vpn? for example: 107.154.106.114
2. how can I route an interface (VLAN or Ether port or Virtual) traffic out of that vpn?

As you use the first approach, i.e. an additional IP address assigned to the initiator router by the responder, I'd say your best bet is to use the connection marking approach for both cases. Instead of src-address-list, set the connection-mark parameter of the /ip ipsec mode-config row to e.g. via-tunnel, so the dynamically created action=src-nat rule will contain a match condition connection-mark=via-tunnel.

And then use dst-address=x.x.x.x action=mark-connection new-connection-mark=via-tunnel and/or in-interface=xxxx action=mark-connection new-connection-mark=via-tunnel rules in chain prerouting or forward of /ip firewall mangle.

IPsec traffic matching only works on IP address, protocol and port number matching and supersedes the result regular routing. So you cannot use IPsec's own means to match on in-interface, you'd have to match using src-address on the subnet linked to each interface, which could be added to the address-list mentioned in the mode-config. And unless you'd create multiple policies, you cannot use direct dst-address matching either.

As you use the first approach

Thank you very much for your help i will check this to see how I can use it for Vlan and virtual.
Is this normal?:

No, it is not normal. The rekeying of the data SA seems to fail and as a consequence, the whole IPsec session gets re-established.

My wild guess is that it is caused by different interpretation of the RFC regarding PFS, try setting pfs-group in proposal to none. In IKEv2, PFS is used always, using the algorithm specified in dh-group in profile, and other setting than none is necessary only for some peers.

IPsec traffic matching only works on IP address, protocol and port number matching and supersedes the result regular routing. So you cannot use IPsec's own means to match on in-interface, you'd have to match using src-address on the subnet linked to each interface, which could be added to the address-list mentioned in the mode-config. And unless you'd create multiple policies, you cannot use direct dst-address matching either.

I didn't understand this part could you please paraphrase it.

No, it is not normal. The rekeying of the data SA seems to fail and as a consequence, the whole IPsec session gets re-established.

My wild guess is that it is caused by different interpretation of the RFC regarding PFS, try setting pfs-group in proposal to none. In IKEv2, PFS is used always, using the algorithm specified in dh-group in profile, and other setting than none is necessary only for some peers.

Thank you very much, I disable peer - identity - policy and then enable them again in order peer => identity => policy and so far for about 1:30 hour it's been running without rekey error, if it's start to show that error again I will change pfs-group to none as you said.

I didn't understand this part could you please paraphrase it.

Once the "normal" routing and firewall processing including NAT is done and the last thing to do is to send the packet out the chosen interface, the IPsec processing compares the source and destination IP address, IP protocol (TCP, UDP, ...), and source and destination port of the packet to the "traffic selectors" of all existing IPsec policies (ports can only be compared if the IP protocol supports the notion of ports of course). If it finds a match, it intercepts the packet, encrypts it, and sends it via the security association linked to that policy rather than via the interface and gateway previously chosen by the regular routing.

There is no other way to force a packet into an IPsec tunnel than making it match the traffic selector of the respective policy. So either its headers mentioned above must match to that policy "natively", or they must be modified in order to match - in most cases, the only value whose modification is harmless is the source address. Which is what the dynamically created src-nat rules do.

Once the "normal" routing and firewall processing including NAT is done and the last thing to do is to send the packet out the chosen interface, the IPsec processing compares the source and destination IP address, IP protocol (TCP, UDP, ...), and source and destination port of the packet to the "traffic selectors" of all existing IPsec policies (ports can only be compared if the IP protocol supports the notion of ports of course). If it finds a match, it intercepts the packet, encrypts it, and sends it via the security association linked to that policy rather than via the interface and gateway previously chosen by the regular routing.

There is no other way to force a packet into an IPsec tunnel than making it match the traffic selector of the respective policy. So either its headers mentioned above must match to that policy "natively", or they must be modified in order to match - in most cases, the only value whose modification is harmless is the source address. Which is what the dynamically created src-nat rules do.

I think you misunderstood my question or I didn't understand your answer, I want to route some websites or at least their IPs out of my VPN, with my current configuration I believe all of the traffics would go trough VPN and I want to keep it this way except for few websites.

I think you misunderstood my question or I didn't understand your answer, I want to route some websites or at least their IPs out of my VPN, with my current configuration I believe all of the traffics would go trough VPN and I want to keep it this way except for few websites.

Okay, yes, with my limited knowledge of English, "to route something out of VPN" may be understood both ways, "via the VPN" or "bypassing the VPN". So I've chosen the more likely understanding, where bulk of traffic bypasses the VPN whereas few exceptions are routed via the VPN. You want the reverse, to exclude a few destinations from being routed via the VPN.

Given how the dynamically created action=src-nat rule is inserted, the method would still be the same - use rules in prerouting chain in mangle to assign or not the connection-mark. So before a common mangle rule assigning the connection-mark, add another rule with action=accept, matching on dst-address-list=excluded-destinations, and put the IPs of the sites you want to be accessed without VPN to that address list.

Or, since your case is specific because you can configure the responder in such a way that it assigns always the same address to the responder, you can remove both the src-address-list and the connection-mark from the /ip ipsec mode-config row and use manual rules in the srcnat chain of nat instead of those in mangle - an action=masquerade one matching on dst-address-list=excluded-destinations, followed by an action=src-nat one with to-addresses set to the address assigned by the initiator.

I think you misunderstood my question or I didn't understand your answer, I want to route some websites or at least their IPs out of my VPN, with my current configuration I believe all of the traffics would go trough VPN and I want to keep it this way except for few websites.

Okay, yes, with my limited knowledge of English, "to route something out of VPN" may be understood both ways, "via the VPN" or "bypassing the VPN". So I've chosen the more likely understanding, where bulk of traffic bypasses the VPN whereas few exceptions are routed via the VPN. You want the reverse, to exclude a few destinations from being routed via the VPN.

Given how the dynamically created action=src-nat rule is inserted, the method would still be the same - use rules in prerouting chain in mangle to assign or not the connection-mark. So before a common mangle rule assigning the connection-mark, add another rule with action=accept, matching on dst-address-list=excluded-destinations, and put the IPs of the sites you want to be accessed without VPN to that address list.

Or, since your case is specific because you can configure the responder in such a way that it assigns always the same address to the responder, you can remove both the src-address-list and the connection-mark from the /ip ipsec mode-config row and use manual rules in the srcnat chain of nat instead of those in mangle - an action=masquerade one matching on dst-address-list=excluded-destinations, followed by an action=src-nat one with to-addresses set to the address assigned by the initiator.

Sorry my bad.

in this case we use src-address-list in the /ip ipsec mode-config row? if not can it be done this way (with src-address-list in the /ip ipsec mode-config row)? because with connection-mark it's would be "bulk of traffic bypasses the VPN whereas few exceptions are routed via the VPN".

It's not working. I add these rules and I got everything is working except that it's not bypassing the VPN for that ip.
add action=masquerade chain=srcnat dst-address-list=111.111.111.111
add action=src-nat chain=srcnat to-addresses=192.168.43.1

It's not "src-address-list in connection-mark". You can specify either or even both on the /ip ipsec mode-config row, and corresponding srcnat rules are created each time the IPsec "session" is established, one per each item. So if you specify both src-address-list=some-list and connection-mark=some-mark, you'll get
D chain=srcnat src-address-list=some-list action=src-nat to-addresses=192.168.43.1
D chain=srcnat connection-mark=some-mark action=src-nat to-addresses=192.168.43.1
In your "manual" case, it's either:
action=masquerade chain=srcnat dst-address-list=111.111.111.111
action=masquerade chain=srcnat dst-address-list=222.222.222.222
(for direct matching on an IP address in each rule), or
action=masquerade chain=srcnat dst-address-list=excluded-addresses
/ip firewall address-list
add list=excluded-addresses address=111.111.111.111
add list=excluded-addresses address=222.222.222.222
(for a list of multiple addresses used to match in single rule common for all of them).

It's not "src-address-list in connection-mark". You can specify either or even both on the /ip ipsec mode-config row, and corresponding srcnat rules are created each time the IPsec "session" is established, one per each item. So if you specify both src-address-list=some-list and connection-mark=some-mark, you'll get
D chain=srcnat src-address-list=some-list action=src-nat to-addresses=192.168.43.1
D chain=srcnat connection-mark=some-mark action=src-nat to-addresses=192.168.43.1
In your "manual" case, it's either:
action=masquerade chain=srcnat dst-address-list=111.111.111.111
action=masquerade chain=srcnat dst-address-list=222.222.222.222
(for direct matching on an IP address in each rule), or
action=masquerade chain=srcnat dst-address-list=excluded-addresses
/ip firewall address-list
add list=excluded-addresses address=111.111.111.111
add list=excluded-addresses address=222.222.222.222
(for a list of multiple addresses used to match in single rule common for all of them).

Yeah sorry I did a last second edit on my post.
It's not working. Not manual case neither dynamic case. it's not bypassing the vpn for 111.111.111.111.

Show me /ip firewall nat print in the "manual" case while the tunnel is up.

Show me /ip firewall nat print in the "manual" case while the tunnel is up.

here you are:
[@MikroTik] > /ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat action=masquerade dst-address-list=79.127.127.21 log=no log-prefix=""

1 chain=srcnat action=src-nat to-addresses=192.168.43.1 log=no log-prefix=""

Now you didn't get me. It's not dst-address-list=79.127.127.21, it's just dst-address=79.127.127.21.

Now you didn't get me. It's not dst-address-list=79.127.127.21, it's just dst-address=79.127.127.21.

Yes It worked, Thank you very much man. I highly appreciate your effort.