[GH-ISSUE #242] Connecting to IPsec/XAuth stops working after some time #222

Closed
opened 2026-03-02 07:44:52 +03:00 by kerem · 18 comments
Owner

Originally created by @niksy on GitHub (Jun 7, 2021).
Original GitHub issue: https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/242

Describe the issue

When trying to connect to IPsec/XAuth VPN server, I get the following error: The VPN server did not respond. Verify the server address and try reconnecting. This seems to be happening after some time and it could be related to the issue #175. After I restart Docker container, everything works OK.

Connecting to IPsec/L2TP works OK.

I haven’t tried changing rekey option since I’m not entirely sure this should fix the issue. Seems like a strange behavior.

Server

  • Docker host OS: macOS Big Sur 11.4

Client

  • Device: iPhone 12 mini
  • OS: iOS 14.6
  • VPN mode: IPsec/XAuth ("Cisco IPsec")
Originally created by @niksy on GitHub (Jun 7, 2021). Original GitHub issue: https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/242 **Describe the issue** When trying to connect to IPsec/XAuth VPN server, I get the following error: `The VPN server did not respond. Verify the server address and try reconnecting.` This seems to be happening after some time and it could be related to the issue #175. After I restart Docker container, everything works OK. Connecting to IPsec/L2TP works OK. I haven’t tried changing `rekey` option since I’m not entirely sure this should fix the issue. Seems like a strange behavior. **Server** - Docker host OS: macOS Big Sur 11.4 **Client** - Device: iPhone 12 mini - OS: iOS 14.6 - VPN mode: IPsec/XAuth ("Cisco IPsec")
kerem closed this issue 2026-03-02 07:44:52 +03:00
Author
Owner

@hwdsl2 commented on GitHub (Jun 7, 2021):

@niksy Hello! iPhones disconnect Wi-Fi automatically shortly after entering sleep mode, and as a result, the IPsec VPN disconnects. This is by design and cannot be customized. However, you can try IKEv2 mode with the VPN on-demand feature. See [1] for more details.

[1] https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md#iosandroid-sleep-mode

<!-- gh-comment-id:855953102 --> @hwdsl2 commented on GitHub (Jun 7, 2021): @niksy Hello! iPhones disconnect Wi-Fi automatically shortly after entering sleep mode, and as a result, the IPsec VPN disconnects. This is by design and cannot be customized. However, you can try IKEv2 mode with the VPN on-demand feature. See [1] for more details. [1] https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md#iosandroid-sleep-mode
Author
Owner

@niksy commented on GitHub (Jun 7, 2021):

When I started Docker container I was able to connect to the VPN. This worked all the time in the span of 3-4 hours. This morning (that was more than 12 hours later I think) I tried it and I always get the same message. When I restart Docker container, everything works.

This behavior happend 2 times already. I don’t think this is related to iPhone Wi-Fi.

<!-- gh-comment-id:856034013 --> @niksy commented on GitHub (Jun 7, 2021): When I started Docker container I was able to connect to the VPN. This worked all the time in the span of 3-4 hours. This morning (that was more than 12 hours later I think) I tried it and I always get the same message. When I restart Docker container, everything works. This behavior happend 2 times already. I don’t think this is related to iPhone Wi-Fi.
Author
Owner

@hwdsl2 commented on GitHub (Jun 7, 2021):

@niksy I see. In that case you'll need to enable Libreswan logs for the container, try to reproduce the issue again and check the logs for errors. See README for more information. If you have findings feel free to reply here.

<!-- gh-comment-id:856043685 --> @hwdsl2 commented on GitHub (Jun 7, 2021): @niksy I see. In that case you'll need to enable Libreswan logs for the container, try to reproduce the issue again and check the logs for errors. See README for more information. If you have findings feel free to reply here.
Author
Owner

@niksy commented on GitHub (Jun 10, 2021):

@hwdsl2 it happened again, and here are the logs. L2TP works, but XAuth doesn’t.

L2TP

Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: responding to Main Mode from unknown peer 172.26.0.1:57729
Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: WARNING: connection l2tp-psk PSK length of 14 bytes is too short for HMAC_SHA2_256 PRF in FIPS mode (16 bytes required)
Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: sent Main Mode R1
Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: sent Main Mode R2
Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: ignoring informational payload IPSEC_INITIAL_CONTACT, msgid=00000000, length=28
Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: Peer ID is ID_IPV4_ADDR: '10.123.214.1'
Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: switched from "l2tp-psk"[5] 172.26.0.1 to "l2tp-psk"
Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #22: Peer ID is ID_IPV4_ADDR: '10.123.214.1'
Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #22: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048}
Jun 10 07:06:41 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #22: the peer proposed: 109.60.103.90/32:1701 -UDP-> 10.123.214.1/32:63233
Jun 10 07:06:41 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #22: NAT-Traversal: received 2 NAT-OA. Using first; ignoring others
Jun 10 07:06:41 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #23: responding to Quick Mode proposal {msgid:2c453fa3}
Jun 10 07:06:41 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #23:     us: 172.26.0.4[109.60.103.90]:17/1701  them: 172.26.0.1[10.123.214.1]:17/63233
Jun 10 07:06:41 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #23: sent Quick Mode reply, inbound IPsec SA installed, expecting confirmation transport mode {ESPinUDP=>0x00164844 <0xf302a3e1 xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=10.123.214.1 NATD=172.26.0.1:42940 DPD=active}
Jun 10 07:06:41 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #23: IPsec SA established transport mode {ESPinUDP=>0x00164844 <0xf302a3e1 xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=10.123.214.1 NATD=172.26.0.1:42940 DPD=active}

XAuth

Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: responding to Main Mode from unknown peer 172.26.0.1:57729
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: OAKLEY_DES_CBC(UNUSED) is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: OAKLEY_DES_CBC(UNUSED) is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: no acceptable Oakley Transform
Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: sending notification NO_PROPOSAL_CHOSEN to 172.26.0.1:57729
Jun 10 07:07:36 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: discarding initial packet; already STATE_MAIN_R0
Jun 10 07:07:39 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: discarding initial packet; already STATE_MAIN_R0
Jun 10 07:07:42 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: discarding initial packet; already STATE_MAIN_R0
<!-- gh-comment-id:858372824 --> @niksy commented on GitHub (Jun 10, 2021): @hwdsl2 it happened again, and here are the logs. L2TP works, but XAuth doesn’t. L2TP ``` Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: responding to Main Mode from unknown peer 172.26.0.1:57729 Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: WARNING: connection l2tp-psk PSK length of 14 bytes is too short for HMAC_SHA2_256 PRF in FIPS mode (16 bytes required) Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: sent Main Mode R1 Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: sent Main Mode R2 Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: ignoring informational payload IPSEC_INITIAL_CONTACT, msgid=00000000, length=28 Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: Peer ID is ID_IPV4_ADDR: '10.123.214.1' Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #22: switched from "l2tp-psk"[5] 172.26.0.1 to "l2tp-psk" Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #22: Peer ID is ID_IPV4_ADDR: '10.123.214.1' Jun 10 07:06:40 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #22: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048} Jun 10 07:06:41 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #22: the peer proposed: 109.60.103.90/32:1701 -UDP-> 10.123.214.1/32:63233 Jun 10 07:06:41 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #22: NAT-Traversal: received 2 NAT-OA. Using first; ignoring others Jun 10 07:06:41 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #23: responding to Quick Mode proposal {msgid:2c453fa3} Jun 10 07:06:41 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #23: us: 172.26.0.4[109.60.103.90]:17/1701 them: 172.26.0.1[10.123.214.1]:17/63233 Jun 10 07:06:41 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #23: sent Quick Mode reply, inbound IPsec SA installed, expecting confirmation transport mode {ESPinUDP=>0x00164844 <0xf302a3e1 xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=10.123.214.1 NATD=172.26.0.1:42940 DPD=active} Jun 10 07:06:41 2057f16ebb2e pluto[1845]: "l2tp-psk"[8] 172.26.0.1 #23: IPsec SA established transport mode {ESPinUDP=>0x00164844 <0xf302a3e1 xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=10.123.214.1 NATD=172.26.0.1:42940 DPD=active} ``` XAuth ``` Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: responding to Main Mode from unknown peer 172.26.0.1:57729 Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: OAKLEY_DES_CBC(UNUSED) is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: OAKLEY_DES_CBC(UNUSED) is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: no acceptable Oakley Transform Jun 10 07:07:33 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: sending notification NO_PROPOSAL_CHOSEN to 172.26.0.1:57729 Jun 10 07:07:36 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: discarding initial packet; already STATE_MAIN_R0 Jun 10 07:07:39 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: discarding initial packet; already STATE_MAIN_R0 Jun 10 07:07:42 2057f16ebb2e pluto[1845]: "l2tp-psk"[5] 172.26.0.1 #24: discarding initial packet; already STATE_MAIN_R0 ```
Author
Owner

@hwdsl2 commented on GitHub (Jun 10, 2021):

@niksy Thanks for the details. This is a known limitation, that you cannot have a mix of IPsec/L2TP and IPsec/XAuth ("Cisco IPsec") mode clients connected from behind the same NAT (e.g. home router). Please use only one of the two modes (or IKEv2, which does not have this limitation) for clients from the same NAT.

Your logs indicate that when an IPsec/L2TP client is already connected, the VPN server temporarily "remembers" the connection mode and refuses to connect an IPsec/XAuth mode client from the same NAT. Restarting the Docker container will clear the server's state and after that you can connect.

<!-- gh-comment-id:858625437 --> @hwdsl2 commented on GitHub (Jun 10, 2021): @niksy Thanks for the details. This is a known limitation, that you cannot have a mix of IPsec/L2TP and IPsec/XAuth ("Cisco IPsec") mode clients connected from behind the same NAT (e.g. home router). Please use only one of the two modes (or IKEv2, which does not have this limitation) for clients from the same NAT. Your logs indicate that when an IPsec/L2TP client is already connected, the VPN server temporarily "remembers" the connection mode and refuses to connect an IPsec/XAuth mode client from the same NAT. Restarting the Docker container will clear the server's state and after that you can connect.
Author
Owner

@niksy commented on GitHub (Jun 10, 2021):

Oh, okay! How can I use only L2TP or XAuth? I don’t need IKEv2 "complexity" for this particular case. Can I disable one and use only other one?

<!-- gh-comment-id:859030293 --> @niksy commented on GitHub (Jun 10, 2021): Oh, okay! How can I use only L2TP or XAuth? I don’t need IKEv2 "complexity" for this particular case. Can I disable one and use only other one?
Author
Owner

@hwdsl2 commented on GitHub (Jun 11, 2021):

@niksy It's configured on the client. There are different documents in this repo to configure clients for each mode, please refer to the docs.

<!-- gh-comment-id:859181474 --> @hwdsl2 commented on GitHub (Jun 11, 2021): @niksy It's configured on the client. There are different documents in this repo to configure clients for each mode, please refer to the docs.
Author
Owner

@niksy commented on GitHub (Jun 12, 2021):

So, there are 2 issues related to mine: https://github.com/hwdsl2/setup-ipsec-vpn/issues/557, https://github.com/hwdsl2/setup-ipsec-vpn/issues/43

I’ve looked up configuration and I think this is the block I need to remove to only have IPsec/XAuth configuration? I haven’t seen anything in the docs which explains this.

<!-- gh-comment-id:860037389 --> @niksy commented on GitHub (Jun 12, 2021): So, there are 2 issues related to mine: https://github.com/hwdsl2/setup-ipsec-vpn/issues/557, https://github.com/hwdsl2/setup-ipsec-vpn/issues/43 I’ve looked up configuration and I think this is the [block](https://github.com/hwdsl2/docker-ipsec-vpn-server/blob/92dea8726ef79d66f1a180fa2da81267c4d4aedd/run.sh#L276) I need to remove to only have IPsec/XAuth configuration? I haven’t seen anything in the docs which explains this.
Author
Owner

@hwdsl2 commented on GitHub (Jun 12, 2021):

@niksy That is correct. To disable IPsec/L2TP mode, first start a Bash shell inside the container [1]. Then remove the conn l2tp-psk block from both /etc/ipsec.conf AND /opt/src/run.sh. The latter is required because /etc/ipsec.conf is overwritten at container restart. Finally, run service ipsec restart.

I understand that you want to disable IPsec/L2TP mode on the VPN server. My previous comment was saying that it is not necessary to do that on the VPN server. Instead, if you do not configure any VPN client to use IPsec/L2TP mode [2], and instead only configure clients to use IPsec/XAuth mode [3], then you shouldn't encounter the policy does not allow Extended Authentication (XAUTH) ... errors. This error only happens when you have a VPN client configured to use IPsec/L2TP mode, and another VPN client configured to use IPsec/XAuth mode from behind the same NAT. So instead of disabling IPsec/L2TP on the VPN server, you can simply configure clients to use IPsec/XAuth mode only.

I plan to add a section to "troubleshooting" to clarify that these two modes should not be mixed for VPN clients connecting from behind the same NAT.

[1] https://github.com/hwdsl2/docker-ipsec-vpn-server#bash-shell-inside-container
[2] https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md
[3] https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients-xauth.md

<!-- gh-comment-id:860089730 --> @hwdsl2 commented on GitHub (Jun 12, 2021): @niksy That is correct. To disable IPsec/L2TP mode, first start a Bash shell inside the container [1]. Then remove the `conn l2tp-psk` block from both `/etc/ipsec.conf` AND `/opt/src/run.sh`. The latter is required because `/etc/ipsec.conf` is overwritten at container restart. Finally, run `service ipsec restart`. I understand that you want to disable IPsec/L2TP mode on the VPN server. My previous comment was saying that it is not necessary to do that on the VPN server. Instead, if you do not configure any VPN client to use IPsec/L2TP mode [2], and instead only configure clients to use IPsec/XAuth mode [3], then you shouldn't encounter the `policy does not allow Extended Authentication (XAUTH) ...` errors. This error only happens when you have a VPN client configured to use IPsec/L2TP mode, and another VPN client configured to use IPsec/XAuth mode from behind the same NAT. So instead of disabling IPsec/L2TP on the VPN server, you can simply configure clients to use IPsec/XAuth mode only. I plan to add a section to "troubleshooting" to clarify that these two modes should not be mixed for VPN clients connecting from behind the same NAT. [1] https://github.com/hwdsl2/docker-ipsec-vpn-server#bash-shell-inside-container [2] https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients.md [3] https://github.com/hwdsl2/setup-ipsec-vpn/blob/master/docs/clients-xauth.md
Author
Owner

@niksy commented on GitHub (Jun 13, 2021):

The thing is I’m currently the only client using this VPN server and that means I only have maximum of 1 connection active, so it can either be IPsec/XAuth or IPsec/L2TP.

One must be disconnected to connect to the other one, but this happens anyways. I even tried waiting for longer periods (half day).

That’s why I’m asking if I should disable one type of VPN server connection.

But, reading your answer:

Instead, if you do not configure any VPN client to use IPsec/L2TP mode [2], and instead only configure clients to use IPsec/XAuth mode [3]

What do you mean by "configured"? If I just add connection type in my iPhone, that’s enough for VPN server to show this error? I don’t even need to connect one time to that type of connection?

I plan to add a section to "troubleshooting" to clarify that these two modes should not be mixed for VPN clients connecting from behind the same NAT.

Maybe add option to disable/enable on Docker container creation, controlled with environment variable? That way users can avoid editing configuration files everytime they recreate containers.

<!-- gh-comment-id:860190633 --> @niksy commented on GitHub (Jun 13, 2021): The thing is I’m currently the only client using this VPN server and that means I only have maximum of 1 connection active, so it can either be IPsec/XAuth or IPsec/L2TP. One must be disconnected to connect to the other one, but this happens anyways. I even tried waiting for longer periods (half day). That’s why I’m asking if I should disable one type of VPN server connection. But, reading your answer: > Instead, if you do not configure any VPN client to use IPsec/L2TP mode [2], and instead only configure clients to use IPsec/XAuth mode [3] What do you mean by "configured"? If I just add connection type in my iPhone, that’s enough for VPN server to show this error? I don’t even need to connect one time to that type of connection? > I plan to add a section to "troubleshooting" to clarify that these two modes should not be mixed for VPN clients connecting from behind the same NAT. Maybe add option to disable/enable on Docker container creation, controlled with environment variable? That way users can avoid editing configuration files everytime they recreate containers.
Author
Owner

@hwdsl2 commented on GitHub (Jun 13, 2021):

@niksy By "configured" I mean that the VPN client is both set up AND connect to the VPN server using IPsec/L2TP mode. If you only set up the client to use this mode but don't connect, it won't trigger this issue.

From my understanding, this issue only occurs in the following scenarios: First, client "A" connects to the VPN server using IPsec/L2TP mode. Then another VPN client "B" from behind the same NAT tries to connect to the VPN server using IPsec/XAuth mode. Generally, if "A" has already disconnected before "B" connects, the issue doesn't occur. However, some earlier Android versions have a bug where they don't properly terminate the VPN connection, resulting in the VPN server still "remembering" the connection type. If such an Android client is client "A", then client "B" cannot connect regardless of whether "A" disconnected, until after the connection times out or until a restart of the IPsec service.

Your setup seems a bit uncommon because your logs show that the VPN server is at (local) IP 172.26.0.4, while the client is behind IP 172.26.0.1 with local IP 10.123.214.X. This means any other VPN client connecting from behind 172.26.0.1 could trigger this issue. I guess this may be due to special networking setup in Docker Desktop for Mac?

If you check your VPN logs when the error policy does not allow Extended Authentication (XAUTH)... is encountered, you should see (earlier in the logs) another client connecting using IPsec/L2TP mode. What I suggested was that if you don't configure that client to use IPsec/L2TP mode, the issue won't occur regardless of whether you disable IPsec/L2TP mode on the server.

<!-- gh-comment-id:860227990 --> @hwdsl2 commented on GitHub (Jun 13, 2021): @niksy By "configured" I mean that the VPN client is both set up AND connect to the VPN server using IPsec/L2TP mode. If you only set up the client to use this mode but don't connect, it won't trigger this issue. From my understanding, this issue only occurs in the following scenarios: First, client "A" connects to the VPN server using IPsec/L2TP mode. Then another VPN client "B" from behind the same NAT tries to connect to the VPN server using IPsec/XAuth mode. Generally, if "A" has already disconnected before "B" connects, the issue doesn't occur. However, some earlier Android versions have a bug where they don't properly terminate the VPN connection, resulting in the VPN server still "remembering" the connection type. If such an Android client is client "A", then client "B" cannot connect regardless of whether "A" disconnected, until after the connection times out or until a restart of the IPsec service. Your setup seems a bit uncommon because your logs show that the VPN server is at (local) IP 172.26.0.4, while the client is behind IP 172.26.0.1 with local IP 10.123.214.X. This means any other VPN client connecting from behind 172.26.0.1 could trigger this issue. I guess this may be due to special networking setup in Docker Desktop for Mac? If you check your VPN logs when the error `policy does not allow Extended Authentication (XAUTH)...` is encountered, you should see (earlier in the logs) another client connecting using IPsec/L2TP mode. What I suggested was that if you don't configure that client to use IPsec/L2TP mode, the issue won't occur regardless of whether you disable IPsec/L2TP mode on the server.
Author
Owner

@niksy commented on GitHub (Jun 13, 2021):

By "configured" I mean that the VPN client is both set up AND connect to the VPN server using IPsec/L2TP mode. If you only set up the client to use this mode but don't connect, it won't trigger this issue.

OK, I will restart Docker container and I only try to connect with IPsec/XAuth to see if the issue still occurs.

Your setup seems a bit uncommon because your logs show that the VPN server is at (local) IP 172.26.0.4, while the client is behind IP 172.26.0.1 with local IP 10.123.214.X. This means any other VPN client connecting from behind 172.26.0.1 could trigger this issue. I guess this may be due to special networking setup in Docker Desktop for Mac?

Maybe you’re right, maybe networking on Docker for Mac works differently than on Linux.

<!-- gh-comment-id:860246509 --> @niksy commented on GitHub (Jun 13, 2021): > By "configured" I mean that the VPN client is both set up AND connect to the VPN server using IPsec/L2TP mode. If you only set up the client to use this mode but don't connect, it won't trigger this issue. OK, I will restart Docker container and I only try to connect with IPsec/XAuth to see if the issue still occurs. > Your setup seems a bit uncommon because your logs show that the VPN server is at (local) IP 172.26.0.4, while the client is behind IP 172.26.0.1 with local IP 10.123.214.X. This means any other VPN client connecting from behind 172.26.0.1 could trigger this issue. I guess this may be due to special networking setup in Docker Desktop for Mac? Maybe you’re right, maybe networking on Docker for Mac works differently than on Linux.
Author
Owner

@niksy commented on GitHub (Jun 14, 2021):

OK, I’ve tried it again, only with IPsec/XAuth and this is what I get, first is successful connection, other two ones are failed connections:

Jun 13 17:44:47 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: responding to Main Mode from unknown peer 172.19.0.1:40016
Jun 13 17:44:47 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: WARNING: connection xauth-psk PSK length of 14 bytes is too short for HMAC_SHA2_256 PRF in FIPS mode (16 bytes required)
Jun 13 17:44:47 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: sent Main Mode R1
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: sent Main Mode R2
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: ignoring informational payload IPSEC_INITIAL_CONTACT, msgid=00000000, length=28
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: Peer ID is ID_IPV4_ADDR: '10.135.51.100'
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: switched from "xauth-psk"[3] 172.19.0.1 to "xauth-psk"
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1: deleting connection instance with peer 172.19.0.1 {isakmp=#0/ipsec=#0}
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: Peer ID is ID_IPV4_ADDR: '10.135.51.100'
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048}
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: XAUTH: Sending Username/Password request (MAIN_R3->XAUTH_R0)
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: XAUTH: password file authentication method requested to authenticate user 'nxr-media'
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: XAUTH: password file (/etc/ipsec.d/passwd) open.
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: XAUTH: success user(nxr-media:xauth-psk) 
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: XAUTH: User nxr-media: Authentication Successful
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: XAUTH: xauth_inR1(STF_OK)
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048}
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: modecfg_inR0(STF_OK)
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: sent ModeCfg reply, expecting Ack {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048}
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: the peer proposed: 0.0.0.0/0 -<all>-> 192.168.43.10/32
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #4: responding to Quick Mode proposal {msgid:fc135f81}
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #4:     us: 0.0.0.0/0===172.19.0.5[109.60.111.45,MS+XS+S=C]  them: 172.19.0.1[10.135.51.100,+MC+XC+S=C]===192.168.43.10/32
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #4: sent Quick Mode reply, inbound IPsec SA installed, expecting confirmation tunnel mode {ESPinUDP=>0x0ad44390 <0xcf25a60d xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=172.19.0.1:57376 DPD=active username=nxr-media}
Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #4: IPsec SA established tunnel mode {ESPinUDP=>0x0ad44390 <0xcf25a60d xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=172.19.0.1:57376 DPD=active username=nxr-media}
Jun 13 17:44:57 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: received Delete SA(0x0ad44390) payload: deleting IPsec State #4
Jun 13 17:44:57 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #4: deleting state (STATE_QUICK_R2) aged 8.659808s and sending notification
Jun 13 17:44:57 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #4: ESP traffic information: in=992B out=1KB XAUTHuser=nxr-media
Jun 13 17:44:57 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: deleting state (STATE_MODE_CFG_R1) aged 9.139696s and sending notification
Jun 13 17:44:57 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1: deleting connection instance with peer 172.19.0.1 {isakmp=#0/ipsec=#0}
Jun 14 00:38:52 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #5: responding to Main Mode from unknown peer 172.19.0.1:32915
Jun 14 00:38:52 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #5: OAKLEY_CAST_CBC is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
Jun 14 00:38:52 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #5: no acceptable Oakley Transform
Jun 14 00:38:52 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #5: sending notification NO_PROPOSAL_CHOSEN to 172.19.0.1:32915
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: responding to Main Mode from unknown peer 172.19.0.1:41694
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: OAKLEY_DES_CBC(UNUSED) is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: OAKLEY_DES_CBC(UNUSED) is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: no acceptable Oakley Transform
Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: sending notification NO_PROPOSAL_CHOSEN to 172.19.0.1:41694
Jun 14 07:03:59 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: discarding initial packet; already STATE_MAIN_R0
Jun 14 07:04:02 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: discarding initial packet; already STATE_MAIN_R0
Jun 14 07:04:05 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: discarding initial packet; already STATE_MAIN_R0
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: responding to Main Mode from unknown peer 172.19.0.1:41694
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder).  Attribute OAKLEY_AUTHENTICATION_METHOD
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: OAKLEY_DES_CBC(UNUSED) is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: OAKLEY_DES_CBC(UNUSED) is not supported.  Attribute OAKLEY_ENCRYPTION_ALGORITHM
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: no acceptable Oakley Transform
Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: sending notification NO_PROPOSAL_CHOSEN to 172.19.0.1:41694
Jun 14 07:05:11 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: discarding initial packet; already STATE_MAIN_R0
Jun 14 07:05:14 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: discarding initial packet; already STATE_MAIN_R0
Jun 14 07:05:18 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: discarding initial packet; already STATE_MAIN_R0

