New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
xfrm interface ipsec1 exist after core dump and blocking restart of ipsec service clean #585
Comments
|
thanks for capturing the full packet. I replayed it in my test setup but it did not crash. Can you give me your /etc/ipsec.conf and any included conf files so I can fully reproduce your setup? Dec 21 18:08:21.770741: | *received 204 bytes from 192.1.2.45:48730 on eth1 192.1.2.23:500 using UDP |
|
Never mind. Cagney already fixed it. I can confirm the packet you captured causes a crash in libreswan 4.2 - 4.5 |
|
That is correct. Thanks @cagney and the team. When will release 4.6 which may incorporate this fix? |
|
On Wed, 22 Dec 2021, MyOzCam wrote:
That is correct. Thanks @cagney and the team.
When will release 4.6 which may incorporate this fix?
January 5.
If you want something sooner try:
git clone github.com/libreswan/libreswan
cd libreswan
make rpm
|
After setting up plutodebug=base, I got the packet which may cause core dump when ikev1 is not accept
Dec 21 02:43:35 localhost pluto[2787]: | *received 204 bytes from 101.4.62.36:43357 on eth0 192.168.99.102:500 using UDP
Dec 21 02:43:35 localhost pluto[2787]: | 31 27 fc b0 38 10 9e 89 00 00 00 00 00 00 00 00 1'..8...........
Dec 21 02:43:35 localhost pluto[2787]: | 01 10 02 00 00 00 00 00 00 00 00 cc 0d 00 00 5c ...............
Dec 21 02:43:35 localhost pluto[2787]: | 00 00 00 01 00 00 00 01 00 00 00 50 01 01 00 02 ...........P....
Dec 21 02:43:35 localhost pluto[2787]: | 03 00 00 24 01 01 00 00 80 01 00 05 80 02 00 02 ...$............
Dec 21 02:43:35 localhost pluto[2787]: | 80 04 00 02 80 03 00 03 80 0b 00 01 00 0c 00 04 ................
Dec 21 02:43:35 localhost pluto[2787]: | 00 00 0e 10 31 27 fc b0 38 10 9e 89 00 00 00 00 ....1'..8.......
Dec 21 02:43:35 localhost pluto[2787]: | 00 00 00 00 01 10 02 00 00 00 00 00 00 00 00 cc ................
Dec 21 02:43:35 localhost pluto[2787]: | 0d 00 00 5c 00 00 00 01 00 00 00 01 00 00 00 50 ..............P
Dec 21 02:43:35 localhost pluto[2787]: | 01 01 00 02 03 00 00 24 01 01 00 00 80 01 00 05 .......$........
Dec 21 02:43:35 localhost pluto[2787]: | 80 02 00 02 80 04 00 02 80 03 00 03 80 0b 00 01 ................
Dec 21 02:43:35 localhost pluto[2787]: | 00 0c 00 04 00 00 0e 10 00 00 00 24 02 01 00 00 ...........$....
Dec 21 02:43:35 localhost pluto[2787]: | 80 01 00 05 80 02 00 01 80 04 00 02 80 03 00 03 ................
Dec 21 02:43:35 localhost pluto[2787]: | 80 0b 00 01 00 0c 00 04 00 00 0e 10 ............
Dec 21 02:43:35 localhost pluto[2787]: | **parse ISAKMP Message:
Dec 21 02:43:35 localhost pluto[2787]: | initiator SPI: 31 27 fc b0 38 10 9e 89
Dec 21 02:43:35 localhost pluto[2787]: | responder SPI: 00 00 00 00 00 00 00 00
Dec 21 02:43:35 localhost pluto[2787]: | next payload type: ISAKMP_NEXT_SA (0x1)
Dec 21 02:43:35 localhost pluto[2787]: | ISAKMP version: ISAKMP Version 1.0 (rfc2407) (0x10)
Dec 21 02:43:35 localhost pluto[2787]: | exchange type: ISAKMP_XCHG_IDPROT (0x2)
Dec 21 02:43:35 localhost pluto[2787]: | flags: none (0x0)
Dec 21 02:43:35 localhost pluto[2787]: | Message ID: 0 (00 00 00 00)
Dec 21 02:43:35 localhost pluto[2787]: | length: 204 (00 00 00 cc)
Dec 21 02:43:35 localhost pluto[2787]: | processing version=1.0 packet with exchange type=ISAKMP_XCHG_IDPROT (2)
Dec 21 02:43:35 localhost pluto[2787]: | State DB: IKEv1 state not found (find_state_ikev1_init)
Dec 21 02:43:35 localhost pluto[2787]: | #null state always idle
Dec 21 02:43:35 localhost pluto[2787]: | got payload 0x2 (ISAKMP_NEXT_SA) needed: 0x2 opt: 0x2080
Dec 21 02:43:35 localhost pluto[2787]: | ***parse ISAKMP Security Association Payload:
Dec 21 02:43:35 localhost pluto[2787]: | next payload type: ISAKMP_NEXT_VID (0xd)
Dec 21 02:43:35 localhost pluto[2787]: | length: 92 (00 5c)
Dec 21 02:43:35 localhost pluto[2787]: | DOI: ISAKMP_DOI_IPSEC (0x1)
Dec 21 02:43:35 localhost pluto[2787]: | got payload 0x2000 (ISAKMP_NEXT_VID) needed: 0x0 opt: 0x2080
Dec 21 02:43:36 localhost systemd[1]: ipsec.service: Main process exited, code=dumped, status=11/SEGV
Dec 21 02:43:36 localhost systemd[1]: ipsec.service: Failed with result 'core-dump'.
Dec 21 02:43:36 localhost systemd[1]: ipsec.service: Consumed 2.706s CPU time.
Dec 21 02:43:36 localhost systemd[1]: ipsec.service: Scheduled restart job, restart counter is at 2.
Dec 21 02:43:36 localhost systemd[1]: Stopped Internet Key Exchange (IKE) Protocol Daemon for IPsec.
Dec 21 02:43:36 localhost systemd[1]: ipsec.service: Consumed 2.706s CPU time.
Dec 21 02:43:36 localhost systemd[1]: Starting Internet Key Exchange (IKE) Protocol Daemon for IPsec...
normally after core dump the IPsec service restart but unfortunately the original xfrm interface was not clear and cause below:
Dec 21 02:43:38 localhost pluto[3815]: "ikev2-cp": conflict ipsec1 already exist cannot support xfrm-interface. May be leftover from previous pluto?
Dec 21 02:43:38 localhost pluto[3815]: "ikev2-cp": failed to add connection: ipsec-interface=1 not supported. device name conflict in xfrm_iface_supported()
This cause the VPN server not accept any connection request and need manual restart the service.
Any workaround?
The text was updated successfully, but these errors were encountered: