1701 is L2TP port. It could be that Windows client tries several protos including PPTP/GRE, L2TP and so on.
What do you see on Windows side? Which error? On Tue, Feb 19, 2019 at 2:55 PM MOSES KARIUKI <kariuk...@gmail.com> 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 <k...@fastmail.com> 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 >> >> > >> > Whole chain must be installed on Win10 to sovle it >> > >> [ >> http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >> ] >> > Без вирусов. www.avg.com[ >> http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >> ] >> [ >> https://www.fastmail.com/mail/compose?u=c414417f#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2 >> ] >> > >> > On Tue, Feb 19, 2019 at 12:40 PM Kostya Vasilyev <k...@fastmail.com> >> wrote: >> >> >> >> On Tue, Feb 19, 2019, at 12:34 PM, IL Ka wrote: >> >> > >> >> > On Tue, Feb 19, 2019 at 8:48 AM Kostya Vasilyev <k...@fastmail.com> >> wrote: >> >> >> Looks like the connection is "almost there" but gets blocked by >> your firewall (UFW) >> >> >> >> >> >> Very end of your log: >> >> >> >> >> >> 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 >> >> > >> >> > >> >> > DPT=443 looks like OpenVPN or HTTPS. >> >> > IKE uses UDP/500 (or UDP/4500 in case of NAT). >> >> > >> >> > I am not sure this message is somehow connected to problem. >> >> > >> >> >> >> Could be unrelated - good find on the EAP-Identity >> >> >> >> But it could also be the client trying to fetch the CA certificate's >> CRL. >> >> >> >> Moses can you check if your CA cert has a CRL? >> >> >> >> openssl -text -noout -in your_CA_cert >> >> >> >> Is there a CRL? Is it an https:// link? >> >> >> >> X509v3 CRL Distribution Points: >> >> >> >> Full Name: >> >> URI:https://...... >> >> >> >> -- K >> >