Eugene Grosbein wrote: > > >>> What beats me is that I cannot reproduce this problem in bhyve. In this > >>> 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, either > >> :-) > > > > 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. > > > > 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." > > enc0 does what you need but before you use it, remember: > > 1) before starting, you better change sysctls to: > > net.enc.in.ipsec_filter_mask=0 > net.enc.out.ipsec_filter_mask=0 > > so using enc0 does not pass packets over netpfilter rules extra time; > > 2) don't forget: ifconfig enc0 up
Perhaps I was forgetting some of those steps previously, because this time I got the desired traffic from enc0. > > 3) tcpdump has no means to filter by inner attributes in case of tunnel mode; > it still shows decoded IPSec transport mode packets correctly. Most importantly, Wireshark recognizes it as "Encapsulation type: OpenBSD enc(4) encapsulating interface" and shows the contents correctly. Back to the point. I've figured out that both encrypted (in transport mode) and unencrypted TCP segments have the same MSS=1460. Then I'm completely at a loss how the encrypted packets avoid being fragmented. TCP has no way to know in advance that encryption overhead will be added. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
signature.asc
Description: PGP signature