Help with IKEv2

bekax5 · Sat Aug 11, 2018 1:57 pm

Hello everyone,
I'm trying to setup IKEv2 between my RB3011 and an iPhone.

I've been fighting against the authentication, but finally I seem to have it figured out and it appears to be a bug which I would like to report first.
I am using WinBox 3.17 and RB3011 v6.43rc51

# If I check in IPsec Peer Proposal "SHA256" this happens:
1   name="proposal1" hash-algorithm=(unknown) enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d proposal-check=obey
# If I check "SHA1" this happens:
1   name="proposal1" hash-algorithm=sha256 enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d proposal-check=obey

It is either a bug with winbox which does not correctly match the checkboxes to the right Hash algorithm, or something else...

What I am dealing with now appears to be a routing and/or firewall problem.
The phone authenticates, gets an IP and shows as connected.
However I try to open the webfig via the router's address but nothing shows.
I packet sniffed, and the iPhone traffic appears to be coming from the Internet interface and with private IP given by the ikev2_pool.
Also something which I am not sure if is right, traffic only comes in udp:500 and udp:4500, no packets in protocol "ipsec-esp" or "ipsec-ah".

How does one correctly configure routes/firewall to allow the IKEv2 client to talk with LAN devices and also access Internet?
Or is there a way to associate IKEv2 clients to a new bridge?!?

sindy · Sat Aug 11, 2018 3:27 pm

Or is there a way to associate IKEv2 clients to a new bridge?!?

With plain IPsec, routing works very different from the standard one. After all the standard routing is done and the packet is just about to be sent out, its source and destination IP addresses are compared to active IPsec policies and if they match, the packet is sent using the security association linked to that policy instead of the original route. There is no interface representing the IPsec client, which could eventually be made a member port of a bridge.

How does one correctly configure routes/firewall to allow the IKEv2 client to talk with LAN devices and also access Internet?

IPsec policy matching is skipped for packets belonging to fasttracked connections, and if the original route for the packets goes out the WAN to which a masquerade rule is related, the src-nat operation is done before policy matching, so the match may fail too. The IPsec manual page mentions both these cases.

I packet sniffed, and the iPhone traffic appears to be coming from the Internet interface and with private IP given by the ikev2_pool.
Also something which I am not sure if is right, traffic only comes in udp:500 and udp:4500, no packets in protocol "ipsec-esp" or "ipsec-ah".

If there is a NAT between the iPhone and the Mikrotik, which I suppose to be the case if the iPhone is using mobile network rather than WiFi, ESP has to be encapsulated into UDP. If you sniff into a file and open that file using Wireshark, it will show you that there is ESP inside the UDP packets coming to port 4500.

bekax5 · Sat Aug 11, 2018 6:42 pm

With plain IPsec, routing works very different from the standard one. After all the standard routing is done and the packet is just about to be sent out, its source and destination IP addresses are compared to active IPsec policies and if they match, the packet is sent using the security association linked to that policy instead of the original route. There is no interface representing the IPsec client, which could eventually be made a member port of a bridge.

Alright, so I believe leaving it as is might be the best option

IPsec policy matching is skipped for packets belonging to fasttracked connections, and if the original route for the packets goes out the WAN to which a masquerade rule is related, the src-nat operation is done before policy matching, so the match may fail too. The IPsec manual page mentions both these cases.

According tho the link you posted, I should add rules for NAT bypass and Fasttrack bypass.
However I see that the example is between two static issued routers. Against a mobile client and ikev2 server which both have dynamic IPs would it be an issue?
I assume I can still create the same rules if they are matched against the private IKEv2 client IP?

If there is a NAT between the iPhone and the Mikrotik, which I suppose to be the case if the iPhone is using mobile network rather than WiFi, ESP has to be encapsulated into UDP. If you sniff into a file and open that file using Wireshark, it will show you that there is ESP inside the UDP packets coming to port 4500.

I think I remember there was an option called NAT-Traversal ?
Is this still a thing, or somehow the protocol/routerOS is now able to find out it is behind a NAT and already enables this by default?

sindy · Sat Aug 11, 2018 6:58 pm

