ipsec ikev2 vpn doesn't do his work

Hello,

I have model RB760iGS (Hex S).
Trying to set up vpn to privateinternetaccess peer via ipsec mode-config.

Configuration
/ip ipsec:

/ip ipsec mode-config
add connection-mark=via-vpn-pia-uk name=pia-uk responder=no
/ip ipsec policy group
add name=pia
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha512 name=pia
/ip ipsec peer
add address=uk-london.privateinternetaccess.com exchange-mode=ike2 name=pia-uk profile=pia
/ip ipsec proposal
add enc-algorithms=aes-128-cbc name=pia pfs-group=modp2048
/ip ipsec identity
add auth-method=eap certificate="" eap-methods=eap-mschapv2 generate-policy=port-strict mode-config=pia-uk notrack-chain=prerouting password=\
    verystrongpassword peer=pia-uk policy-template-group=pia remote-id=fqdn:*.privateinternetaccess.com username=x0000000
/ip ipsec policy
add dst-address=0.0.0.0/0 group=pia proposal=pia src-address=0.0.0.0/0 template=yes

/ip firewall:

/ip firewall address-list
add address=10.0.10.0/24 list=nat-internet
add address=10.0.30.0/24 list=nat-internet
add address=10.0.50.0/24 list=nat-internet
add address=10.0.110.0/24 list=nat-internet
add address=192.168.130.0/24 list=nat-internet
add address=10.0.0.0/8 list="Private Networks RFC 1918"
add address=192.168.0.0/16 list="Private Networks RFC 1918"
add address=172.16.0.0/12 list="Private Networks RFC 1918"
add address=127.0.0.0/8 list="Loopback adresses"
/ip firewall filter
add action=drop chain=input in-interface-list=wan src-address-list="Local Networks RFC 4193"
add action=drop chain=input in-interface-list=wan src-address-list="Private Networks RFC 1918"
add action=accept chain=input in-interface-list=lan protocol=icmp
add action=accept chain=input connection-state=new dst-port=80,8291,22 protocol=tcp src-address=10.0.2.0/24
add action=accept chain=input dst-port=163 protocol=udp src-address=10.0.2.1
add action=accept chain=input connection-state=new dst-port=53,123 in-interface-list=lan protocol=udp
add action=accept chain=input comment="accept established, related, untracked" connection-state=established,related,untracked
add action=accept chain=output connection-state=!invalid
add action=accept chain=forward in-interface-list=lan-trusted out-interface-list=lan-trusted
add action=accept chain=forward connection-state=established,new in-interface-list=lan out-interface-list=wan
add action=accept chain=forward connection-state=established,related in-interface-list=wan out-interface-list=lan
add action=drop chain=forward comment="drop ALL from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-inter
add action=drop chain=input log-prefix=drop-input
add action=drop chain=output log-prefix=drop-output
add action=drop chain=forward log-prefix=drop-forward
/ip firewall mangle
add action=mark-routing chain=prerouting new-routing-mark=blackhole passthrough=yes src-address=10.0.31.0/24
add action=mark-connection chain=prerouting new-connection-mark=via-vpn-pia-uk passthrough=yes src-address=10.0.31.0/24
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1-wan src-address-list=nat-internet

_Some type of kill-swich feature based on topic http://forum.mikrotik.com/t/blackhole-unreachable-with-ipsec-policies/131549/1

/interface bridge
add name=bridge2-blackhole
/ip route
add distance=1 gateway=bridge2-blackhole routing-mark=blackhole

ip firewall nat and mangle after successful connection to peer

/ip firewall raw print
Flags: X - disabled, I - invalid, D - dynamic 
 0  D ;;; ipsec policy
      chain=prerouting action=notrack src-address=0.0.0.0/0 dst-address=10.0.3.105 
 1  D ;;; ipsec policy
      chain=prerouting action=notrack src-address=10.0.3.105 dst-address=0.0.0.0/0 

/ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic 
 0  D ;;; ipsec mode-config
      chain=srcnat action=src-nat to-addresses=10.0.3.105 connection-mark=via-vpn-pia-uk 
 1    chain=srcnat action=masquerade src-address-list=nat-internet out-interface=ether1-wan

And it does not work - I can not get access to the Internet via 10.0.31.0/24.

Need some expertise and explanation why it does not work.
Advice what should I do will be very handy too.

In /ip firewall, action=notrack in raw prevents action=src-nat in nat and action=mark-connection in mangle from working, whereas the “IKEv2 initiator with mode-config” setup, where you get a single address from the remote responder, depends on the NAT to be working.

The exclusion of IPsec traffic from connection tracking (and thus saving CPU and permitting it without limitations thanks to an “accept connection-state=…,untracked,…” rule in /ip firewall filter) by means of the action=notrack in raw is suitable for other IPsec application scenarios than this (mostly site to site VPN).

I removed the Notrack Chain in the identity settings.
Everything works as expected now.

Thank you very much for the explanation.

It works for me and the difference is that I use for the second line output and not prerouting and I put those in manually.

 1    ;;; IKEv2 from GW-router in and out. Make them invisible in connections and using so less processor time. 
      chain=prerouting action=notrack src-address-list=NoTrackIKEV 
 2    chain=output action=notrack dst-address-list=NoTrackIKEV

Your previous config:

 0  D ;;; ipsec policy
      chain=prerouting action=notrack src-address=0.0.0.0/0 dst-address=10.0.3.105 
 1  D ;;; ipsec policy
      chain=prerouting action=notrack src-address=10.0.3.105 dst-address=0.0.0.0/0

In the address-list NoTrackIKEV is/are the server address(es) of the VPN provider.

Ran a short test and without NoTrack I get: 107 down and 160 up (Mbit/s). When using NoTrack this increases a bit and Ihave then 115 down and 185 up (Mbit/s).

When using two routers in series, it increases to 250 down and +300 up (Mbit/s)

To add to what @sindy said, as i think it is important to remind what features are specifically affected when we disable connection tracking…
Those are:

  • NAT


  • firewall:
    connection-bytes
    connection-mark
    connection-type
    connection-state
    connection-limit
    connection-rate
    layer7-protocol
    new-connection-mark
    tarpit

https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Connection_tracking#Features_affected_by_connection_tracking

Also, RAW Table exists in the Prerouting and Output Chains and is always before the Connection Tracking process and Filter Table…
So, even in the case where connection tracking is enabled, if we add a rule in the RAW Table where for a specific host action=notrack, that specific host will loose the ability to use the features in the above list…
https://help.mikrotik.com/docs/display/ROS/Packet+Flow+in+RouterOS

I am hiding the tunnels (UDP 4500) created by the IKEv2 and the ESP (protocol 50) this way in connections. In the upstream router I can’t hide those anymore because there is no IPSEC handling active for those connections. On the upstream I do the the same for the IKEv2 connections that are handled by the IPSEC handler.

Update: I tested with an eye on the load on the processor and NoTrack is ideal for ipsec (protocol 50) and the tunnel (UDP/4500) can be fastracked and that is the fasted method for that.

I can even hide fasttracked untracked traffic but I did not see a advantage in that. I is still strange to me, to be able to fasttrack notracked traffic.

Update 2: A bit further in it seems to be not wise to UnTrack also because then it is not known what are new connections and the counter of the fasttrack setter in Filter goes very fast up. This because it only sees UnTracked traffic without the possibility to see if the packets are new.