It seems like it’s trying to connect with L2TP even though after I restarted Docker container I only used XAuth.

<!-- gh-comment-id:860438813 --> @niksy commented on GitHub (Jun 14, 2021): OK, I’ve tried it again, only with IPsec/XAuth and this is what I get, first is successful connection, other two ones are failed connections: ``` Jun 13 17:44:47 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: responding to Main Mode from unknown peer 172.19.0.1:40016 Jun 13 17:44:47 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: WARNING: connection xauth-psk PSK length of 14 bytes is too short for HMAC_SHA2_256 PRF in FIPS mode (16 bytes required) Jun 13 17:44:47 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: sent Main Mode R1 Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: sent Main Mode R2 Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: ignoring informational payload IPSEC_INITIAL_CONTACT, msgid=00000000, length=28 Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: Peer ID is ID_IPV4_ADDR: '10.135.51.100' Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1 #3: switched from "xauth-psk"[3] 172.19.0.1 to "xauth-psk" Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[3] 172.19.0.1: deleting connection instance with peer 172.19.0.1 {isakmp=#0/ipsec=#0} Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: Peer ID is ID_IPV4_ADDR: '10.135.51.100' Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048} Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: XAUTH: Sending Username/Password request (MAIN_R3->XAUTH_R0) Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: XAUTH: password file authentication method requested to authenticate user 'nxr-media' Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: XAUTH: password file (/etc/ipsec.d/passwd) open. Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: XAUTH: success user(nxr-media:xauth-psk) Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: XAUTH: User nxr-media: Authentication Successful Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: XAUTH: xauth_inR1(STF_OK) Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: IKE SA established {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048} Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: modecfg_inR0(STF_OK) Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: sent ModeCfg reply, expecting Ack {auth=PRESHARED_KEY cipher=AES_CBC_256 integ=HMAC_SHA2_256 group=MODP2048} Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: the peer proposed: 0.0.0.0/0 -<all>-> 192.168.43.10/32 Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #4: responding to Quick Mode proposal {msgid:fc135f81} Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #4: us: 0.0.0.0/0===172.19.0.5[109.60.111.45,MS+XS+S=C] them: 172.19.0.1[10.135.51.100,+MC+XC+S=C]===192.168.43.10/32 Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #4: sent Quick Mode reply, inbound IPsec SA installed, expecting confirmation tunnel mode {ESPinUDP=>0x0ad44390 <0xcf25a60d xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=172.19.0.1:57376 DPD=active username=nxr-media} Jun 13 17:44:48 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #4: IPsec SA established tunnel mode {ESPinUDP=>0x0ad44390 <0xcf25a60d xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=172.19.0.1:57376 DPD=active username=nxr-media} Jun 13 17:44:57 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: received Delete SA(0x0ad44390) payload: deleting IPsec State #4 Jun 13 17:44:57 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #4: deleting state (STATE_QUICK_R2) aged 8.659808s and sending notification Jun 13 17:44:57 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #4: ESP traffic information: in=992B out=1KB XAUTHuser=nxr-media Jun 13 17:44:57 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1 #3: deleting state (STATE_MODE_CFG_R1) aged 9.139696s and sending notification Jun 13 17:44:57 490e0abdebb2 pluto[1665]: "xauth-psk"[4] 172.19.0.1: deleting connection instance with peer 172.19.0.1 {isakmp=#0/ipsec=#0} Jun 14 00:38:52 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #5: responding to Main Mode from unknown peer 172.19.0.1:32915 Jun 14 00:38:52 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #5: OAKLEY_CAST_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM Jun 14 00:38:52 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #5: no acceptable Oakley Transform Jun 14 00:38:52 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #5: sending notification NO_PROPOSAL_CHOSEN to 172.19.0.1:32915 Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: responding to Main Mode from unknown peer 172.19.0.1:41694 Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: OAKLEY_DES_CBC(UNUSED) is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: OAKLEY_DES_CBC(UNUSED) is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: no acceptable Oakley Transform Jun 14 07:03:55 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: sending notification NO_PROPOSAL_CHOSEN to 172.19.0.1:41694 Jun 14 07:03:59 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: discarding initial packet; already STATE_MAIN_R0 Jun 14 07:04:02 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: discarding initial packet; already STATE_MAIN_R0 Jun 14 07:04:05 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #6: discarding initial packet; already STATE_MAIN_R0 Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: responding to Main Mode from unknown peer 172.19.0.1:41694 Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: policy does not allow Extended Authentication (XAUTH) of initiator (we are responder). Attribute OAKLEY_AUTHENTICATION_METHOD Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: OAKLEY_DES_CBC(UNUSED) is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: OAKLEY_DES_CBC(UNUSED) is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: no acceptable Oakley Transform Jun 14 07:05:08 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: sending notification NO_PROPOSAL_CHOSEN to 172.19.0.1:41694 Jun 14 07:05:11 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: discarding initial packet; already STATE_MAIN_R0 Jun 14 07:05:14 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: discarding initial packet; already STATE_MAIN_R0 Jun 14 07:05:18 490e0abdebb2 pluto[1665]: "l2tp-psk"[1] 172.19.0.1 #7: discarding initial packet; already STATE_MAIN_R0 ``` It seems like it’s trying to connect with L2TP even though after I restarted Docker container I only used XAuth.
Author
Owner