According tho the link you posted, I should add rules for NAT bypass and Fasttrack bypass.
However I see that the example is between two static issued routers. Against a mobile client and ikev2 server which both have dynamic IPs would it be an issue?
I assume I can still create the same rules if they are matched against the private IKEv2 client IP?

IPsec is IPsec regardless for what type of connection it is used, it doesn't matter whether it is used between two routers or between a router and roaming client. So yes, you have to make the exceptions from fasttracking and NAT for packets whose dst-address matches the private one assigned to the client, as these are the packets which the IPsec policy has to match.

I think I remember there was an option called NAT-Traversal ?
Is this still a thing, or somehow the protocol/routerOS is now able to find out it is behind a NAT and already enables this by default?

The NAT-Traversal option is an option for IKE(v1); in case of IKEv2 it is an intrinsic part. The existence of NAT in the path is not the cause of your trouble, I've only menioned it to explain why you cannot see ESP packets in the sniff.

bekax5 · Sun Aug 12, 2018 1:54 am

Perfect!

At first it was not working, it seems I had yet to add an accept firewall input rule for in:ipsec policy since these packets were being dropped by my generic WAN input drop rule.

add action=accept chain=input in-interface=bridge-vlan12 ipsec-policy=in,ipsec
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=bridge-vlan12

But for now I am able to connect to everything in the remote LAN.

I am yet to understand if it is forwarding Internet traffic, since everywhere I check IP when connected to the IKEv2 in iPhone, it is showing the cell network IP and not the remote IKEv2 connection IP.

sindy · Sun Aug 12, 2018 10:25 am

I am yet to understand if it is forwarding Internet traffic, since everywhere I check IP when connected to the IKEv2 in iPhone, it is showing the cell network IP and not the remote IKEv2 connection IP.

The Note in this section of the Mikrotk IPsec manual is related to this.

Many VPN clients on other systems (Windows, Android) use the tunnel as the default gateway and people seek ways how to disable this behaviour; iOS seems to do the opposite and not to accept a prefix 0.0.0.0/0 (any IP address). So if you want the iOS device to access the whole internet via the IPsec tunnel, try to use two split-include prefixes, 0.0.0.0/1 and 128.0.0.0/1, instead of 0.0.0.0/0. There is a chance that doing so might cause a routing loop in the iOS where IPsec control and transport packets would be caught by IPsec policy; if this is the case, you will have to use 32 prefixes which will cover the whole internet except your Mikrotik's public address.

If you add those two prefixes and the tunnel gets up but doesn't work, remove the prefix which matches your Mikrotik's public IP address and try again. If it then works and you can see that traffic to addresses matching the remaining one of the two prefixes goes via the tunnel, come back for the rest of the story.

bekax5 · Sun Aug 12, 2018 4:59 pm

I am yet to understand if it is forwarding Internet traffic, since everywhere I check IP when connected to the IKEv2 in iPhone, it is showing the cell network IP and not the remote IKEv2 connection IP.
The Note in this section of the Mikrotk IPsec manual is related to this.

Many VPN clients on other systems (Windows, Android) use the tunnel as the default gateway and people seek ways how to disable this behaviour; iOS seems to do the opposite and not to accept a prefix 0.0.0.0/0 (any IP address). So if you want the iOS device to access the whole internet via the IPsec tunnel, try to use two split-include prefixes, 0.0.0.0/1 and 128.0.0.0/1, instead of 0.0.0.0/0. There is a chance that doing so might cause a routing loop in the iOS where IPsec control and transport packets would be caught by IPsec policy; if this is the case, you will have to use 32 prefixes which will cover the whole internet except your Mikrotik's public address.

If you add those two prefixes and the tunnel gets up but doesn't work, remove the prefix which matches your Mikrotik's public IP address and try again. If it then works and you can see that traffic to addresses matching the remaining one of the two prefixes goes via the tunnel, come back for the rest of the story.

First, Thanks a lot for the explanations and your time.

I tried with several different configs, "0.0.0.0/0", "0.0.0.0/1 + 128.0.0.0/1", but none of it works!
I'm afraid packets might be dropped by the firewall for some reason.
I tried reading most of the wiki regarding IPsec firewall but I can't seem to grasp what I am missing.

