Re: [strongSwan] udp packet size
Hi Fred, -Original Message- On 12/03/2015 02:35, Steffen Plotner wrote: Hi, Strongswan 5.2.2 on linux (centos 6) IKEv2 configuration for windows clients I have the following problem: Initiator sends IKE_SA_INIT Server responds with IKE_SA_INIT Initiator sends IKE_AUTH Server responds with a fragmented IP packet of 1514 bytes (the MTU is 1500 on the outgoing interface). Just an update. Using ECDSA means these large packets are no longer an issue. Perhaps RSA is preferred from a security point of view; I don't know. But certainly the smaller key footprint without having to reduce the RSA keysize or use a short DN is maybe a good solution. I actually did try the ECSDA cert and saw that the packet sizes are small enough to not fragment, but the Windows 7 client does not understand it. It ends up just hanging the connection process. I found a reference about that here: https://www.mail-archive.com/users@lists.strongswan.org/msg04603.html Steffen ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Kernel panic with VTI tunnel
Hi Mike, that's right. I had no time to take a deeper look. Perhaps you have;-) Kind regards, André Am 16.03.2015 um 10:30 schrieb Mike Noordermeer: Hi, In the mail conversation, Steffen mentions that the patch should never be necessary, since outer_mode should not become NULL. So I doubt the patch would be the proper fix? It may fix this issue, but if the maintainer says the patch should not be necessary it seems like the wrong fix to me. Regards, Mike On 16 March 2015 at 10:19, André Valentin avalen...@marcant.net wrote: Hi! Please try the patch which is attached to the initial email. That shoud fix it. There is another bug with IPv6 which at first I ahrought at, but that's only with NAT. So please ignore that. So diffinig vanilla isn't needed. Kind regards, André Am 16.03.2015 um 09:50 schrieb Mike Noordermeer: Thanks... that looks very much like the same bug indeed. I will diff the various files of the Debian kernel and 3.18 vanilla to see if I can spot the change that introduced it. Regards, Mike On 16 March 2015 at 09:42, André Valentin avalen...@marcant.net wrote: Hi, take a look at this thread: http://marc.info/?t=14249509271r=1w=2 The initial mail is attached. I couldn't verfy the error with vanilla, but your error looks like mine. Have fun;-) André Am 16.03.2015 um 09:18 schrieb Mike Noordermeer: Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi
Re: [strongSwan] udp packet size
On 12/03/2015 02:35, Steffen Plotner wrote: Hi, Strongswan 5.2.2 on linux (centos 6) IKEv2 configuration for windows clients I have the following problem: Initiator sends IKE_SA_INIT Server responds with IKE_SA_INIT Initiator sends IKE_AUTH Server responds with a fragmented IP packet of 1514 bytes (the MTU is 1500 on the outgoing interface). Just an update. Using ECDSA means these large packets are no longer an issue. Perhaps RSA is preferred from a security point of view; I don't know. But certainly the smaller key footprint without having to reduce the RSA keysize or use a short DN is maybe a good solution. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Kernel panic with VTI tunnel
Hi, In the mail conversation, Steffen mentions that the patch should never be necessary, since outer_mode should not become NULL. So I doubt the patch would be the proper fix? It may fix this issue, but if the maintainer says the patch should not be necessary it seems like the wrong fix to me. Regards, Mike On 16 March 2015 at 10:19, André Valentin avalen...@marcant.net wrote: Hi! Please try the patch which is attached to the initial email. That shoud fix it. There is another bug with IPv6 which at first I ahrought at, but that's only with NAT. So please ignore that. So diffinig vanilla isn't needed. Kind regards, André Am 16.03.2015 um 09:50 schrieb Mike Noordermeer: Thanks... that looks very much like the same bug indeed. I will diff the various files of the Debian kernel and 3.18 vanilla to see if I can spot the change that introduced it. Regards, Mike On 16 March 2015 at 09:42, André Valentin avalen...@marcant.net wrote: Hi, take a look at this thread: http://marc.info/?t=14249509271r=1w=2 The initial mail is attached. I couldn't verfy the error with vanilla, but your error looks like mine. Have fun;-) André Am 16.03.2015 um 09:18 schrieb Mike Noordermeer: Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi 0xcd742975 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x439dd5bf790a1f7ba1979d798757bab94f62776c 128
Re: [strongSwan] ikev2 strongswan IKE_SA_INIT not have RFC 3947 Specification Vendor ID payload
Hello, Not sure this RFC is the correct one for IKEv2 implementations. You should read this one: https://tools.ietf.org/html/rfc5996#section-2.23 You will find what you have read in the strongswan's wiki. Regards, - Mail original - De: Deepak Khandelwal dazz...@gmail.com À: users@lists.strongswan.org Envoyé: Lundi 16 Mars 2015 18:06:36 Objet: [strongSwan] ikev2 strongswan IKE_SA_INIT not have RFC 3947 Specification Vendor ID payload Hi All, During our testing with IKEv2, we found that the 1 st packet(IKE_SA_INIT) does not have any information on vendor ID payload which is a MUST criteria as per the RFC. As per the RFC 3947. “ In the first two messages of Phase 1, the vendor id payload for this specification MUST be sent if supported (and it MUST be received by both sides) for the NAT- Traversal probe to continue. The content of the payload is the MD5 hash of RFC 3947 i checked strongswan wiki docs and here in below link https://wiki.strongswan.org/projects/strongswan/wiki/NatTraversal The NAT_DETECTION_SOURCE/DESTINATION_IP notifications included in the IKE_SA_INIT exchange indicate the peers NAT-T capability and if a NAT situation is detected, UDP encapsulation is activated for IPsec. Does this mean ikev2 first exchange message(s) does not need to have any information on vendor ID payload for RFC 3947 specification. or is there any config option to enable this setting ? thanks ! best Regards, Deepak ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Kernel panic with VTI tunnel
Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi 0xcd742975 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x439dd5bf790a1f7ba1979d798757bab94f62776c 128 src x.x.x.x dst y.y.y.y proto esp spi 0xc79db590 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x7bf0811323a4df1118680d30d4117ed403b60bd8 128 src y.y.y.y dst x.x.x.x proto esp spi 0xc8e198f5 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x1f1f32fc74a0d8ba38b9aab67fbbfff1024cf265 128 Kernel oops backtrace [31202.487290] BUG: unable to handle kernel NULL pointer dereference at 0034 [31202.499656] IP: [814e4a12] xfrm_input+0x3d2/0x590 [31202.502444] PGD 0 [31202.503479] Oops: [#1] SMP [31202.505121] Modules linked in: seqiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_hfsc sch_htb sch_ingress sch_sfq xt_statistic xt_CT xt_realm xt_LOG iptable_raw xt_connlimit xt_addrtype xt_comment xt_nat xt_recent ipt_ULOG ipt_REJECT ipt_MASQUERADE ipt_ECN ipt_CLUSTERIP ipt_ah nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip
Re: [strongSwan] Kernel panic with VTI tunnel
Hi, take a look at this thread: http://marc.info/?t=14249509271r=1w=2 The initial mail is attached. I couldn't verfy the error with vanilla, but your error looks like mine. Have fun;-) André Am 16.03.2015 um 09:18 schrieb Mike Noordermeer: Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi 0xcd742975 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x439dd5bf790a1f7ba1979d798757bab94f62776c 128 src x.x.x.x dst y.y.y.y proto esp spi 0xc79db590 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x7bf0811323a4df1118680d30d4117ed403b60bd8 128 src y.y.y.y dst x.x.x.x proto esp spi 0xc8e198f5 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x1f1f32fc74a0d8ba38b9aab67fbbfff1024cf265 128 Kernel oops backtrace [31202.487290] BUG: unable to handle kernel NULL pointer dereference at 0034 [31202.499656] IP: [814e4a12] xfrm_input+0x3d2/0x590 [31202.502444] PGD 0 [31202.503479] Oops: [#1] SMP [31202.505121] Modules linked in: seqiv xfrm6_mode_tunnel xfrm4_mode_tunnel xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo act_police cls_basic cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_hfsc
Re: [strongSwan] Kernel panic with VTI tunnel
Thanks... that looks very much like the same bug indeed. I will diff the various files of the Debian kernel and 3.18 vanilla to see if I can spot the change that introduced it. Regards, Mike On 16 March 2015 at 09:42, André Valentin avalen...@marcant.net wrote: Hi, take a look at this thread: http://marc.info/?t=14249509271r=1w=2 The initial mail is attached. I couldn't verfy the error with vanilla, but your error looks like mine. Have fun;-) André Am 16.03.2015 um 09:18 schrieb Mike Noordermeer: Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi 0xcd742975 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x439dd5bf790a1f7ba1979d798757bab94f62776c 128 src x.x.x.x dst y.y.y.y proto esp spi 0xc79db590 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x7bf0811323a4df1118680d30d4117ed403b60bd8 128 src y.y.y.y dst x.x.x.x proto esp spi 0xc8e198f5 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x1f1f32fc74a0d8ba38b9aab67fbbfff1024cf265 128 Kernel oops backtrace [31202.487290] BUG: unable to handle kernel NULL pointer dereference at 0034 [31202.499656] IP: [814e4a12] xfrm_input+0x3d2/0x590 [31202.502444]
Re: [strongSwan] StrongSwan Mac OS X app questions
Ken, Are there any issues with DNS StrongSwan Mac OS X app? The osx-attr plugin prepends the negotiated DNS servers to the currently configured ones. You may check with scutil if that works as expected. Not sure if keeping the current DNS servers installed is the best approach, maybe we should remove the previous servers. But we currently just add them to have them as a fallback. 2. EAP-GTC authentication. I would like to use EAP-GTC authentication with the Mac app and would be willing to modify the app to add this feature. Currently the eap-gtc plugin is not included in the build we provide. But I can do so for a next release. You may also check the build instructions [1] if you want to try that yourself (a note of warning: you need a code signing certificate to get thinks working). 3. Machine authentication. Why doesn’t the Mac app require a client certificate for machine authentication, as is required for the native Mac client? The native OS X client uses IKEv1, and usually XAuth. XAuth does both, Certificate and Password client authentication, but it also can use Hybrid Mode which skips certification authentication. The strongSwan App uses IKEv2, currently with EAP. In that protocol certificate client authentication is not included unless you do EAP-TTLS and a password based EAP method. Of course one could use Multiple Authentication as per RFC 4739, but as of now there is no option to configure that on the client. 4. Password configuration. It would be nice to be able to configure the user’s password, instead of having to enter it on every tunnel invocation. I agree, but such a functionality is still missing. Patches welcome; but we should rely on the Keychain to have some level of security for that password. Does the client cache the password for the entire session lifetime? Does the Mac app present the original password during re-authentication? No, I don't think that makes sense. If you want to re-evaluate user credentials and check if the same user still sits on that client, you'd need to re-prompt for the password. If you don't want to do that, instead of caching the password you may just disable re-authentication on the server, and use rekeying instead. You may do so in ipsec.conf by setting reauth=no. There is no security benefit in going through re-authentaction if you cache the password anyway. While re-prompting for the password in some scenarios might make sense, I don't think that this currently works. So there is probably no way around setting reauth=no on your server. Regards Martin [1]https://github.com/strongswan/strongswan/blob/master/src/frontends/osx/README.md ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Kernel panic with VTI tunnel
Hi! Please try the patch which is attached to the initial email. That shoud fix it. There is another bug with IPv6 which at first I ahrought at, but that's only with NAT. So please ignore that. So diffinig vanilla isn't needed. Kind regards, André Am 16.03.2015 um 09:50 schrieb Mike Noordermeer: Thanks... that looks very much like the same bug indeed. I will diff the various files of the Debian kernel and 3.18 vanilla to see if I can spot the change that introduced it. Regards, Mike On 16 March 2015 at 09:42, André Valentin avalen...@marcant.net wrote: Hi, take a look at this thread: http://marc.info/?t=14249509271r=1w=2 The initial mail is attached. I couldn't verfy the error with vanilla, but your error looks like mine. Have fun;-) André Am 16.03.2015 um 09:18 schrieb Mike Noordermeer: Hi, Do you happen to have any more specific info on this bugfix? I would rather not deviate from the Debian default kernels, so it would be nice if I could point the maintainers to a specific fix that should be backported. Thanks, Mike On 15 March 2015 at 17:02, Andre Valentin avalen...@marcant.net wrote: Hi! Try kernel 3.18. There's a bugfix for an issue like this. Kind regards, André Am 15.03.2015 um 15:15 schrieb Mike Noordermeer: Hi, I am currently experiencing the same kernel panic on multiple hosts, with a quite recent Linux kernel, and was wondering if anyone here has an idea of what the issue could be, or how I could further debug it. Any help is appreciated. I am using Linux 3.16 (3.16.7-ckt4-3~bpo70+1 from Debian wheezy-backports) and Strongswan 5.2.1 (5.2.1-5~bpo70+1 form Debian wheezy-backports). I have a fairly 'simple' tunnel with a mark and a left/right subnet of 0/0, and disabled install_routes in Strongswan. Then I have a VTI device configured with the same mark. This all works well, but causes a kernel panic every few hours, always on the same spot. As far as I can see, no fixes for such an issue have been committed to the kernel since version 3.16. From the backtrace it seems that xfrm_input() in the kernel is hitting a NULL dereference, when dereferencing 'outer_mode' in the xfrm_state struct, this line to be precise: https://github.com/torvalds/linux/blob/2e71029e2c32ecd59a2e8f351517bfbbad42ac11/include/net/xfrm.h#L1807 Any idea on why this could be NULL? Some config details and the full backtrace are below. Thanks, Mike Simplified ipsec.conf: config setup conn %default keyexchange = ikev2 dpdaction = restart esp = aes128gcm128-modp4096! ike = aes128gcm128-prfsha256-modp4096! mobike = no auto = route conn myconnection left = x.x.x.x leftcert = leftcert.crt leftsubnet = 0.0.0.0/0 right = y.y.y.y rightcert = rightcert.crt rightsubnet = 0.0.0.0/0 mark = 15 ip xfrm policy src 0.0.0.0/0 dst 0.0.0.0/0 dir fwd priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir in priority 3075 ptype main mark 15/0x tmpl src y.y.y.y dst x.x.x.x proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir out priority 3075 ptype main mark 15/0x tmpl src x.x.x.x dst y.y.y.y proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip xfrm state src x.x.x.x dst y.y.y.y proto esp spi 0xcb5c6f72 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x3d1c9ae2f921fc088b2e54a1d1efcd3e4441e502 128 src y.y.y.y dst x.x.x.x proto esp spi 0xcd742975 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x439dd5bf790a1f7ba1979d798757bab94f62776c 128 src x.x.x.x dst y.y.y.y proto esp spi 0xc79db590 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes)) 0x7bf0811323a4df1118680d30d4117ed403b60bd8 128 src y.y.y.y dst x.x.x.x proto esp spi 0xc8e198f5 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 15/0x aead rfc4106(gcm(aes))
Re: [strongSwan] StrongSwan Mac OS X app questions
On 16/03/2015 08:23, Martin Willi wrote: Ken, Are there any issues with DNS StrongSwan Mac OS X app? The osx-attr plugin prepends the negotiated DNS servers to the currently configured ones. You may check with scutil if that works as expected. Not sure if keeping the current DNS servers installed is the best approach, maybe we should remove the previous servers. But we currently just add them to have them as a fallback. In my case the local DNS server was being used instead of the DNS servers added by strongSwan. I could clearly see the them added in the both the strongSwan logfile and also in the output of scutil --dns. If I deleted them all and then added just the ones via the VPN, it all worked fine. Personally I think removing the previous servers would be better. This problem did go away in Yosemite so maybe it was a bug in previous versions of Mac OS X or odd expected behaviour. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