@hwdsl2 commented on GitHub (Jun 14, 2021):

@niksy Not sure about the root cause but I was unable to reproduce the issue with Docker on Linux. If all three attempts are from your VPN client, it may be a bug specific to Docker for Mac. If the second attempt is not from your VPN client, it may be an attacker trying to connect using IPsec/L2TP mode. I would suggest that you disable IPsec/L2TP mode on the VPN server as previously discussed.

<!-- gh-comment-id:860706417 --> @hwdsl2 commented on GitHub (Jun 14, 2021): @niksy Not sure about the root cause but I was unable to reproduce the issue with Docker on Linux. If all three attempts are from your VPN client, it may be a bug specific to Docker for Mac. If the second attempt is not from your VPN client, it may be an attacker trying to connect using IPsec/L2TP mode. I would suggest that you disable IPsec/L2TP mode on the VPN server as previously discussed.
Author
Owner

@niksy commented on GitHub (Jun 14, 2021):

Yeah, all three are from my VPN client. I guess it’s a bug specific to macOS version.

OK, I’m going to try with L2TP disabled. If that works, do you think it would be possible to make activation/deactivation with environment variables, like I mentioned earlier? There are currently 3 steps needed to perform this operation which could be achieved with properly defined environment variable.

For example, USE_IPSEC_L2TP which controls L2TP mode and which is enabled by default.