/ip firewall filter
add action=accept chain=input comment="IKEv2 Server" dst-port=500 in-interface=bridge-vlan12 protocol=udp
add action=accept chain=input in-interface=bridge-vlan12 protocol=ipsec-esp
add action=accept chain=input in-interface=bridge-vlan12 protocol=ipsec-ah
add action=accept chain=input dst-port=4500 in-interface=bridge-vlan12 protocol=udp
add action=accept chain=input dst-port=1701 in-interface=bridge-vlan12 protocol=udp
add action=accept chain=input in-interface=bridge-vlan12 ipsec-policy=in,ipsec
/ip firewall nat
add action=accept chain=srcnat comment="IKEv2 NAT Bypass" dst-address=192.168.200.0/24
/ip firewall raw
add action=notrack chain=prerouting comment="IKEv2 Fasttrack bypass - Able to reach IPsec Policies" src-address=192.168.200.0/24
add action=notrack chain=prerouting dst-address=192.168.200.0/24

I think it's safe to assume all packets that don't get caught in these rules are dropped.
I keep seeing packets being sent to the router from the private IKEv2 client IP, but no reply is sent.

I though,

add action=accept chain=input in-interface=bridge-vlan12 ipsec-policy=in,ipsec

would be enough to allow everything after connecting to be forwarded as expected.

Would you mind taking a look at these and check if I am missing something else?

sindy · Sun Aug 12, 2018 5:09 pm

I think it's safe to assume all packets that don't get caught in these rules are dropped.

It is not safe to assume this, and this firewall actually protects nothing at all. The reason is that in RouterOS, the default packet handling in the /ip firewall filter is action=accept, so whatever does not match any rule in chain=input chain is let in to the Mikrotik itself, and whatever does not match any rule in chain=forward is forwarded by the Mikrotik.

Have a look here for details.

I'd recommend to fix your firewall first and then get back to the IPsec access.

Other than that, there is a missing NAT rule in your firewall, which means that even if the iPhone sends a packet to some address in the internet via the IPsec tunnel, Mikrotik forwards that packet with source address unchanged, so the response from the server in the internet cannot get back to it and gets routed to that private address in the local context of the responding server.

bekax5 · Mon Aug 13, 2018 5:36 am

I think it's safe to assume all packets that don't get caught in these rules are dropped.
It is not safe to assume this, and this firewall actually protects nothing at all. The reason is that in RouterOS, the default packet handling in the /ip firewall filter is action=accept, so whatever does not match any rule in chain=input chain is let in to the Mikrotik itself, and whatever does not match any rule in chain=forward is forwarded by the Mikrotik.

Have a look here for details.

I'd recommend to fix your firewall first and then get back to the IPsec access.

Other than that, there is a missing NAT rule in your firewall, which means that even if the iPhone sends a packet to some address in the internet via the IPsec tunnel, Mikrotik forwards that packet with source address unchanged, so the response from the server in the internet cannot get back to it and gets routed to that private address in the local context of the responding server.

I mean't safe for the purposes of IKEv2 discussion.
I have some generic rules that block all traffic after these.

Unfortunately I spent the entire afternoon trying to fix this but still unable.
LAN traffic works perfect though.

Which NAT rule you mean?
I see traffic going in from the IPsec client, but nothing goes to the internet.

sindy · Mon Aug 13, 2018 9:46 am

Post the complete /ip firewall export then. Need to guess complicates the process.

Post also /ip ipsec policy print while the client is connected. Edit the public addresses as per my automatic signature.

bekax5 · Mon Aug 13, 2018 7:17 pm

I was trying to avoid posting too much rules...

