switching from L2TP/IPSEC to IKEv2/IPSEC interface?

Pericynthion · October 10, 2018, 11:02pm

Hi everyone! I searched the forum but couldn’t find an answer to this one - happy if anyone can point me at something I missed;

Current setup is a HexGr3 which has an authenticated (username/password) L2TP/IPSEC interface to a VPN provider. Using a combination of some DHCP reservations and some mangle rules to add a routing mark, coupled with the appropriate static routes, I send all the client traffic out over the L2TP interface - apart from some specific clients IP’s that I route direct to the ISP gateway.
The VPN provider is retiring (or deliberately not fixing issues with ) their LT2P service, so my options are SSTP/Softether (TCP based, so slow) or move to IKEv2/IPSEC. Obviously with the GR3 I get the encryption acceleration, so I figure that IKEv2/IPSEC is the best way to go.

Q: Might seem like a basic question, but what exactly do I need to replace the L2TP interface with?
Am I now creating a tunnel interface (GRE/IPIP etc), or do I now establish the IPSEC peers directly (in the IPSEC menu) - or both?

Ideally I’d like it to operate as another virtual interface so I can dynamically add the default gateway route with the preferable metric when the interface is up (and then if the interface drops I can fall back to the direct-to-ISP default route) The config is working fine (both with the current L2TP , and with the slower SSTP) - so hopeful someone can give me a lesson in IKEv2/IPSEC ‘interfaces’!!

Thanks in advance..

mducharme · October 11, 2018, 1:52am

With a pure IPsec tunnel, there is no interface created for the tunnel. Instead, the traffic goes out your default gateway to the Internet (ex. if you are using ether1 as a WAN port, the traffic seemingly going to the other IPsec end would appear to simply be going out ether1) and simply gets placed into the ‘invisible’ IPsec tunnel on its way out.

Pericynthion · October 11, 2018, 2:14am

