Re: [Openvpn-users] mssfix set to zero
On Thu, Mar 11, 2021 at 05:06:49PM +, tincanteksup wrote: > Yes, i'm using http server on vpn server and wget on vpn client. Ok, so, on-the-fly TCP MSS clamping will also work in this scenario, which is a quite rare scenario anyway. ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] mssfix set to zero
On 11/03/2021 16:35, Marc SCHAEFER wrote: On Thu, Mar 11, 2021 at 03:25:25PM +, tincanteksup wrote: I was expecting that openvpn configure MSS at the IP level so that only the kernel manages that side of the packet creation. What would happen if the OpenVPN client is actually a router that forward trafic from a network ? In that case, only the dynamic TCP MSS clamping can work. The same if your OpenVPN server is not the end server you communicate with. The only case what you suggest might work is if the OpenVPN client *is* the application client and the OpenVPN server *is* the application server. In that case it would be enough that the tun or tap interface presents a MTU which takes in account OpenVPN header overhead. In my use cases, this nevers happens. Yes, i'm using http server on vpn server and wget on vpn client. ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] mssfix set to zero
Hi, On Thu, Mar 11, 2021 at 03:25:25PM +, tincanteksup wrote: > I was expecting that openvpn configure MSS at the IP level so > that only the kernel manages that side of the packet creation. This is hard to impossible for "locally created TCP sessions", and totally impossible for TCP sessions passing through OpenVPN as a router. > However, the above does match what I find: > > With > --ncp-disable --cipher AES-256-CBC --mssfix 1280 NO --fragment > > Sender: > 14:38:26.920435 IP 10.33.20.26.49268 > 10.33.20.1.80: Flags [S], seq > 1427850990, win 64240, options [mss 1460,sackOK,TS val 3860999194 ecr > 0,nop,wscale 6], length 0 This is the kernel MSS. > 14:38:26.922145 IP 10.33.20.1.80 > 10.33.20.26.49268: Flags [S.], seq > 1973493569, ack 1427850991, win 65160, options [mss 1115,sackOK,TS val > 329730242 This is the SYN ACK coming back, also subject to MSS manipulation. > Receiver: > 14:38:26.967006 IP 10.33.20.26.49268 > 10.33.20.1.80: Flags [S], seq > 1427850990, win 64240, options [mss 1115,sackOK,TS val 3860999194 ecr > 0,nop,wscale 6], length 0 This is the original SYN, after OpenVPN manipulated it. > 14:38:26.967037 IP 10.33.20.1.80 > 10.33.20.26.49268: Flags [S.], seq > 1973493569, ack 1427850991, win 65160, options [mss 1460,sackOK,TS val > 3297302424 ecr 3860999194,nop,wscale 7], length 0 This is the SYN ACK, before OpenVPN got its hand on it. > Both ends create a packet with mss 1460 > Both end receive a packet with mss 1115 Yes: because packet creation is "before OpenVPN got its hands on it", and reception is "after OpenVPN". (Now 1115 hints at "something isn't counting right", but it could be that with peer-id we indeed end up with an odd number of bytes for the per-packet overhead) > Instead, using only --link-mtu 1280 + --ncp-disable > > Sender: > 14:51:29.642213 IP 10.33.20.6.52306 > 10.33.20.1.80: Flags [S], seq > 3997192232, win 64670, options [mss 1115,sackOK,TS val 69514149 ecr > 0,nop,wscale 6], length 0 This is interesting. But it could be a caching effect (kernel learns the other end wants 1115, so remembers this). gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] mssfix set to zero
On Thu, Mar 11, 2021 at 03:25:25PM +, tincanteksup wrote: > I was expecting that openvpn configure MSS at the IP level so > that only the kernel manages that side of the packet creation. What would happen if the OpenVPN client is actually a router that forward trafic from a network ? In that case, only the dynamic TCP MSS clamping can work. The same if your OpenVPN server is not the end server you communicate with. The only case what you suggest might work is if the OpenVPN client *is* the application client and the OpenVPN server *is* the application server. In that case it would be enough that the tun or tap interface presents a MTU which takes in account OpenVPN header overhead. In my use cases, this nevers happens. ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] mssfix set to zero
Hi, On 11/03/2021 13:54, Gert Doering wrote: Hi, On Thu, Mar 11, 2021 at 11:12:27AM +, tincanteksup wrote: 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 "SYN SENT" is "when the system passes the packet towards OpenVPN", so you see the MSS value the sending kernel set. Then OpenVPN gets to see the packe, and does its thing. "SYN RECEIVED" is after the packet comes out of the OpenVPN tunnel, so all mss changes will only be seen "on the receiving end" I think I see what you mean: 1. The SYN packet is created as normal by the local kernel. 2. Packet is captured by openvpn. 3. MSS is edited by openvpn. (Also --fragment, --compress and --data-cipher etc.) 4. Encrypted Packet is sent through the tunnel. 5. Packet is decrypted. 6. Packet is received by remote kernel. If so then this is not what I was expecting. I was expecting that openvpn configure MSS at the IP level so that only the kernel manages that side of the packet creation. However, the above does match what I find: With --ncp-disable --cipher AES-256-CBC --mssfix 1280 NO --fragment Sender: 14:38:26.920435 IP 10.33.20.26.49268 > 10.33.20.1.80: Flags [S], seq 1427850990, win 64240, options [mss 1460,sackOK,TS val 3860999194 ecr 0,nop,wscale 6], length 0 14:38:26.922145 IP 10.33.20.1.80 > 10.33.20.26.49268: Flags [S.], seq 1973493569, ack 1427850991, win 65160, options [mss 1115,sackOK,TS val 329730242 Receiver: 14:38:26.967006 IP 10.33.20.26.49268 > 10.33.20.1.80: Flags [S], seq 1427850990, win 64240, options [mss 1115,sackOK,TS val 3860999194 ecr 0,nop,wscale 6], length 0 14:38:26.967037 IP 10.33.20.1.80 > 10.33.20.26.49268: Flags [S.], seq 1973493569, ack 1427850991, win 65160, options [mss 1460,sackOK,TS val 3297302424 ecr 3860999194,nop,wscale 7], length 0 Both ends create a packet with mss 1460 Both end receive a packet with mss 1115 Instead, using only --link-mtu 1280 + --ncp-disable Sender: 14:51:29.642213 IP 10.33.20.6.52306 > 10.33.20.1.80: Flags [S], seq 3997192232, win 64670, options [mss 1115,sackOK,TS val 69514149 ecr 0,nop,wscale 6], length 0 14:51:29.643931 IP 10.33.20.1.80 > 10.33.20.6.52306: Flags [S.], seq 2185726373, ack 3997192233, win 65254, options [mss 1115,sackOK,TS val 3177267971 ecr 69514149,nop,wscale 7], length 0 Receiver: 14:51:29.699917 IP 10.33.20.6.52306 > 10.33.20.1.80: Flags [S], seq 3997192232, win 64670, options [mss 1115,sackOK,TS val 69514149 ecr 0,nop,wscale 6], length 0 14:51:29.699961 IP 10.33.20.1.80 > 10.33.20.6.52306: Flags [S.], seq 2185726373, ack 3997192233, win 65254, options [mss 1118,sackOK,TS val 3177267971 ecr 69514149,nop,wscale 7], length 0 So, although openvpn is still making changes, the packet before transmission is more or less what I was expecting. I guess this is one of those things where openvpn has too many options and the same (similar) results can be achieved multiple ways. @Pippin https://community.openvpn.net/openvpn/wiki/HowPacketsFlow Your diagram is missing the kernel fragment/mss ;-) Thanks R ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] mssfix set to zero
Hi, On Thu, Mar 11, 2021 at 11:12:27AM +, tincanteksup wrote: > 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 "SYN SENT" is "when the system passes the packet towards OpenVPN", so you see the MSS value the sending kernel set. Then OpenVPN gets to see the packe, and does its thing. "SYN RECEIVED" is after the packet comes out of the OpenVPN tunnel, so all mss changes will only be seen "on the receiving end" gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] mssfix set to zero
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 +, 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(, MTU_TO_MSS(TUN_MTU_SIZE_DYNAMIC(>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 .. hm .. 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
Re: [Openvpn-users] mssfix set to zero
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 +, 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(, MTU_TO_MSS(TUN_MTU_SIZE_DYNAMIC(>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 .. hm .. 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 ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] mssfix set to zero
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 +, 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(, MTU_TO_MSS(TUN_MTU_SIZE_DYNAMIC(>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 .. hm .. I'll definitely look at --ncp-disable. ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] mssfix set to zero
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 +, 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(, MTU_TO_MSS(TUN_MTU_SIZE_DYNAMIC(>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
Re: [Openvpn-users] mssfix set to zero
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 +, 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(, MTU_TO_MSS(TUN_MTU_SIZE_DYNAMIC(>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 ] JJK Also ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] mssfix set to zero
On 09/03/2021 15:48, Gert Doering wrote: Hi, On Tue, Mar 09, 2021 at 03:33:56PM +, 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(, MTU_TO_MSS(TUN_MTU_SIZE_DYNAMIC(>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 uh-huh .. Simply for your amusement. ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] mssfix set to zero
On Tue, Mar 09, 2021 at 04:48:43PM +0100, Gert Doering wrote: > No. The code in question is not OS dependent (forward.c, mss.c, no > #ifdef _WIN32 anywhere close to "mss"). Some background: Actually, OpenVPN acts here as a firewall with inspection and mangling, as far as I understand, modifying packets as they flow. This is the equivalent of Linux iptables --clamp-mss-to-pmtu, except this autodetects from the interface, and OpenVPN probably substracts some more headers (its headers) from the total. Normally, the MSS is set during the initial TCP connection opening (the client sets one, the server sets one). Only by changing on-the-fly the TCP MSS can OpenVPN make that the client side, respectively the server side, respects the maximum possible MTU. Obviously this has no impact on UDP traffic. signature.asc Description: PGP signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] mssfix set to zero
Thanks Gert, interesting ways indeed ! On 09/03/2021 15:48, Gert Doering wrote: Hi, On Tue, Mar 09, 2021 at 03:33:56PM +, 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(, MTU_TO_MSS(TUN_MTU_SIZE_DYNAMIC(>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"). gert ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
Re: [Openvpn-users] mssfix set to zero
Hi, On Tue, Mar 09, 2021 at 03:33:56PM +, 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(, MTU_TO_MSS(TUN_MTU_SIZE_DYNAMIC(>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"). gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
[Openvpn-users] mssfix set to zero
Hi, 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. Also, would openvpn behave differently on *nix vs Windows with this setting. Thanks. ___ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