/ip firewall filter
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related" connection-state=established,related
add action=accept chain=input comment="defconf: accept establieshed,related" connection-state=established,related
add action=drop chain=input comment="Drop Blacklisted" src-address-list=Blacklist
add action=drop chain=forward src-address-list=Blacklist
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="DVR VPN Input Drop" src-address=192.168.1.157-192.168.1.159
add action=accept chain=input comment="PPTP Server" dst-port=1723 protocol=tcp
add action=accept chain=input protocol=gre
add action=accept chain=input comment="OpenVPN Server" disabled=yes dst-port=5060 protocol=tcp
add action=accept chain=input comment="IKEv2 Server" dst-port=500 in-interface=bridge-vlan12 protocol=udp
add action=accept chain=input in-interface=bridge-vlan12 protocol=ipsec-esp
add action=accept chain=input in-interface=bridge-vlan12 protocol=ipsec-ah
add action=accept chain=input dst-port=4500 in-interface=bridge-vlan12 protocol=udp
add action=accept chain=input dst-port=1701 in-interface=bridge-vlan12 protocol=udp
add action=accept chain=input in-interface=bridge-vlan12 ipsec-policy=in,ipsec src-address=192.168.200.0/24
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=bridge1
add action=drop chain=input in-interface=bridge-vlan12
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface=bridge1
add action=drop chain=forward connection-nat-state=!dstnat connection-state=new in-interface=bridge-vlan12

/ip firewall mangle
add action=change-mss chain=forward comment="Clamp MSS to PMTU" new-mss=clamp-to-pmtu out-interface=bridge-local passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=8159-65535
add action=change-mss chain=forward in-interface=bridge-local new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=8159-65535

/ip firewall nat
add action=accept chain=srcnat comment="IKEv2 NAT Bypass" dst-address=192.168.200.0/24
add action=accept chain=srcnat src-address=192.168.200.0/24
add action=src-nat chain=srcnat disabled=yes dst-address=192.168.0.0/24 to-addresses=192.168.0.250
add action=masquerade chain=srcnat comment="Rule for HairPin NAT" disabled=yes dst-address=192.168.0.0/24 out-interface=bridge1 protocol=tcp src-address=192.168.1.0/24
add action=masquerade chain=srcnat dst-address=192.168.1.0/24 out-interface=bridge-local protocol=tcp src-address=192.168.1.0/24
# pptp-out1 not ready
add action=masquerade chain=srcnat comment="Masquerade for pptp-out1" out-interface=pptp-out1
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=bridge1
add action=masquerade chain=srcnat out-interface=bridge-vlan12
add action=dst-nat chain=dstnat comment="Port Forwarding" disabled=yes dst-address-type=local dst-port=21 protocol=tcp to-addresses=192.168.1.18 to-ports=21
add action=dst-nat chain=dstnat dst-address-type=local dst-port=22 protocol=tcp to-addresses=192.168.1.3 to-ports=22
add action=dst-nat chain=dstnat dst-address-type=local dst-port=443 protocol=tcp to-addresses=192.168.1.3 to-ports=443

/ip firewall raw
add action=notrack chain=prerouting comment="IKEv2 Fasttrack bypass - Able to reach IPsec Policies" src-address=192.168.200.0/24
add action=notrack chain=prerouting dst-address=192.168.200.0/24

/ip ipsec policy
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
0 T * group=default src-address=0.0.0.0/0 dst-address=192.168.200.0/24 protocol=all proposal=default template=yes 
1  DA  src-address=192.168.1.0/24 src-port=any dst-address=192.168.200.199/32 dst-port=any protocol=all action=encrypt level=unique ipsec-protocols=esp tunnel=yes sa-src-address=IKEV2_SERVER_PUBLIC_IP sa-dst-address=CLIENT_PUBLIC_IP proposal=default ph2-count=1

At the moment split-include has only internal LAN ip since I was unable to figure out why both /1 ranges would work as expected.
Would you want a print of ipsec policy with the two split-include ranges?

sindy · Mon Aug 13, 2018 7:20 pm

I was trying to avoid posting too much rules...

Posting anything less than all rules creates space for missing something important.

Would you want a print of ipsec policy with the two split-include ranges?

Better yes.

sindy · Mon Aug 13, 2018 7:29 pm

The /ip firewall nat rule action=accept chain=srcnat src-address=192.168.200.0/24 prevents packets coming from the IPsec client from being src-nat'ed as they get forwarded to the internet because for those packets it shadows the action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=bridge1 one, so the responses never come back. If you need to prevent the part of these packets whose destination is not in the internet, you have to add additional conditions (like out-interface=!bridge1) to that shadowing rule.

