Community discussions

MikroTik App
 
gromund
just joined
Topic Author
Posts: 2
Joined: Sun Dec 04, 2022 11:51 am

IPsec/IKEv2 VPN client on hEX S to ProtonVPN

Sun Dec 04, 2022 5:33 pm

I've configured VPN client as described in https://protonvpn.com/support/vpn-mikrotik-router/ on my router 6.42 version, and all was working well. But at some point, after many experiments I thought it would be better to repeat everything on clean unit, so I did reset my device, upgraded to 7.6 (current) and rollout my script. However, now it's not working on the very first step - can't establish connection with remote peer. Internet of course is working.

Here what I do:
/ip ipsec mode-config add connection-mark=under_protonvpn name="Proton VPN mode config" responder=no
/ip ipsec policy group add name="Proton VPN group"
/ip ipsec profile add dh-group=modp4096,modp2048,modp1024 dpd-interval=disable-dpd enc-algorithm=aes-256 hash-algorithm=sha256 name="Proton VPN profile"
/ip ipsec peer add address=169.150.218.91/32 exchange-mode=ike2 name="Proton VPN server" profile="Proton VPN profile"
/ip ipsec proposal add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=0s name="Proton VPN proposal" pfs-group=none
/ip ipsec identity add auth-method=eap certificate="Proton VPN CA" eap-methods=eap-mschapv2 generate-policy=port-strict mode-config="Proton VPN mode config" password=<pwd> peer="Proton VPN server" policy-template-group="Proton VPN group" username=<user>
/ip ipsec policy add dst-address=0.0.0.0/0 group="Proton VPN group" proposal="Proton VPN proposal" src-address=0.0.0.0/0 template=yes
In the log of ipsec topic:
Dec/04/2022 12:42:49 ipsec,debug 0.0.0.0[500] used as isakmp port (fd=11)
Dec/04/2022 12:42:49 ipsec,debug 0.0.0.0[4500] used as isakmp port with NAT-T (fd=13)
Dec/04/2022 12:42:49 ipsec,debug ::[500] used as isakmp port (fd=14)
Dec/04/2022 12:42:49 ipsec,debug ::[4500] used as isakmp port (fd=15)
Dec/04/2022 12:42:51 ipsec ike2 starting for: 169.150.218.91
Dec/04/2022 12:42:54 ipsec adding notify: IKEV2_FRAGMENTATION_SUPPORTED
Dec/04/2022 12:42:54 ipsec,debug => (size 0x8)
Dec/04/2022 12:42:54 ipsec,debug 00000008 0000402e
Dec/04/2022 12:42:54 ipsec adding notify: NAT_DETECTION_DESTINATION_IP
Dec/04/2022 12:42:54 ipsec,debug => (size 0x1c)
Dec/04/2022 12:42:54 ipsec,debug 0000001c 00004005 db97af86 1abda372 59298724 a2878713 d0dc9dbf
Dec/04/2022 12:42:54 ipsec adding notify: NAT_DETECTION_SOURCE_IP
Dec/04/2022 12:42:54 ipsec,debug => (size 0x1c)
Dec/04/2022 12:42:54 ipsec,debug 0000001c 00004004 ca1cfa9b 9d04817d 8bbc8239 6e85fb28 3de91c59
Dec/04/2022 12:42:54 ipsec adding payload: NONCE
Dec/04/2022 12:42:54 ipsec,debug => (size 0x1c)
Dec/04/2022 12:42:54 ipsec,debug 0000001c 1163a001 833c3977 d33d45e7 b40d3deb 7cf0c529 40c68277
Dec/04/2022 12:42:54 ipsec adding payload: KE
Dec/04/2022 12:42:54 ipsec,debug => (first 0x100 of 0x208)
Dec/04/2022 12:42:54 ipsec,debug 00000208 00100000 55aea95d dacef45e 723362e5 2666c587 108ec3be b634959e
Dec/04/2022 12:42:54 ipsec,debug 0b60666a ff4064e0 4e1c71b8 ba9e096f 44678eda ec2e82ee c028a338 773fe567
Dec/04/2022 12:42:54 ipsec,debug e791211a 17547456 dc3d0841 980e038c 687895a5 a0ef2a55 2672e502 b7f7900a
Dec/04/2022 12:42:54 ipsec,debug c22bbe8e 80d4f7aa c23fdba5 72006a9f 305fdc48 2b5883ae f2ce2eaf 6c810b67
Dec/04/2022 12:42:54 ipsec,debug 7cb6dc26 5a9750e7 db041a64 fd60efeb 5cd8ebc4 56347cc0 2c6d48e5 00576f96
Dec/04/2022 12:42:54 ipsec,debug 59957fbe 7fe07b50 746c6946 29b15c3e 02856816 5906319e 4b612613 2cb104aa
Dec/04/2022 12:42:54 ipsec,debug b3613d4d 982c6946 b64e3747 767a18da 813731d5 8c5b36d0 99887426 13b20d96
Dec/04/2022 12:42:54 ipsec,debug 8ebc0ea7 7b8840ee daa6b9b7 f923fc8d 86835bf4 d17389e6 0569d908 b9b8ce68
Dec/04/2022 12:42:54 ipsec adding payload: SA
Dec/04/2022 12:42:54 ipsec,debug => (size 0x40)
Dec/04/2022 12:42:54 ipsec,debug 00000040 0000003c 01010006 0300000c 0100000c 800e0100 03000008 02000005
Dec/04/2022 12:42:54 ipsec,debug 03000008 0300000c 03000008 04000010 03000008 0400000e 00000008 04000002
Dec/04/2022 12:42:54 ipsec <- ike2 request, exchange: SA_INIT:0 169.150.218.91[4500] 75fee59bf1006bff:0000000000000000
Dec/04/2022 12:42:54 ipsec,debug ===== sending 704 bytes from 100.70.3.235[4500] to 169.150.218.91[4500]
Dec/04/2022 12:42:54 ipsec,debug 1 times of 708 bytes message will be sent to 169.150.218.91[4500]
Dec/04/2022 12:42:54 ipsec,debug,packet 75fee59b f1006bff 00000000 00000000 29202208 00000000 000002c0 29000008
Dec/04/2022 12:42:54 ipsec,debug,packet 0000402e 2900001c 00004005 db97af86 1abda372 59298724 a2878713 d0dc9dbf
Dec/04/2022 12:42:54 ipsec,debug,packet 2800001c 00004004 ca1cfa9b 9d04817d 8bbc8239 6e85fb28 3de91c59 2200001c
Dec/04/2022 12:42:54 ipsec,debug,packet 1163a001 833c3977 d33d45e7 b40d3deb 7cf0c529 40c68277 21000208 00100000
Dec/04/2022 12:42:54 ipsec,debug,packet 55aea95d dacef45e 723362e5 2666c587 108ec3be b634959e 0b60666a ff4064e0
Dec/04/2022 12:42:54 ipsec,debug,packet 4e1c71b8 ba9e096f 44678eda ec2e82ee c028a338 773fe567 e791211a 17547456
Dec/04/2022 12:42:54 ipsec,debug,packet dc3d0841 980e038c 687895a5 a0ef2a55 2672e502 b7f7900a c22bbe8e 80d4f7aa
Dec/04/2022 12:42:54 ipsec,debug,packet c23fdba5 72006a9f 305fdc48 2b5883ae f2ce2eaf 6c810b67 7cb6dc26 5a9750e7
Dec/04/2022 12:42:54 ipsec,debug,packet db041a64 fd60efeb 5cd8ebc4 56347cc0 2c6d48e5 00576f96 59957fbe 7fe07b50
Dec/04/2022 12:42:54 ipsec,debug,packet 746c6946 29b15c3e 02856816 5906319e 4b612613 2cb104aa b3613d4d 982c6946
Dec/04/2022 12:42:54 ipsec,debug,packet b64e3747 767a18da 813731d5 8c5b36d0 99887426 13b20d96 8ebc0ea7 7b8840ee
Dec/04/2022 12:42:54 ipsec,debug,packet daa6b9b7 f923fc8d 86835bf4 d17389e6 0569d908 b9b8ce68 9074af37 fdc7e483
Dec/04/2022 12:42:54 ipsec,debug,packet 9ce9fc37 93aeab7e 98199579 9b9e685e f4bde0b7 13c17f90 52050277 635c6c29
Dec/04/2022 12:42:54 ipsec,debug,packet 9fa4f4fb c9b1af52 8bfb0d50 8fc455d3 20d3a47e 3223bef4 85f0a39b 2bd98567
Dec/04/2022 12:42:54 ipsec,debug,packet 04da5114 e701f005 c37fd0ed 2d7bf197 40c62cb7 d0c2c3b4 9453367d f965ec44
Dec/04/2022 12:42:54 ipsec,debug,packet 65c8f539 117c0767 c2fd4569 3ed65bbb 3ed3dd83 7ae4b28a 0c43a756 b76e00e6
Dec/04/2022 12:42:54 ipsec,debug,packet 12e31d94 fd0157df d77a8717 4cf902e8 f83174cf 880271af e26043b7 aed94844
Dec/04/2022 12:42:54 ipsec,debug,packet 41ce3d3f 794564c0 7b67c621 f1259322 6c9e2514 3d972bf0 ff395c49 fda8169a
Dec/04/2022 12:42:54 ipsec,debug,packet b15afc62 d455e9ba 0bc5b0c9 09ef5541 71b2e359 6c4cd77f 1e3e5695 58efb570
Dec/04/2022 12:42:54 ipsec,debug,packet 7df7b100 eab218af 86f3cfad 9702c785 3cf7354e 6447a28c 2351f39a acdb0141
Dec/04/2022 12:42:54 ipsec,debug,packet 00000040 0000003c 01010006 0300000c 0100000c 800e0100 03000008 02000005
Dec/04/2022 12:42:54 ipsec,debug,packet 03000008 0300000c 03000008 04000010 03000008 0400000e 00000008 04000002
Dec/04/2022 12:43:00 ipsec <- ike2 init retransmit request, exchange: SA_INIT:0 169.150.218.91[4500] 75fee59bf1006bff:0000000000000000

