Menu
▾
▴
Re: [Openvpn-users] mssfix set to zero
|
From: tincanteksup <tin...@gm...> - 2021-03-11 11:47:16
|
On 11/03/2021 11:12, tincanteksup wrote: > > > On 11/03/2021 03:05, tincanteksup wrote: >> >> >> On 11/03/2021 02:58, tincanteksup wrote: >>> Hi, >>> >>> On 11/03/2021 01:41, Jan Just Keijser wrote: >>>> Hi, >>>> >>>> On 11/03/21 00:16, tincanteksup wrote: >>>>> >>>>> >>>>> On 09/03/2021 15:48, Gert Doering wrote: >>>>>> Hi, >>>>>> >>>>>> On Tue, Mar 09, 2021 at 03:33:56PM +0000, tincanteksup wrote: >>>>>>> what is the final effect of using `--mssfix 0` in a client >>>>>>> config ? >>>>>>> >>>>>>> What I mean is, how would openvpn interpret this and what would >>>>>>> it tell the TCP stack ? >>>>>>> >>>>>>> I don't need to know about MSS, I just want to know what openvpn >>>>>>> would do with a setting of 0. >>>>>> >>>>>> I would expect things to break in most interesting ways. >>>>>> >>>>>> From what I can see, the code does not enforce a minimum value, but >>>>>> isn't directly *using* that value either. It will be modified by >>>>>> this macro >>>>>> >>>>>> mss_fixup_ipv6(&ipbuf, >>>>>> MTU_TO_MSS(TUN_MTU_SIZE_DYNAMIC(&c->c2.frame))); >>>>>> >>>>>> to figure out the final MSS value to put into the TCP SYN/SYN ACK >>>>>> packets. Since "0" is the expected *outer* maximum, the net result >>>>>> is likely something negative, which will end up as a large positive >>>>>> number in the 16 bit MSS field. >>>>>> >>>>>> Run tcpdump/wireshark and find out :-) >>>>>> >>>>>>> Also, would openvpn behave differently on *nix vs Windows with >>>>>>> this setting. >>>>>> >>>>>> No. The code in question is not OS dependent (forward.c, mss.c, no >>>>>> #ifdef _WIN32 anywhere close to "mss"). >>>>>> >>>>> >>>>> So, Windows Wireshark verses Linux tcpdump .. fun and games .. >>>>> All --dev tun >>>>> >>>>> Windows ovpn-cli WireShark: >>>>> vbox - Win7 >>>>> TAP adapter >>>>> MTU 1500 (Ethernet 1500, TAP driver config 1500 and no MTU settings >>>>> configured in cli.ovpn) >>>>> SYN packet SENT >>>>> ---- >>>>> # Packet 60 from >>>>> C:\Users\IEUser\AppData\Local\Temp\wireshark_OpenVPN >>>>> TAP-Windows68T9PZ0.pcapng >>>>> - 61 >>>>> - 250.056710 >>>>> - 10.33.20.6 >>>>> - 10.33.20.1 >>>>> - TCP >>>>> - 66 >>>>> - >>>>> - >>>>> - 49254 >>>>> - 80 >>>>> - Sequence Number (raw): 3641931747 >>>>> - 49254 → 80 [SYN] Seq=0 Win=8192 Len=0 MSS=*1460* WS=256 SACK_PERM=1 >>>>> ---- >>>>> >>>>> Linux ovpn-srv tcpdump: >>>>> Real hardware >>>>> MTU 1500 (eth0 1500, tunx 1500 and no MTU settings configured in >>>>> srv.conf) >>>>> SYN packet RECEIVED >>>>> ---- >>>>> 22:32:05.050166 IP 10.33.20.6.49254 > 10.33.20.1.80: Flags [S], seq >>>>> 3641931747, win 8192, options [mss *1188*,nop,wscale >>>>> 8,nop,nop,sackOK], length 0 >>>>> ---- >>>>> >>>>> Linux ovpn-cli tcpdump: >>>>> vbox - Arch Linux 64bit >>>>> MTU 1500 (eth0 1500, tunx 1500 and no MTU settings configured in >>>>> srv.conf) >>>>> SYN packet SENT >>>>> ---- >>>>> 23:00:46.164814 IP 10.33.20.10.60642 > 10.33.20.1.80: Flags [S], >>>>> seq 3275200057, win 64240, options [mss *1460*,sackOK,TS val >>>>> 342885876 ecr 0,nop,wscale 6], length 0 >>>>> ---- >>>>> >>>>> Linux ovpn-srv tcpdump: >>>>> Real hardware >>>>> MTU 1500 (eth0 1500, tunx 1500 and no MTU settings configured in >>>>> srv.conf) >>>>> SYN packet RECEIVED >>>>> ---- >>>>> 23:00:46.234925 IP 10.33.20.10.60642 > 10.33.20.1.80: Flags [S], >>>>> seq 3275200057, win 64240, options [mss *1357*,sackOK,TS val >>>>> 342885876 ecr 0,nop,wscale 6], length 0 >>>>> ---- >>>>> >>>>> >>>>> The only thing I can think of is VBox interfering. >>>>> Host Linux >>>>> - Guest Win7 in VBox bridge mode >>>>> - Guest Arch in VBox bridge mode >>>>> (same machine, same single NIC) >>>>> >>>>> Also, openvpn man: >>>>> --mssfix max | Default value of 1450 >>>>> >>>> >>>> the server-side channel parameters can be quite different compared >>>> to the client-side parameters, as caused by NCP. Rerun your test with >>>> ncp-disable >>>> on the server side to see if that makes any difference. >>>> I know that the tun MTU itself stays the same but look for the line >>>> Data Channel MTU parms [ L:1621 D:1621 EF:121 EB:406 ET:0 EL:3 ] >>>> >>> >>> I will try with --ncp-disable, thanks for the reminder! >>> >>> However, for now it is enough to say that irc:freenode#vbox.rfm >>> confirmed that; it is likely that vbox makes some adjustments to >>> packets egressing from vbox bridged-connections because .. >>> reasons. eg. MTU on host and guest are different or the same! >>> >>> I can live with that ;-) >> >> On second thought though .. >> >> this is a packet egressing the TUN device under the OS, which is >> then handed over to openvpn for encryption .. and then my vpn is >> UDP not TCP .. hmmmmm .. >> >> I'll definitely look at --ncp-disable. > > Taking vbox out of the equation by using real hardware: > > Win7 > ovpn 2.5 > SYN sent - MSS 1460 > > Linux 5.4.0-66-generic #74-Ubuntu > ovpn git-master > SYN received - MSS 1358 > > Still have to test --ncp-disable With --ncp-disable and --cipher AES-256-CBC Win7 SYN sent MSS 1460 SYN-ACK received MSS 1286 Linux SYN received MSS 1286 SYN-ACK sent MSS 1460 Srv-log: 2021-03-11 11:15:46 us=807202 10.1.101.123:58704 Control Channel MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ] 2021-03-11 11:15:46 us=807248 10.1.101.123:58704 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ] srv-mtu-test: 2021-03-11 11:18:57 us=376434 cd07/10.1.101.123:58704 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1560,1560] remote->local=[1544,1448] 2021-03-11 11:18:57 us=376519 cd07/10.1.101.123:58704 NOTE: This connection is unable to accommodate a UDP packet size of 1560. Consider using --fragment or --mssfix options as a workaround. Which is odd for MTU .. and a dodgy message too .. Real MTU for both devices is 1500, as is the router in between. Unencrypted IPv4 on-the-wire Win 7 SYN sent MSS 1460 SYN-ACK received MSS 1460 Linux SYN received MSS 1460 SYN-ACK sent MSS 1460 Any thoughts ? -- |