Ok - so can I still route down the IP tunnel independently in the same way as if it was an interface? i.e. have a different default route/gateway depending on the routing mark?
Also do I create it as a ‘raw’ IP sec configuration (e.g. setup the IPSEC peers directly or just simply as a new IP tunnel interface, and then provide the authentication information etc in the IPSEC peer configration?

I guess I’m trying to figure out;
(a)the easiest way to establish the tunnel (for L2TP I just checked the ‘use IPSEC’ option)
(b)how I route down it - presumably I still end up gateway target I can route the particular routing mark connections down?

Sorry if this is basic stuff - everytime I get comfortable with RouterOS , I find something new to learn

sindy · October 11, 2018, 10:43pm

As @mducharme has stated, bare IPsec provides you with no interface and/or gateway IP to be used as the gateway parameter in the usual /ip route configuration. Whether it will be a plain IPsec or GRE over IPsec depends on the VPN provider’s decision, not yours. So if they don’t say there is GRE, don’t expect it.

So with bare IPsec, the packet is first handled using the “normal” routing. If a route exists for it and some output interface is found, then as the very last step before the packet is sent out that interface, its IP header is compared to the “traffic selector” part of all rows in /ip ipsec policy. The traffic selector consists of src-address, dst-address, protocol, src-port, and dst-port values. The policies are consulted top to bottom, just like firewall rule chains or /ip route rule rows. The action of the first policy which matches is executed on the packet; it may be none, which means that the packet is sent out the interface unchanged, or encrypt, which means that the packet is encrypted and sent using the security association (sa) associated to the policy (regardless through which interface the transport packets actually go out), or discard which means it is dropped. The last one is useful if you want to prevent packets from getting out if their respective SA is down; unfortunately, what I’ve described is only how it should work and in reality there are some surprises - e.g. currently (which means 6.42.3 as of writing this), if you create two policies with an identical selector, the one added or enbled later is marked as inactive regardless whether the earlier added/enabled one is active or not.

So the idea is that you make sure that all the packets you want to be actually sent via the IPsec tunnel are routed anywhere using the regular routing - if a default route matches on them, you’re good. Then, you create ipsec policies choosing the packets you want to send out the tunnel. But the traffic selector only works with the packet parameters listed above, so policy routing by in-interface and routing-mark doesn’t work the way you are used to as the IPsec policies don’t care which route has been used to determine the output interface.

However, in your case, I suspect that the VPN provider assigns you an IP address using the IKEv2 and mode-config and expects you to src-nat to that address all your traffic outgoing through the tunnel. So instead of the usual way, where you first choose the output interface and then apply src-nat to the outgoing packet to set its source address to the one of the chosen output interface, here you use the parameters you normally use to choose an action=mark-routing rule in mangle to choose an action=src-nat rule in nat. And that’s almost it, because when your IKEv2 peer is configured in client mode with mode-config, you get not only the address but also a corresponding policy for it, something like src-address=the.ip.you.got dst-address=0.0.0.0/0 protocol=any.

So on top of setting the IKEv2 peer in client mode and the modification mentioned above (src-nat rule instead of a mark-routing one), you have to make sure that the to-addresses value of that src-nat rule follows the address assignment from the VPN provider. And here again the readily available solution is a bit exotic - in the default mode-config settings called request-only, with responder set to no, which you use on the client peer, you specify a src-address-list value, referring to a name of an /ip firewall address-list which you populate with all local addresses or subnets from which the traffic should be routed to the tunnel. However, you can only use this method if it is enough for you to policy-route based on source IP addresses alone, because RouterOS creates dynamic src-nat rules (one per each policy) and inserts them to the beginning of the srcnat chain, which means you can neither specify any additional conditions to them nor place any other rules before them. So if you need to care about something else (in-interface, dst-address-list), you have to schedule for a periodical run a script which checks whether the address assigned by mode-config matches the to-addresses of your manually created src-nat rule and if not, it adjusts the to-addresses value in the rule.

The last thing to think about is how to prevent packets which should only go out via the VPN from ever going out the WAN if the VPN is down. And here the default route with a routing-mark comes back into play, because the only way I could find to prevent the leakage is to create an /interface bridge without any member ports and use it as a gateway of a route with a routing-mark. So when the IPsec policy is active, it will match, encrypt and send the packets just before they would be sent “out” via that bridge; when the policy is not active, those packets will be sent out the bridge which effectively means dropping them.

Pericynthion · October 12, 2018, 1:47am

Thanks for the detailed explanation sindy - now it makes a lot more sense - it actually sounds a lot easier than I thought. So I think I have a plan;

Leverage the standard, default routing table (with default gateway direct to the ISP)
Define an ipsec policy based on a src-address list (a handful of DHCP reserved IPs) with action set to ‘none’ (so it routes direct out the default gateway always, unencrypted )
Below that policy, define another ipsec policy based on src-address 0.0.0.0/0 via the VPN provider peer with an action of encrypt so everything else get passed over that virtual path encrypted to the IPSEC peer
Define a src-nat mangle rule for everything via the encrypted path to the VPN provider

In the event that the VPN peer is down, I’m happy for everything to follow the default gateway anyway, so I don’t need to blackhole anything - I just want the majority of clients to use the link if its available. If the SA is down it wont match any of those policies so it will route normally based on standard routing principles.

I think I’m over simplifying it - but I think this is actually a lot easier than the L2TP version I started out with. Or did I miss something ,

sindy · October 12, 2018, 8:33am

You did miss a couple of things so I probably haven’t stressed them out enough

an address-list can only be referred to in firewall rules, so you cannot use an address-list in place of src-address or dst-address of an ipsec policy
the src-nat is done before the packet is offered to traffic selectors to eventually steal it, so you have to src-nat what should go out the basic WAN to that WAN’s address (or not NAT it at all if you don’t normally need it), and src-nat what should go out the IPsec SA to the address required or assigned by the VPN provider
if the provider assigns you the IP address for your side, they usually also assign the complete policy; in any case it is not your free choice what the policy will be. Even if they don’t assign the policy, they cannot accept one with src-address=0.0.0.0/0 on your side, because the policies are negotiated between the peers and are mirrors of each other, so src-address=0.0.0.0/0 on client side side would mean dst-address=0.0.0.0/0 at their side so they would be sending everything to the first client on the list, which they clearly aren’t going to do.

Given that the VPN providers target ordinary users with default clients of Windows and iOS, I’m almost sure they use mode-config to assign you both the address and the policy.

You say it is enough for you to use only local side source address to choose between direct routing and routing via VPN, which is a good news as it allows to use the concept provided by RouterOS without any script to run periodically. But you have to modify a bit your idea of setting up exceptions for non-VPN routing and sending the bulk via the VPN. You have to use an /ip pool range for those local DHCP clients which should use the VPN as WAN, and assign addresses manually or using static leases to those which should use the “normal” WAN. So the whole setup would be like in this example:

/ip pool add name=for-vpn-users ranges=x.x.x.x-y.y.y.y
/ip firewall address-list add list=local-vpn-users address=x.x.x.x-y.y.y.y
/ip ipsec mode-config set [find name~"request-only"] address-list=local-vpn-users

So while the VPN is down, there will be no dynamically added src-nat rule to the address from the VPN provider, so all packets will be src-nated by your regular masquerade or src-nat rule. Once the VPN goes up, a dynamic rule will be inserted to the top of the srcnat chain, matching on src-address-list=local-vpn-users, with to-addresses set to the address from the provider.

Pericynthion · October 25, 2018, 11:48pm

Ok team, I’m back from vacation and looking at this.
Creating the peer to the VPN provider, seems to establish without any problem - although it doesnt seem to assign me an address, nor does it seem to require any authentication (presumably not needed for ph1)?

Q: Looking at this, does this imply the mode-config is incorrect (in that I am not getting an address back)

[dickie@MikroTik] /ip ipsec> peer print 
Flags: X - disabled, D - dynamic, R - responder 
 0     address=104.237.61.xx/32 profile=default auth-method=pre-shared-key secret="mysecret" generate-policy=no policy-template-group=default exchange-mode=ike2 send-initial-contact=yes 

[dickie@MikroTik] /ip ipsec remote-peers> print 
Flags: R - responder, N - natt-peer 
 #    ID                   STATE              REMOTE-ADDRESS  		DYNAMIC-ADDRESS                                   UPTIME               
 0  N 104.237.61.xx         established        104.237.61.xx				 1m

sindy · October 26, 2018, 5:26pm

Correct, you don’t ask for the address - you have to add mode-config=request-only to that peer’s parameters, and you have to set generate-policy to port-strict (or, maybe to port-override as there seems to be some issue in current RouterOS) to be able to create a policy from the mode-config instruction you get from the responder (server). As for authentication, the secret is there in the peer configuration and that’s it, no dialog is going to appear.

Pericynthion · October 26, 2018, 6:40pm

Ok - so now we’re getting somewhere

[dickie@MikroTik] /system logging> /ip ipsec peer print
Flags: X - disabled, D - dynamic, R - responder 
 0     address=104.237.61.xx/32 profile=default auth-method=pre-shared-key secret="mysecret" generate-policy=port-override policy-template-group=default exchange-mode=ike2 
       send-initial-contact=yes 
       
[dickie@MikroTik] /system logging> /ip ipsec remote-peer print
Flags: R - responder, N - natt-peer 
 #    ID                   STATE              REMOTE-ADDRESS                                                           DYNAMIC-ADDRESS                                  UPTIME              
 0  N 104.237.61.xx         established        104.237.61.xx                                                                                                              2m29s  
 
 [dickie@MikroTik] /system logging> /ip ipsec policy print
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
 0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes 

 1  DA  src-address=70.95.93.yy/32 src-port=any dst-address=104.237.61.xx/32 dst-port=any protocol=udp action=encrypt level=unique ipsec-protocols=esp tunnel=no proposal=default ph2-count=1 

[dickie@MikroTik] /system logging> /ip ipsec installed-sa print
Flags: H - hw-aead, A - AH, E - ESP 
 0 HE spi=0xEF7D839 src-address=104.237.61.xx:4500 dst-address=70.95.93.yy:4500 state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=128 
      auth-key="74b8b525a8f3c7ebc6d140bb96385b7be1287c1e" enc-key="49ede9956156ad78116cb7f5bd38fb60" add-lifetime=24m7s/30m9s replay=128 

 1 HE spi=0xC42C6273 src-address=70.95.93.yy:4500 dst-address=104.237.61.xx:4500 state=mature auth-algorithm=sha1 enc-algorithm=aes-cbc enc-key-size=128 
      auth-key="fde5ac9d98e2bc902ee30d15c2dade0d9d00aa59" enc-key="7d42134e1acd4d8b4d25558d76e4131e" add-lifetime=24m7s/30m9s replay=128

So we have the peer established , and the hardware accelerated SA’s installed. Awesome!!!

If I understand correctly based on the last reply, I need to add a srcnat based for a local IP address or range to be applied before the packet is offered to the IPSEC policy traffic selector.
I already have this srcNAT for the default ISP gateway, which is srcnat’ing everything for the WAN port behind the same 79.95.93.yy address above (which is my WAN address from the ISP).

 1    ;;; defconf: masquerade for ISP routed traffic
      chain=srcnat action=masquerade out-interface-list=WAN log=no log-prefix="" ipsec-policy=out,none

Q1: I can create a new srcnat where the source address is now a specific local IP address like 192.168.10.z , but what address do I NAT it behind? I still didnt get an IP address from the mode-config (blank)so do I use the 104.237.61.xx address of the remote peer or something else? There’s no interface to point it at either so do I still use the WAN interface, but with the IPsec policy set to ‘ipsec’?

Q2: I have the dynamically created IPsec policy in place between the WAN interface and the remote peer, so I just need to add a manual IPsec policy using the same source IP address as the src-nat in Q1, so that traffic selector will pick it up and encrypt it (based on source address) after it has passed through the standard routing and srcnat above.

That way for this specific local client, it will hit the standard default g/way routing via the ISP , then before the packet is routed it will get src’nat’d (to something) and passed encrypted to the remote VPN provider who will decrypt it and route it onwards At least thats my thinking…

So close… I can almost taste it

Pericynthion · October 26, 2018, 7:14pm

So I spotted a problem - for some reason configuring it through the webfig, it never applies the mode-config. Guess its a GUI issue with the latest beta (v6.44 beta20)

[dickie@MikroTik] /ip ipsec peer> set 0 mode-config request-only 
[dickie@MikroTik] /ip ipsec peer> print 
Flags: X - disabled, D - dynamic, R - responder 
 0     address=104.237.61.xx/32 profile=default auth-method=pre-shared-key secret="mysecret" generate-policy=port-override policy-template-group=default exchange-mode=ike2 mode-config=request-only send-initial-contact=yes

After adding this parameter though, the SA’s no longer establish - and it just keeps killing the connection (I tried it with both the port-override and port-strict policy)

12:09:44 ipsec,info new ike2 SA (I): 70.95.93.yy[4500]-104.237.61.xx[4500] spi:354480a913de1059:5d3534dd4d426ee5 
12:09:44 ipsec,info,account peer authorized: 70.95.93.yy[4500]-104.237.61.xx[4500] spi:354480a913de1059:5d3534dd4d426ee5 
12:09:44 ipsec,info killing ike2 SA: 70.95.93.yy[4500]-104.237.61.xx[4500] spi:354480a913de1059:5d3534dd4d426ee5 
12:09:54 ipsec,info new ike2 SA (I): 70.95.93.yy[4500]-104.237.61.xx[4500] spi:0c1ab77b0e69c583:c9a157208a24d7f4 
12:09:54 ipsec,info,account peer authorized: 70.95.93.yy[4500]-104.237.61.xx[4500] spi:0c1ab77b0e69c583:c9a157208a24d7f4 
12:09:54 ipsec,info killing ike2 SA: 70.95.93.yy[4500]-104.237.61.xx[4500] spi:0c1ab77b0e69c583:c9a157208a24d7f4

So without the mode-config it connects, but I don’t get an address. But with it in there, the peer never establishes.

If we go without the mode-config, then back to Q1 in the previous post - what address am I srcNat’ing behind.. or does this point to the policy at the IPsec endpoint is incorrect?

sindy · October 26, 2018, 7:56pm

Hm… seems like the mode-config either doesn’t work in the beta or is not supported/expected by the VPN provider. I never knew that policy-generate=port-* without mode-config worked this way, creating a transport-mode SA, but it seems logical. So guess it may even work if the client has a private address so the NAT-T handling can adjust the traffic selectors, but I’d have to dive into the RFC to be sure.

However, what does not work is to add a policy which the remote peer doesn’t agree to, and as soon as you want to send traffic towards internet using the SA, it must work in tunnel mode (so the dst-address at your side must be 0.0.0.0/0 while the sa-dst-address is the remote peer’s one). And if you did that using your normal WAN address, you’d make the SA your default route (because policies steal packets regardless where the normal routes send them).

The VPN provider should assign you a real public address, as anything else has a potential to get into conflict with your internal addresses or with the shared address pool some ISPs use to avoid conflict with customers’ private addresses.

So I have no idea what else to suggest, given that the current policy is useless and mode-config doesn’t work, except using a stable version where the mode-config may work better.

Of course, seeing the log in debug mode (/system logging add topics=ipsec,!packet) might explain what the peer says regarding the mode-config, but there is nothing you could change about it. If you decide to post the log anyway, be aware that the log sometimes contains IP addresses in hex form even if logging of packet contents is disabled using the !packet above, so you have to obfuscate these as well if you wish to stay anonymous.

Pericynthion · October 26, 2018, 10:27pm

I’m sure people have got better things to do than DOS my router or my VPN provider (famous last words)
Looks to me like the negotiation seems fine right up until ’ INTERNAL_ADDRESS_FAILURE’ , then it bails and deletes the SA.

From what I can find in the Cisco documentation, this is likely to be a server-side problem;
“If the client requests an IPv4 address and the RA server is unable to assign an address, an INTERNAL_ADDRESS_FAILURE message is returned to the client.”

15:13:55 system,info ipsec peer changed by dickie 
15:13:57 ipsec,debug 0.0.0.0[500] used as isakmp port (fd=20) 
15:13:57 ipsec,debug 0.0.0.0[4500] used as isakmp port with NAT-T (fd=22) 
15:13:57 ipsec,debug ::[500] used as isakmp port (fd=23) 
15:13:57 ipsec,debug ::[4500] used as isakmp port (fd=24) 
15:13:57 system,info ipsec peer changed by dickie 
15:13:58 ipsec ike2 starting for: 104.237.61.xx 
15:13:59 ipsec adding notify: NAT_DETECTION_DESTINATION_IP 
15:13:59 ipsec,debug => (size 0x1c) 
15:13:59 ipsec,debug 0000001c 00004005 d3374469 6485836b 82a303a9 26496b3a 433d9bad 
15:13:59 ipsec adding notify: NAT_DETECTION_SOURCE_IP 
15:13:59 ipsec,debug => (size 0x1c) 
15:13:59 ipsec,debug 0000001c 00004004 8e74ed29 a8fb568c 43b02767 4ad0689b ec822b05 
15:13:59 ipsec adding payload: NONCE 
15:13:59 ipsec,debug => (size 0x1c) 
15:13:59 ipsec,debug 0000001c fbe37f26 fa677dd0 726db339 9c0ae7e4 8e46d8e9 91b10d1e 
15:13:59 ipsec adding payload: KE 
15:13:59 ipsec,debug => (first 0x100 of 0x108) 
15:13:59 ipsec,debug 00000108 000e0000 c0b5185c 42e455bb 00f43119 755db536 fdcde507 f317e71a 
15:13:59 ipsec,debug fe2fc0aa a8d5086d 8257e894 957813d5 54bd869a a09d6466 7a5543b8 0cdbc1bb 
15:13:59 ipsec,debug 51f53a98 0335ba1f 1a39c634 db55cd31 26f3649e dddb99de e140aa6e f3261f27 
15:13:59 ipsec,debug 6c7ae134 3669b29d 59ff4638 9987f959 1c4e83ea 50c90dda 69433ebd 74be2ad1 
15:13:59 ipsec,debug 70a68ec9 0d1b62ec 7841d4b1 65639897 32637446 d06b078a a577f8a7 c7ea5c9f 
15:13:59 ipsec,debug 135d470e 3642d4df 3ea97767 82f9a0d5 61859f70 054d9736 1b232cfb bc90187c 
15:13:59 ipsec,debug b27f243e 73c02b33 347a6df0 7c5dc77e 521a62df f0821cad 07259949 35643bad 
15:13:59 ipsec,debug bb13fb86 fcadbef7 a28b2bfd ecf2a594 ad38ce0b 79288ab4 74cdb642 1fa38fec 
15:13:59 ipsec adding payload: SA 
15:13:59 ipsec,debug => (size 0x58) 
15:13:59 ipsec,debug 00000058 00000054 01010008 0300000c 0100000c 800e0100 0300000c 0100000c 
15:13:59 ipsec,debug 800e00c0 0300000c 0100000c 800e0080 03000008 01000003 03000008 02000002 
15:13:59 ipsec,debug 03000008 03000002 03000008 0400000e 00000008 04000002 
15:13:59 ipsec <- ike2 request, exchange: SA_INIT:0 104.237.61.xx[4500] 
15:13:59 ipsec,debug ===== sending 464 bytes from 70.95.93.yy[4500] to 104.237.61.xx[4500] 
15:13:59 ipsec,debug 1 times of 468 bytes message will be sent to 104.237.61.xx[4500] 
15:13:59 ipsec,debug ===== received 38 bytes from 104.237.61.xx[4500] to 70.95.93.yy[4500] 
15:13:59 ipsec -> ike2 reply, exchange: SA_INIT:0 104.237.61.xx[4500] 
15:13:59 ipsec payload seen: NOTIFY 
15:13:59 ipsec first payload is NOTIFY 
15:13:59 ipsec processing payloads: NOTIFY 
15:13:59 ipsec   notify: INVALID_KE_PAYLOAD 
15:13:59 ipsec,debug 0002 
15:13:59 ipsec retrying with different KE value 
15:13:59 ipsec adding notify: NAT_DETECTION_DESTINATION_IP 
15:13:59 ipsec,debug => (size 0x1c) 
15:13:59 ipsec,debug 0000001c 00004005 d3374469 6485836b 82a303a9 26496b3a 433d9bad 
15:13:59 ipsec adding notify: NAT_DETECTION_SOURCE_IP 
15:13:59 ipsec,debug => (size 0x1c) 
15:13:59 ipsec,debug 0000001c 00004004 8e74ed29 a8fb568c 43b02767 4ad0689b ec822b05 
15:13:59 ipsec adding payload: NONCE 
15:13:59 ipsec,debug => (size 0x1c) 
15:13:59 ipsec,debug 0000001c fbe37f26 fa677dd0 726db339 9c0ae7e4 8e46d8e9 91b10d1e 
15:13:59 ipsec adding payload: KE 
15:13:59 ipsec,debug => (size 0x88) 
15:13:59 ipsec,debug 00000088 00020000 bb13ffd6 1d6adad6 12fc9324 40024c6c 47aab604 1377eab0 
15:13:59 ipsec,debug f94d8d0f 46d69fe0 213cd490 bd82f853 f6de05e3 5cedb32c 90e11cc6 fcaa1142 
15:13:59 ipsec,debug 0ec55e42 27adf9b5 90b2589c 65c3ed91 72b335c8 f7b9b06e 70a4f7f1 288975e0 
15:13:59 ipsec,debug 827b3413 6cb4e92d f53f0e0d c5e12332 c48187ad cc97a991 8c0141af f341d384 
15:13:59 ipsec,debug 5e8ea69c 0437a237 
15:13:59 ipsec adding payload: SA 
15:13:59 ipsec,debug => (size 0x50) 
15:13:59 ipsec,debug 00000050 0000004c 01010007 0300000c 0100000c 800e0100 0300000c 0100000c 
15:13:59 ipsec,debug 800e00c0 0300000c 0100000c 800e0080 03000008 01000003 03000008 02000002 
15:13:59 ipsec,debug 03000008 03000002 00000008 04000002 
15:13:59 ipsec,debug ===== sending 328 bytes from 70.95.93.yy[4500] to 104.237.61.xx[4500] 
15:13:59 ipsec,debug 1 times of 332 bytes message will be sent to 104.237.61.xx[4500] 
15:13:59 ipsec,debug ===== received 312 bytes from 104.237.61.xx[4500] to 70.95.93.yy[4500] 
15:13:59 ipsec -> ike2 reply, exchange: SA_INIT:0 104.237.61.xx[4500] 
15:13:59 ipsec ike2 initialize recv 
15:13:59 ipsec payload seen: SA 
15:13:59 ipsec payload seen: KE 
15:13:59 ipsec payload seen: NONCE 
15:13:59 ipsec payload seen: NOTIFY 
15:13:59 ipsec payload seen: NOTIFY 
15:13:59 ipsec payload seen: NOTIFY 
15:13:59 ipsec processing payload: NONCE 
15:13:59 ipsec processing payload: SA 
15:13:59 ipsec IKE Protocol: IKE 
15:13:59 ipsec  proposal #1 
15:13:59 ipsec   enc: aes128-cbc 
15:13:59 ipsec   prf: hmac-sha1 
15:13:59 ipsec   auth: sha1 
15:13:59 ipsec   dh: modp1024 
15:13:59 ipsec matched proposal: 
15:13:59 ipsec  proposal #1 
15:13:59 ipsec   enc: aes128-cbc 
15:13:59 ipsec   prf: hmac-sha1 
15:13:59 ipsec   auth: sha1 
15:13:59 ipsec   dh: modp1024 
15:13:59 ipsec processing payload: KE 
15:13:59 ipsec,debug => shared secret (size 0x80) 
15:13:59 ipsec,debug 79a3a68b 069a84c4 56a07a47 70103cd5 8d0208a7 17df04ce 84d5d1c4 9ef215a9 
15:13:59 ipsec,debug 1fdee9a0 749b6252 5a16ab33 59990932 38ef75af 57479f58 da348a2d e6dbd278 
15:13:59 ipsec,debug d969c87d 8494abeb 2e969679 75932c66 866e57ea 9f77f28c 4545e837 6eb1810e 
15:13:59 ipsec,debug f641d1aa f3d69fdc 09fa9087 e8b214d5 eb1f0468 cc620cfb d2aac12b 94fb22f1 
15:13:59 ipsec,debug => skeyseed (size 0x14) 
15:13:59 ipsec,debug aacbcff4 e8cfe886 6be7cbdf e139119b 0bba9881 
15:13:59 ipsec,debug => keymat (size 0x14) 
15:13:59 ipsec,debug e18eb248 fa61b812 73fc848b bda4e683 43f832e5 
15:13:59 ipsec,debug => SK_ai (size 0x14) 
15:13:59 ipsec,debug fad662c6 0773a513 fe7022b7 620db55f 32b0682e 
15:13:59 ipsec,debug => SK_ar (size 0x14) 
15:13:59 ipsec,debug edd0efb1 1b201041 86bd672d c530cf66 1e94e9d2 
15:13:59 ipsec,debug => SK_ei (size 0x10) 
15:13:59 ipsec,debug 63523673 85eace01 a1ba9762 9432625c 
15:13:59 ipsec,debug => SK_er (size 0x10) 
15:13:59 ipsec,debug 997d4fae d379dbc8 1d2901fb 0308ca28 
15:13:59 ipsec,debug => SK_pi (size 0x14) 
15:13:59 ipsec,debug 354178cc 18d165cf 1c53a8db 520a27c4 9008edc1 
15:13:59 ipsec,debug => SK_pr (size 0x14) 
15:13:59 ipsec,debug 836b8ba2 acb413bd c5be0193 8fcd3df8 3ce26b40 
15:13:59 ipsec,info new ike2 SA (I): 70.95.93.yy[4500]-104.237.61.xx[4500] spi:7b01fb40cb21c1da:2f62510ec7d645bd 
15:13:59 ipsec processing payloads: NOTIFY 
15:13:59 ipsec   notify: NAT_DETECTION_SOURCE_IP 
15:13:59 ipsec,debug 2fa4c5d17e822dcd4d7bed81eb881114d01f6068 
15:13:59 ipsec   notify: NAT_DETECTION_DESTINATION_IP 
15:13:59 ipsec,debug da13aecc163464becc33b89d773159adab61157b 
15:13:59 ipsec   notify: MULTIPLE_AUTH_SUPPORTED 
15:13:59 ipsec (NAT-T) REMOTE  
15:13:59 ipsec KA list add: 70.95.93.yy[4500]->104.237.61.xx[4500] 
15:13:59 ipsec init child 
15:13:59 ipsec init child continue 
15:13:59 ipsec offering proto: 3 
15:13:59 ipsec  proposal #1 
15:13:59 ipsec   enc: aes256-cbc 
15:13:59 ipsec   enc: aes192-cbc 
15:13:59 ipsec   enc: aes128-cbc 
15:13:59 ipsec   auth: sha512 
15:13:59 ipsec   auth: sha256 
15:13:59 ipsec   auth: sha1 
15:13:59 ipsec my ID (ADDR): 70.95.93.yy 
15:13:59 ipsec processing payload: NONCE 
15:13:59 ipsec,debug => auth nonce (size 0x20) 
15:13:59 ipsec,debug cbcd54c3 db0bc9f5 0d271885 881f934a 282dab31 3bba1867 5cf82aa5 dc6a16b0 
15:13:59 ipsec,debug => SK_p (size 0x14) 
15:13:59 ipsec,debug 354178cc 18d165cf 1c53a8db 520a27c4 9008edc1 
15:13:59 ipsec,debug => idhash (size 0x14) 
15:13:59 ipsec,debug 5986657a 77ded0f1 d4df496a e908aa35 d28c184b 
15:13:59 ipsec,debug => my auth (size 0x14) 
15:13:59 ipsec,debug a1860237 18035dc2 46d5fe99 eec7eba8 dfb4f4a3 
15:13:59 ipsec adding payload: ID_I 
15:13:59 ipsec,debug => (size 0xc) 
15:13:59 ipsec,debug 0000000c 01000000 465f5d81 
15:13:59 ipsec adding payload: AUTH 
15:13:59 ipsec,debug => (size 0x1c) 
15:13:59 ipsec,debug 0000001c 02000000 a1860237 18035dc2 46d5fe99 eec7eba8 dfb4f4a3 
15:13:59 ipsec adding notify: INITIAL_CONTACT 
15:13:59 ipsec,debug => (size 0x8) 
15:13:59 ipsec,debug 00000008 00004000 
15:13:59 ipsec adding payload: SA 
15:13:59 ipsec,debug => (size 0x54) 
15:13:59 ipsec,debug 00000054 00000050 01030407 0d116024 0300000c 0100000c 800e0100 0300000c 
15:13:59 ipsec,debug 0100000c 800e00c0 0300000c 0100000c 800e0080 03000008 0300000e 03000008 
15:13:59 ipsec,debug 0300000c 03000008 03000002 00000008 05000000 
15:13:59 ipsec initiator selector: 0.0.0.0/0 
15:13:59 ipsec adding payload: TS_I 
15:13:59 ipsec,debug => (size 0x18) 
15:13:59 ipsec,debug 00000018 01000000 07000010 0000ffff 00000000 ffffffff 
15:13:59 ipsec responder selector: 0.0.0.0/0 
15:13:59 ipsec adding payload: TS_R 
15:13:59 ipsec,debug => (size 0x18) 
15:13:59 ipsec,debug 00000018 01000000 07000010 0000ffff 00000000 ffffffff 
15:13:59 ipsec prepearing internal IPv4 address 
15:13:59 ipsec prepearing internal IPv4 netmask 
15:13:59 ipsec prepearing internal IPv6 subnet 
15:13:59 ipsec prepearing internal IPv4 DNS 
15:13:59 ipsec adding payload: CONFIG 
15:13:59 ipsec,debug => (size 0x2c) 
15:13:59 ipsec,debug 0000002c 01000000 00010004 00000000 00020004 00000000 000d0008 00000000 
15:13:59 ipsec,debug 00000000 00030004 00000000 
15:13:59 ipsec <- ike2 request, exchange: AUTH:1 104.237.61.xx[4500] 
15:13:59 ipsec,debug ===== sending 412 bytes from 70.95.93.yy[4500] to 104.237.61.xx[4500] 
15:13:59 ipsec,debug 1 times of 416 bytes message will be sent to 104.237.61.xx[4500] 
15:13:59 ipsec,debug ===== received 124 bytes from 104.237.61.xx[4500] to 70.95.93.yy[4500] 
15:13:59 ipsec -> ike2 reply, exchange: AUTH:1 104.237.61.xx[4500] 
15:13:59 ipsec payload seen: ENC 
15:13:59 ipsec processing payload: ENC 
15:13:59 ipsec,debug => iv (size 0x10) 
15:13:59 ipsec,debug 0ffc9c1a e3a84502 7bfdebc5 1a19b4b4 
15:13:59 ipsec,debug => plain payload (trimmed) (size 0x30) 
15:13:59 ipsec,debug 2700000c 01000000 68ed3d02 2900001c 02000000 c41c8a62 ba0d3298 0b6ba1f0 
15:13:59 ipsec,debug 1a7d2363 3ec90eeb 00000008 00000024 
15:13:59 ipsec,debug decrypted 
15:13:59 ipsec payload seen: ID_R 
15:13:59 ipsec payload seen: AUTH 
15:13:59 ipsec payload seen: NOTIFY 
15:13:59 ipsec ike auth: initiator finish 
15:13:59 ipsec processing payloads: NOTIFY 
15:13:59 ipsec   notify: INTERNAL_ADDRESS_FAILURE 
15:13:59 ipsec got error: INTERNAL_ADDRESS_FAILURE 
15:13:59 ipsec processing payloads: ID_R 
15:13:59 ipsec peer ID (ADDR4): 104.237.61.xx 
15:13:59 ipsec processing payload: AUTH 
15:13:59 ipsec,debug => peer's auth (size 0x14) 
15:13:59 ipsec,debug c41c8a62 ba0d3298 0b6ba1f0 1a7d2363 3ec90eeb 
15:13:59 ipsec,debug => auth nonce (size 0x18) 
15:13:59 ipsec,debug fbe37f26 fa677dd0 726db339 9c0ae7e4 8e46d8e9 91b10d1e 
15:13:59 ipsec,debug => SK_p (size 0x14) 
15:13:59 ipsec,debug 836b8ba2 acb413bd c5be0193 8fcd3df8 3ce26b40 
15:13:59 ipsec,debug => idhash (size 0x14) 
15:13:59 ipsec,debug f120b0cb 7792d041 cab6caba 112afbbc c63d7fbf 
15:13:59 ipsec,debug => calculated peer's AUTH (size 0x14) 
15:13:59 ipsec,debug c41c8a62 ba0d3298 0b6ba1f0 1a7d2363 3ec90eeb 
15:13:59 ipsec,info,account peer authorized: 70.95.93.yy[4500]-104.237.61.xx[4500] spi:7b01fb40cb21c1da:2f62510ec7d645bd 
15:13:59 ipsec,info killing ike2 SA: 70.95.93.yy[4500]-104.237.61.xx[4500] spi:7b01fb40cb21c1da:2f62510ec7d645bd 
15:13:59 ipsec adding payload: DELETE 
15:13:59 ipsec,debug => (size 0x8) 
15:13:59 ipsec,debug 00000008 01000000 
15:13:59 ipsec <- ike2 request, exchange: INFORMATIONAL:2 104.237.61.xx[4500] 
15:13:59 ipsec,debug ===== sending 252 bytes from 70.95.93.yy[4500] to 104.237.61.xx[4500] 
15:13:59 ipsec,debug 1 times of 256 bytes message will be sent to 104.237.61.xx[4500] 
15:13:59 ipsec KA remove: 70.95.93.yy[4500]->104.237.61.xx[4500] 
15:13:59 ipsec,debug KA tree dump: 70.95.93.yy[4500]->104.237.61.xx[4500] (in_use=1) 
15:13:59 ipsec,debug KA removing this one... 
15:13:59 ipsec,debug ===== received 76 bytes from 104.237.61.xx[4500] to 70.95.93.yy[4500] 
15:13:59 ipsec -> ike2 reply, exchange: INFORMATIONAL:2 104.237.61.xx[4500] 
15:13:59 ipsec SPI dac121cb40fb017b not registred for 104.237.61.xx[4500]

sindy · October 27, 2018, 7:20am

Well, the trouble is that there may be a number of reasons why the responder descides not to assign you an address, and it has no means to tell you the actual reason. E.g., it may have free addresses in the pool but won’t assign one to you because you haven’t identified yourself properly.

So my apologies, I forgot that you’ve probably got a username for the service along with the shared secret. So add **my-id=user-fqdn:**the-username-you’ve-got to peer configuration and try again (if the username came with a domain name, like an e-mail address, use the complete username@domain.name string). If you’ve got a shared secret for IKEv2 and a password, you’d instead have to change auth-mode to pre-shared-key-xauth and set xauth-login and xauth-password, but I’d assume that if these were required, already the authentication should have failed.

Pericynthion · October 27, 2018, 4:19pm

its odd, because I’ve got;

-a username and password (the same ones I use when connection via L2TP etc - no FQDN, just a regular username/pwd)
-a L2TP pre-shared key (which is the same one I’m currently using for the IPSEC peer)
-an ‘IKEv2 Remote ID’ (which is just a domain name)

When I flip to pre-shared with xauth, I can’t get the username and password to work and the peer/SA’s never establish (the IPSEC log shows);

09:14:55 ipsec ike auth: initiator finish
09:14:55 ipsec processing payloads: NOTIFY
09:14:55 ipsec notify: AUTHENTICATION_FAILED
09:14:55 ipsec,error got error: AUTHENTICATION_FAILED

I also tried username@FQDN in the xauth field (where the FQDN is the usppoed IKEv2 RemoteID) - but the peer still fails.
So that might explain why the peer is failing to issue an L3 address if the AAA at the back-end is failing.

Thanks again for all your help - I’m going to go back and ask them what info I should be using to authenticate the ipsec peer, becuase I feel like we’re guessing here