<    ===== sending 704 bytes from .....  repeats 3 times  >

Dec/04/2022 12:43:15 ipsec ike2 init timeout request, exchange: SA_INIT:0 169.150.218.91[4500] 75fee59bf1006bff:0000000000000000
Does somebody know where to look at? Thank you!
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPsec/IKEv2 VPN client on hEX S to ProtonVPN

Mon Dec 05, 2022 4:49 pm

There is no response from the remote IPsec responder in the log. So there are multiple possibilities:
  • a routing issue at your end
  • a firewall issue at your end (if you use mangle rules, these two points may actually be one as the interpretation of the routing-mark has changed somewhere between ROS 7.1 and ROS 7.6, so the response from the responder may get diverted)
  • something is wrong at the responder (ProtonVPN) side
  • something has changed about the contents in the first IKEv2 packet between ROS 6 and ROS 7 so ProtonVPN ignores it
To me, the issue with mangle rules seems most likely, but as you've decided to post only the part of the configuration you assumed to be relevant, I can't say that for sure.

One unrelated remark, there is no point in specifying the certificate in the identity as you authenticate to the responder using a username and password. The "Proton VPN CA" certificate must be in your router's certificate store in order that the router could verify validity of the certificate presented by the ProtonVPN responder.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: IPsec/IKEv2 VPN client on hEX S to ProtonVPN

