Community discussions

 
User avatar
bekax5
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 71
Joined: Thu Apr 30, 2015 11:27 pm

Help with IKEv2

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
Forum Guru
Forum Guru
Posts: 1955
Joined: Mon Dec 04, 2017 9:19 pm

Re: Help with IKEv2

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace each occurrence of any public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
bekax5
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 71
Joined: Thu Apr 30, 2015 11:27 pm

Re: Help with IKEv2

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
Forum Guru
Forum Guru
Posts: 1955
Joined: Mon Dec 04, 2017 9:19 pm

Re: Help with IKEv2

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace each occurrence of any public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
bekax5
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 71
Joined: Thu Apr 30, 2015 11:27 pm

Re: Help with IKEv2

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
Forum Guru
Forum Guru
Posts: 1955
Joined: Mon Dec 04, 2017 9:19 pm

Re: Help with IKEv2

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace each occurrence of any public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
bekax5
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 71
Joined: Thu Apr 30, 2015 11:27 pm

Re: Help with IKEv2

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
Forum Guru
Forum Guru
Posts: 1955
Joined: Mon Dec 04, 2017 9:19 pm

Re: Help with IKEv2

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace each occurrence of any public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
bekax5
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 71
Joined: Thu Apr 30, 2015 11:27 pm

Re: Help with IKEv2

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
Forum Guru
Forum Guru
Posts: 1955
Joined: Mon Dec 04, 2017 9:19 pm

Re: Help with IKEv2

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace each occurrence of any public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
bekax5
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 71
Joined: Thu Apr 30, 2015 11:27 pm

Re: Help with IKEv2

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
Forum Guru
Forum Guru
Posts: 1955
Joined: Mon Dec 04, 2017 9:19 pm

Re: Help with IKEv2

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace each occurrence of any public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
sindy
Forum Guru
Forum Guru
Posts: 1955
Joined: Mon Dec 04, 2017 9:19 pm

Re: Help with IKEv2

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.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace each occurrence of any public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: Google [Bot], SumTingWong and 19 guests