Hi,
On 11/03/2021 13:54, Gert Doering wrote:
Hi,
On Thu, Mar 11, 2021 at 11:12:27AM +0000, 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