Mon Dec 05, 2022 5:09 pm

Your software version is getting stale.............
Any reason you need ipsec IKEv2 for a basic third party VPN provider.

wireguard works well in these cases, is easier IMHO to implement and decently fast.
 
gromund
just joined
Topic Author
Posts: 2
Joined: Sun Dec 04, 2022 11:51 am

Re: IPsec/IKEv2 VPN client on hEX S to ProtonVPN

Mon Dec 05, 2022 9:15 pm

There is no response from the remote IPsec responder in the log. So there are multiple possibilities:
  • a routing issue at your end
  • a firewall issue at your end (if you use mangle rules, these two points may actually be one as the interpretation of the routing-mark has changed somewhere between ROS 7.1 and ROS 7.6, so the response from the responder may get diverted)
  • something is wrong at the responder (ProtonVPN) side
  • something has changed about the contents in the first IKEv2 packet between ROS 6 and ROS 7 so ProtonVPN ignores it
To me, the issue with mangle rules seems most likely, but as you've decided to post only the part of the configuration you assumed to be relevant, I can't say that for sure.

One unrelated remark, there is no point in specifying the certificate in the identity as you authenticate to the responder using a username and password. The "Proton VPN CA" certificate must be in your router's certificate store in order that the router could verify validity of the certificate presented by the ProtonVPN responder.
Thanks for the answer. I've posted only ipsec as I thought all other is irrelevant, yes. But there's no problem to share other settings with you. Nothing special - I just follow the instructions from the article of ProtonVPN mentioned above. I create local address and mark connection so that all traffic goes through the tunnel. All other settings are just default as Mikrotik nicely created for me (DHCP/DNS is auto to my ISP).
/ip/firewall/address-list> print 
Flags: D - DYNAMIC
Columns: LIST, ADDRESS, CREATION-TIME
  #   LIST      ADDRESS          CREATION-TIME       
  0   local     192.168.88.0/24  dec/03/2022 22:08:41

