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 ;-)
Thanks
R
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
