And here it is again:
Feb 19 02:10:01 VM-e2b7 charon: 11[ENC] generating IKE_AUTH response 1 [
EF(2/2) ]
Feb 19 02:10:01 VM-e2b7 charon: 11[NET] sending packet: from
102.1*9.2**.***[4500] to 154.77.***.**[4500] (1236 bytes)
Feb 19 02:10:01 VM-e2b7 charon: 11[NET] sending packet: from
102.1*9.2**.***[4500] to 154.77.***.**[4500] (772 bytes)
Feb 19 02:10:01 VM-e2b7 kernel: [ 2543.189073] [UFW BLOCK] IN=ens3 OUT=
MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
DST=102.1*9.2**.*** LEN=52 TOS=0x10 PREC=0x20 TTL=116 ID=27223 DF PROTO=TCP
SPT=54229 DPT=443 WINDOW=17520 RES=0x00 SYN URGP=0
Feb 19 02:10:04 VM-e2b7 kernel: [ 2546.194639] [UFW BLOCK] IN=ens3 OUT=
MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
DST=102.1*9.2**.*** LEN=52 TOS=0x10 PREC=0x20 TTL=116 ID=27227 DF PROTO=TCP
SPT=54229 DPT=443 WINDOW=17520 RES=0x00 SYN URGP=0
Feb 19 02:10:10 VM-e2b7 kernel: [ 2552.209139] [UFW BLOCK] IN=ens3 OUT=
MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
DST=102.1*9.2**.*** LEN=52 TOS=0x10 PREC=0x20 TTL=116 ID=27234 DF PROTO=TCP
SPT=54229 DPT=443 WINDOW=17520 RES=0x00 SYN URGP=0
Feb 19 02:10:22 VM-e2b7 kernel: [ 2564.254984] [UFW BLOCK] IN=ens3 OUT=
MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
DST=102.1*9.2**.*** LEN=44 TOS=0x10 PREC=0x20 TTL=113 ID=53967 PROTO=TCP
SPT=54230 DPT=1723 WINDOW=32120 RES=0x00 SYN URGP=0
Feb 19 02:10:24 VM-e2b7 kernel: [ 2566.134188] [UFW BLOCK] IN=ens3 OUT=
MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
DST=102.1*9.2**.*** LEN=44 TOS=0x10 PREC=0x20 TTL=112 ID=53967 PROTO=TCP
SPT=54230 DPT=1723 WINDOW=32120 RES=0x00 SYN URGP=0
Feb 19 02:10:30 VM-e2b7 charon: 14[JOB] deleting half open IKE_SA with
154.77.***.** after timeout
This time there is port 1723 too - which is PPTP. But port 443 is there too.
Both are blocked by the firewall.
Moses, several people gave you several different suggestions today, including:
- Installing EAP-Identity support
- Setting UFW to allow all traffic from client
- Checking client logs
- Checking actual error message from the client
- Checking if your server certificates have https:// CRL's
- Simplifying your setup to use PSK (pre-shared-keys) for authentication *for
now*
Have you tried any of these?
-- K
On Tue, Feb 19, 2019, at 2:39 PM, MOSES KARIUKI wrote:
> Hello Team,
>
> This is the full LOG. The redacted IPs with ** are the VPN server
> ('102.1*9.2**.***') and Windows client (154.77.***.**).
>
> Feb 19 02:10:01 VM-e2b7 ipsec[1011]: 11[CFG] looking for peer configs
> matching 102.1*9.2**.***[%any]...154.77.***.**[192.168.43.156]
> Feb 19 02:10:01 VM-e2b7 ipsec[1011]: 11[CFG] candidate "ikev2-vpn", match:
> 1/1/28 (me/other/ike)
> Feb 19 02:10:01 VM-e2b7 ipsec[1011]: 11[CFG] selected peer config 'ikev2-vpn'
> Feb 19 02:10:01 VM-e2b7 ipsec[1011]: 11[IKE] EAP-Identity request configured,
> but not supported
> Feb 19 02:10:01 VM-e2b7 ipsec[1011]: 11[IKE] initiating EAP_MSCHAPV2 method
> (id 0x64)
> Feb 19 02:10:01 VM-e2b7 ipsec[1011]: 11[IKE] peer supports MOBIKE
> Feb 19 02:10:01 VM-e2b7 ipsec[1011]: 11[IKE] authentication of
> '102.1*9.2**.***' (myself) with RSA signature successful
> Feb 19 02:10:01 VM-e2b7 ipsec[1011]: 11[IKE] sending end entity cert
> "CN=102.1*9.2**.***"
> Feb 19 02:10:01 VM-e2b7 ipsec[1011]: 11[ENC] generating IKE_AUTH response 1 [
> IDr CERT AUTH EAP/REQ/MSCHAPV2 ]
> Feb 19 02:10:01 VM-e2b7 ipsec[1011]: 11[ENC] splitting IKE message with
> length of 1936 bytes into 2 fragments
> Feb 19 02:10:01 VM-e2b7 charon: 11[ENC] generating IKE_AUTH response 1 [
> EF(1/2) ]
> Feb 19 02:10:01 VM-e2b7 charon: 11[ENC] generating IKE_AUTH response 1 [
> EF(2/2) ]
> Feb 19 02:10:01 VM-e2b7 charon: 11[NET] sending packet: from
> 102.1*9.2**.***[4500] to 154.77.***.**[4500] (1236 bytes)
> Feb 19 02:10:01 VM-e2b7 charon: 11[NET] sending packet: from
> 102.1*9.2**.***[4500] to 154.77.***.**[4500] (772 bytes)
> Feb 19 02:10:01 VM-e2b7 kernel: [ 2543.189073] [UFW BLOCK] IN=ens3 OUT=
> MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
> DST=102.1*9.2**.*** LEN=52 TOS=0x10 PREC=0x20 TTL=116 ID=27223 DF PROTO=TCP
> SPT=54229 DPT=443 WINDOW=17520 RES=0x00 SYN URGP=0
> Feb 19 02:10:04 VM-e2b7 kernel: [ 2546.194639] [UFW BLOCK] IN=ens3 OUT=
> MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
> DST=102.1*9.2**.*** LEN=52 TOS=0x10 PREC=0x20 TTL=116 ID=27227 DF PROTO=TCP
> SPT=54229 DPT=443 WINDOW=17520 RES=0x00 SYN URGP=0
> Feb 19 02:10:10 VM-e2b7 kernel: [ 2552.209139] [UFW BLOCK] IN=ens3 OUT=
> MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
> DST=102.1*9.2**.*** LEN=52 TOS=0x10 PREC=0x20 TTL=116 ID=27234 DF PROTO=TCP
> SPT=54229 DPT=443 WINDOW=17520 RES=0x00 SYN URGP=0
> Feb 19 02:10:12 VM-e2b7 kernel: [ 2553.847176] [UFW BLOCK] IN=ens3 OUT=
> MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=191.96.110.25
> DST=102.1*9.2**.*** LEN=44 TOS=0x00 PREC=0x00 TTL=248 ID=54321 PROTO=TCP
> SPT=50543 DPT=990 WINDOW=65535 RES=0x00 SYN URGP=0
> Feb 19 02:10:22 VM-e2b7 kernel: [ 2564.254984] [UFW BLOCK] IN=ens3 OUT=
> MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
> DST=102.1*9.2**.*** LEN=44 TOS=0x10 PREC=0x20 TTL=113 ID=53967 PROTO=TCP
> SPT=54230 DPT=1723 WINDOW=32120 RES=0x00 SYN URGP=0
> Feb 19 02:10:24 VM-e2b7 kernel: [ 2566.134188] [UFW BLOCK] IN=ens3 OUT=
> MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
> DST=102.1*9.2**.*** LEN=44 TOS=0x10 PREC=0x20 TTL=112 ID=53967 PROTO=TCP
> SPT=54230 DPT=1723 WINDOW=32120 RES=0x00 SYN URGP=0
> Feb 19 02:10:24 VM-e2b7 kernel: [ 2566.425334] [UFW BLOCK] IN=ens3 OUT=
> MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=37.157.72.207
> DST=102.1*9.2**.*** LEN=40 TOS=0x08 PREC=0x40 TTL=43 ID=10093 PROTO=TCP
> SPT=34401 DPT=8080 WINDOW=20539 RES=0x00 SYN URGP=0
> Feb 19 02:10:30 VM-e2b7 charon: 14[JOB] deleting half open IKE_SA with
> 154.77.***.** after timeout
> Feb 19 02:10:40 VM-e2b7 kernel: [ 2582.134308] [UFW BLOCK] IN=ens3 OUT=
> MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
> DST=102.1*9.2**.*** LEN=44 TOS=0x10 PREC=0x20 TTL=112 ID=53967 PROTO=TCP
> SPT=54230 DPT=1723 WINDOW=32120 RES=0x00 SYN URGP=0
> Feb 19 02:11:08 VM-e2b7 kernel: [ 2610.346853] [UFW BLOCK] IN=ens3 OUT=
> MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
> DST=102.1*9.2**.*** LEN=136 TOS=0x10 PREC=0x20 TTL=116 ID=27300 PROTO=UDP
> SPT=1701 DPT=1701 LEN=116
> Feb 19 02:12:13 VM-e2b7 kernel: [ 2674.792576] [UFW BLOCK] IN=ens3 OUT=
> MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=173.212.236.49
> DST=102.1*9.2**.*** LEN=40 TOS=0x08 PREC=0x40 TTL=239 ID=12005 PROTO=TCP
> SPT=50816 DPT=50802 WINDOW=1024 RES=0x00 SYN URGP=0
> Feb 19 02:13:28 VM-e2b7 charon: 13[CFG] proposing traffic selectors for us:
> Feb 19 02:13:28 VM-e2b7 charon: 13[CFG] 0.0.0.0/0
> Feb 19 02:13:28 VM-e2b7 charon: 13[CFG] proposing traffic selectors for other:
> Feb 19 02:13:28 VM-e2b7 charon: 13[CFG] dynamic
>
> Thanks a lot for your assistance.
>
>
>
> On Tue, Feb 19, 2019 at 1:03 PM Kostya Vasilyev <[email protected]> wrote:
>> On Tue, Feb 19, 2019, at 12:50 PM, IL Ka wrote:
>> > > But it could also be the client trying to fetch the CA certificate's
>> CRL.
>> > I now think you are right.
>> >
>> > Client tries to fetch whole cert chain and fails to do so.
>> > It explains both: packet with DST=443 and client timeout.
>>
>> The missing EAP-identity support could also be an issue - there can be two
>> problems at once not one.
>>
>> But this sequence -
>>
>> connection almost up, server sends packet to client, UFW blocks packet from
>> client to server port 443
>>
>> - has occurred twice, in *two* of Moses' logs.
>>
>> Feb 19:
>>
>> Feb 19 02:10:01 VM-e2b7 charon: 11[NET] sending packet: from
>> 102.1*9.2**.***[4500] to 154.77.***.**[4500] (772 bytes)
>> Feb 19 02:10:01 VM-e2b7 kernel: [ 2543.189073] [UFW BLOCK] IN=ens3 OUT=
>> MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.77.***.**
>> DST=102.1*9.2**.*** LEN=52 TOS=0x10 PREC=0x20 TTL=116 ID=27223 DF PROTO=TCP
>> SPT=54229 DPT=443 WINDOW=17520 RES=0x00 SYN URGP=0
>> Feb 19 02:10:30 VM-e2b7 charon: 14[JOB] deleting half open IKE_SA with
>> 154.77.***.** after timeout
>>
>> Feb 15:
>>
>> Feb 15 20:13:11 VM-e2b7eaee-4c52-4455-8364-c1977c8afa6a charon: 08[NET]
>> sending packet: from 102.1*9.2*9.** [500] to 154.76.***.1*1 [500] (36
>> bytes)
>> Feb 15 20:13:12 VM-e2b7eaee-4c52-4455-8364-c1977c8afa6a kernel: [
>> 1898.916216] [UFW BLOCK] IN=ens3 OUT=
>> MAC=06:97:9c:00:00:8f:00:1d:b5:c0:a7:c0:08:00 SRC=154.76.122.161
>> DST=102.129.249.173 LEN=52 TOS=0x10 PREC=0x20 TTL=115 ID=24830 DF PROTO=TCP
>> SPT=57716 DPT=443 WINDOW=17520 RES=0x00 SYN URGP=0
>>
>> Unfortunately this log is cut off short, there is no "deleting half open
>> connection" here.
>>
>> But the server sending a UDP packet followed immediately by UFW BLOCK is.
>>
>> Moses - I would also consider getting things to work using the basic PSK
>> auth method and only then switching to certs and EAP.
>>
>> It just might be easier to solve problems one at a time.
>>
>> -- K
