Date: Thu, 16 Jan 2020 19:36:51 +0300 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: Victor Sudakov <vas@sibptus.ru>, Eugene Grosbein <eugen@grosbein.net> Cc: freebsd-net@freebsd.org, Michael Tuexen <tuexen@freebsd.org> Subject: Re: IPSec transport mode, mtu, fragmentation... Message-ID: <97b07801-da80-0665-aaa9-57184a52ce0f@yandex.ru> In-Reply-To: <20200116160745.GA1356@admin.sibptus.ru> References: <20191220152314.GA55278@admin.sibptus.ru> <4cc83b85-dd30-8c0d-330e-aa549ce98c98@yandex.ru> <f9b7357e-ced1-4ce5-40d5-8e3dcad42442@yandex.ru> <d263a709-63cf-7da5-1747-8a6791f6503f@grosbein.net> <20200116155305.GA465@admin.sibptus.ru> <55f7bafa-24c4-9810-0d21-f82cb332ee2d@grosbein.net> <20200116160745.GA1356@admin.sibptus.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --z7OlqF60UnZ6RtaY6Sq9DYDWzQRdoDSQQ Content-Type: multipart/mixed; boundary="QTouuRJEBBnaSeob6V7UsC1dhstCu13ya"; protected-headers="v1" From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: Victor Sudakov <vas@sibptus.ru>, Eugene Grosbein <eugen@grosbein.net> Cc: freebsd-net@freebsd.org, Michael Tuexen <tuexen@freebsd.org> Message-ID: <97b07801-da80-0665-aaa9-57184a52ce0f@yandex.ru> Subject: Re: IPSec transport mode, mtu, fragmentation... References: <20191220152314.GA55278@admin.sibptus.ru> <4cc83b85-dd30-8c0d-330e-aa549ce98c98@yandex.ru> <f9b7357e-ced1-4ce5-40d5-8e3dcad42442@yandex.ru> <d263a709-63cf-7da5-1747-8a6791f6503f@grosbein.net> <20200116155305.GA465@admin.sibptus.ru> <55f7bafa-24c4-9810-0d21-f82cb332ee2d@grosbein.net> <20200116160745.GA1356@admin.sibptus.ru> In-Reply-To: <20200116160745.GA1356@admin.sibptus.ru> --QTouuRJEBBnaSeob6V7UsC1dhstCu13ya Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 16.01.2020 19:07, Victor Sudakov wrote: > Eugene Grosbein wrote: >> >>> What beats me is that I cannot reproduce this problem in bhyve. In th= is >>> packet dump: http://admin.sibptus.ru/~vas/ipsec1.pcap.gz I'm scp-ing = a >>> 50M file from 192.168.246.10 (bhyve guest) to 192.168.246.1 (bhyve >>> host), and I see no fragments, and the largets packet is 1466 bytes, = and >>> the scp never stalls nor fails. >>> >>> Why is it NOT broken this time? >>> >>> Both hosts are 12.1-RELEASE-p1. >> >> I could not reproduce the problem with unpatched recent stable/11, eit= her :-) >=20 > Is there a way to view the MSS in the TCP segments before encryption or= > after decryption? I want to compare them in situations with IPSec > enabled and disabled. >=20 > I've never been able to see anything in "tcpdump -i enc0", probably it > cannot do transport mode IPSec because the man page talks about "outer > and inner header." For transport mode inner and outer headers will be the same. I guess the problem can be reproduced in the lab using the following conf= ig: [Host A] <--> [Router] <--> [Host B] IPsec should be configured between hosts A and B. Then you need to reduce MTU on the router. This should lead to ICMP NEEDFRAG messages from the router, and then host should correctly handle them. --=20 WBR, Andrey V. Elsukov --QTouuRJEBBnaSeob6V7UsC1dhstCu13ya-- --z7OlqF60UnZ6RtaY6Sq9DYDWzQRdoDSQQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAl4gkSMACgkQAcXqBBDI oXoFCwf/QhJkuf+DeK4lo6sTpaC+MPJwbSrxjzje5JlR3olYkF7rZPfq7heSbNol 6zHXB/gyk+NneppXuqcUmGloBlLZX+1rgPcZfh5re9sQmavQrB5gF9PNQpEe+A/2 TvgMGE05uLsfXmGRYNQqXXoSsYzbiLFYugtNzofG4FRhB3PT93vef2zcpBNZ2XO+ G67zqT1TuqAYuJOZ27Pchaz2lBMKchybe1WALniPTi7wM2voSwXWxPBViwfz0pPr 6NiBdghgM5EcrT/YjS9v0Ovbfi9A6jx5+u7/gE2B93VpgJHVJoL8eDb1rH4lG0T3 iuJmH4lFcn5jv2KGMZXsV9h+O7Dceg== =L09n -----END PGP SIGNATURE----- --z7OlqF60UnZ6RtaY6Sq9DYDWzQRdoDSQQ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?97b07801-da80-0665-aaa9-57184a52ce0f>