And also, of course, mention this bug and behavior in docs and how to adjust configuration.

<!-- gh-comment-id:860801956 --> @niksy commented on GitHub (Jun 14, 2021): Yeah, all three are from my VPN client. I guess it’s a bug specific to macOS version. OK, I’m going to try with L2TP disabled. If that works, do you think it would be possible to make activation/deactivation with environment variables, like I mentioned earlier? There are currently 3 steps needed to perform this operation which could be achieved with properly defined environment variable. For example, `USE_IPSEC_L2TP` which controls L2TP mode and which is enabled by default. And also, of course, mention this bug and behavior in docs and how to adjust configuration.
Author
Owner

@hwdsl2 commented on GitHub (Jun 15, 2021):

@niksy I will need time to think about how to implement this variable properly, possibly with other variables that disable IPsec/XAuth mode and/or limit to IKEv2 only. Disabling IPsec/L2TP is an uncommon use case. In the meantime please continue to use the workaround discussed earlier by commenting out the l2tp-psk block in both files.

<!-- gh-comment-id:861578398 --> @hwdsl2 commented on GitHub (Jun 15, 2021): @niksy I will need time to think about how to implement this variable properly, possibly with other variables that disable IPsec/XAuth mode and/or limit to IKEv2 only. Disabling IPsec/L2TP is an uncommon use case. In the meantime please continue to use the workaround discussed earlier by commenting out the l2tp-psk block in both files.
Author
Owner