/ip/firewall/mangle> print 
Flags: X - disabled, I - invalid; D - dynamic 
 0    ;;; Mark all for VPN
      chain=prerouting action=mark-connection new-connection-mark=under_protonvpn passthrough=yes 
      connection-state=new src-address-list=local log=no log-prefix="" 

 1    ;;; Reduce MSS for VPN
      chain=forward action=change-mss new-mss=1360 passthrough=yes tcp-flags=syn protocol=tcp 
      connection-mark=under_protonvpn tcp-mss=!0-1375 log=no log-prefix="" 

/ip/route> print 
Flags: D - DYNAMIC; A - ACTIVE; c, d, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS      GATEWAY     DISTANCE
DAd 0.0.0.0/0        100.68.0.1         1
DAc 100.68.0.0/14    ether1             0
DAc 192.168.88.0/24  bridge             0

/ip/firewall/filter> print 
Flags: X - disabled, I - invalid; D - dynamic 
 0    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked 

 1    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid 

 2    ;;; defconf: accept ICMP
      chain=input action=accept protocol=icmp 

 3    ;;; defconf: accept to local loopback (for CAPsMAN)
      chain=input action=accept dst-address=127.0.0.1 

 4    ;;; defconf: drop all not coming from LAN
      chain=input action=drop in-interface-list=!LAN log=no log-prefix="" 

 5    ;;; defconf: accept in ipsec policy
      chain=forward action=accept ipsec-policy=in,ipsec 

 6    ;;; defconf: accept out ipsec policy
      chain=forward action=accept ipsec-policy=out,ipsec 

 7    ;;; defconf: accept established,related, untracked
      chain=forward action=accept connection-state=established,related,untracked 

 8    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid 

 9    ;;; defconf: drop all from WAN not DSTNATed
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN log=no 
      log-prefix="" 

/ip/firewall/nat> print 
Flags: X - disabled, I - invalid; D - dynamic 
 0    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface-list=WAN log=no log-prefix="" ipsec-policy=out,none 

and I deleted fasttrack rules - all as described in the ProtonVPN article at this point.
So, I suspect 2 things - something changed from 6.42 to 7.6; or my ISP provider started blocking remote peer(s) (I tried several ones from their list) - but this is very improbable as I upgraded in one day.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: IPsec/IKEv2 VPN client on hEX S to ProtonVPN

Mon Dec 05, 2022 9:32 pm

It's again not the complete configuration - your action=mark-connection mangle rule might be responsible for the issue depending on the contents of the address list local. But if there is indeed no mangle rule with action=mark-routing, we can wave that off.

I deleted fasttrack rules
If fastrack rules remained in place, it would strike later, the data transfer through the tunnel would be much slower than expected and most of the traffic from your router that should have gone through the tunnel would leak via the default route.

something changed from 6.42 to 7.6;
This is possible, but then ProtonVPN would have to be really specific, as otherwise much more people would report problems with IKEv2 in 7.6.

my ISP provider started blocking remote peer(s)
If you live in Iran, North Korea, possibly Russia soon - this could be the case, and it would be not just some servers but anything that looks like IPsec. You can try to downgrade back to 6.42 (or run a CHR in that version for a test). Or you can try to connect to some IPsec server in another country where the admin can tell you whether your packets arrive, and even respond them to see whether the responses come back. Or ask the ProtonVPN helpdesk for the same.

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 91 guests