bekax5 · Thu Aug 16, 2018 8:55 pm

Now with both ipv4 range halves

[admin@MikroTik-RB3011] /ip ipsec policy> print 
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 0 T * group=default src-address=0.0.0.0/0 dst-address=192.168.200.0/24 protocol=all proposal=default template=yes 

 1  DA  src-address=0.0.0.0/1 src-port=any dst-address=192.168.200.196/32 dst-port=any protocol=all action=encrypt level=unique ipsec-protocols=esp tunnel=yes sa-src-address=IKEV2_SERVER_PUBLIC_IP sa-dst-address=CLIENT_PUBLIC_IP proposal=default ph2-count=1

That rule never got any traffic though..
I thought I needed to bypass NAT as well, but from what I understood that impedes tunneled packets to go to the internet because they won't reach the masquerade rule for internet traffic, is that correct?
I disabled that one.

By the way, bridge-vlan12 is the internet interface.

sindy · Thu Aug 16, 2018 10:37 pm

Supposing that your mode-config's split-include contains both 0.0.0.0/1 and 128.0.0.0/1 and only the policy with src-address=0.0.0.0/1 has been dynamically created, there are two possibilities:

the iOS client supports only a single policy,
the iOS ignores any policy which would match the IPsec transport packets to avoid cutting off itself.

Solely to find out which of these two possibilities is true, set the split-include to 0.0.0.0/3 and 64.0.0.0/3 (these are intentionally non-adjacent subnets in order to avoid additional doubts). If only one of them gets established, it is case a. above; if both get established, it is case b.

Regarding the NAT: the point is that the NAT handling is applied before the ipsec policies match the packets. So if the subnet of the IPSec client is e.g. 192.168.10.0/24 but there is no "normal" route with this subnet as dst-address, packets towards this subnet are routed using the default route which goes via WAN to which a src-nat/masquerade rule is attached. And you need to prevent only packets to that subnet from being src-nat'ed if the policy's src-address is not 0.0.0.0/0 but some more narrow subnet. Packets from that subnet towards internet must be src-nat'ed normally before being sent out via the WAN. But if you say that that rule hasn't counted any packets, it seems that the packets from the IPsec client have not reached that rule.

bekax5 · Fri Aug 17, 2018 2:16 pm

[admin@MikroTik-RB3011] /ip ipsec> mode-config print 
Flags: * - default, R - responder 
 0 *  name="request-only" responder=no 

 1  R name="ikev2-config" system-dns=no static-dns=192.168.1.250 address-pool=pool_ikev2_1 address-prefix-length=32 split-include=0.0.0.0/3,64.0.0.0/3 
[admin@MikroTik-RB3011] /ip ipsec> policy print      
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 0 T * group=default src-address=0.0.0.0/0 dst-address=192.168.200.0/24 protocol=all proposal=default template=yes 

 1  DA  src-address=0.0.0.0/3 src-port=any dst-address=192.168.200.194/32 dst-port=any protocol=all action=encrypt level=unique ipsec-protocols=esp tunnel=yes sa-src-address=IKEV2_SERVER_PUBLIC_IP sa-dst-address=CLIENT_PUBLIC_IP proposal=default ph2-count=1

So it appears that iphone client only supports single policy!
I tried with the four /4 subnets and only 0.0.0.0/4 appears.
We can assume this is due to the client even though this is just the mtik side?

In this case I guess I can only route half the internet via IKEv2 right?

sindy · Fri Aug 17, 2018 4:28 pm

We can assume this is due to the client even though this is just the mtik side?

The precise answer is in the log, but between two Mikrotiks a mode-config with split-include indicating two prefixes configured at the responder side creates both policies at both ends.

In this case I guess I can only route half the internet via IKEv2 right?

Yes, so practically unusable for tunnelling internet access. Unless there is some magic setting hidden deep in the embedded iOS client's configuration, it can only be used for access to home/corporate network with some additional limitations.

A quick googling has found the Greenbow client for iOS which promises to support custom traffic selectors which is another name for ipsec policies, but I have no information about this product whatsoever nor I am in any way related to it.

Help with IKEv2

Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2

Re: Help with IKEv2