@niksy commented on GitHub (Jun 16, 2021):

Thank you!

Disabling IPsec/L2TP is an uncommon use case.

Yeah, but as you said in one of the previous comments, using both modes behind same NAT is a known limitation, and offering easy way of disabling one and enabling other could be potential solution for that.

<!-- gh-comment-id:862295451 --> @niksy commented on GitHub (Jun 16, 2021): Thank you! > Disabling IPsec/L2TP is an uncommon use case. Yeah, but as you said in one of the [previous comments](https://github.com/hwdsl2/docker-ipsec-vpn-server/issues/242#issuecomment-858625437), using both modes behind same NAT is a known limitation, and offering easy way of disabling one and enabling other could be potential solution for that.
Author
Owner

@hwdsl2 commented on GitHub (Jul 19, 2021):

This has been implemented in the latest Docker image version. Use the following variables to selectively disable VPN modes:

  VPN_DISABLE_IPSEC_L2TP: If 'yes', disable IPsec/L2TP mode.
  VPN_DISABLE_IPSEC_XAUTH: If 'yes', disable IPsec/XAuth ("Cisco IPsec") mode.
  VPN_IKEV2_ONLY: If 'yes', disable both IPsec/L2TP and IPsec/XAuth modes.
<!-- gh-comment-id:882248198 --> @hwdsl2 commented on GitHub (Jul 19, 2021): This has been implemented in the latest Docker image version. Use the following variables to selectively disable VPN modes: ``` VPN_DISABLE_IPSEC_L2TP: If 'yes', disable IPsec/L2TP mode. VPN_DISABLE_IPSEC_XAUTH: If 'yes', disable IPsec/XAuth ("Cisco IPsec") mode. VPN_IKEV2_ONLY: If 'yes', disable both IPsec/L2TP and IPsec/XAuth modes. ```
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/docker-ipsec-vpn-server#222
No description provided.