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