[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#908556: IPQoS change in 7.8p1 broke network access via Palo Alto Networks Global Protect

Package: openssh-server
Version: 1:7.8p1-1

Hi,
   since update to OpenSSH 7.8p1-1 my ssh connection is getting terminated
by RST as soon as OpenSSH figures out that this is interactive session, and
starts using non-zero ToS:

22:18:37.850520 00:08:e3:ff:fd:90 > 34:17:eb:b5:b5:57, ethertype IPv4 (0x0800), length 150: (tos 0x0, ttl 114, id 44915, offset 0, flags [none], proto TCP (6), length 136)
    10.16.112.99.60256 > 10.20.93.187.22: Flags [.], cksum 0xd1ea (correct), seq 3693:3789, ack 4721, win 3840, length 96
22:18:37.850533 00:08:e3:ff:fd:90 > 34:17:eb:b5:b5:57, ethertype IPv4 (0x0800), length 118: (tos 0x0, ttl 114, id 44920, offset 0, flags [none], proto TCP (6), length 104)
    10.16.112.99.60256 > 10.20.93.187.22: Flags [P.], cksum 0x7c83 (correct), seq 3789:3853, ack 4721, win 3840, length 64
22:18:37.850554 34:17:eb:b5:b5:57 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 64, id 35842, offset 0, flags [DF], proto TCP (6), length 40)
    10.20.93.187.22 > 10.16.112.99.60256: Flags [.], cksum 0xe25c (incorrect -> 0x6489), ack 3853, win 309, length 0
22:18:37.851382 34:17:eb:b5:b5:57 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 214: (tos 0x48, ttl 64, id 35843, offset 0, flags [DF], proto TCP (6), length 200)
    10.20.93.187.22 > 10.16.112.99.60256: Flags [P.], cksum 0xe2fc (incorrect -> 0x8767), seq 4721:4881, ack 3853, win 309, length 160
22:18:37.851515 34:17:eb:b5:b5:57 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 342: (tos 0x48, ttl 64, id 35844, offset 0, flags [DF], proto TCP (6), length 328)
    10.20.93.187.22 > 10.16.112.99.60256: Flags [P.], cksum 0xe37c (incorrect -> 0xb328), seq 4881:5169, ack 3853, win 309, length 288
22:18:37.851570 34:17:eb:b5:b5:57 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 246: (tos 0x48, ttl 64, id 35845, offset 0, flags [DF], proto TCP (6), length 232)
    10.20.93.187.22 > 10.16.112.99.60256: Flags [P.], cksum 0xe31c (incorrect -> 0x74ba), seq 5169:5361, ack 3853, win 309, length 192
22:18:37.854537 34:17:eb:b5:b5:57 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 118: (tos 0x48, ttl 64, id 35846, offset 0, flags [DF], proto TCP (6), length 104)
    10.20.93.187.22 > 10.16.112.99.60256: Flags [P.], cksum 0xe29c (incorrect -> 0xdb54), seq 5361:5425, ack 3853, win 309, length 64
22:18:37.929327 34:17:eb:b5:b5:57 > 00:08:e3:ff:fd:90, ethertype IPv4 (0x0800), length 118: (tos 0x48, ttl 64, id 35847, offset 0, flags [DF], proto TCP (6), length 104)
    10.20.93.187.22 > 10.16.112.99.60256: Flags [P.], cksum 0xe29c (incorrect -> 0xdb54), seq 5361:5425, ack 3853, win 309, length 64
22:18:38.141863 00:08:e3:ff:fd:90 > 34:17:eb:b5:b5:57, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 114, id 10177, offset 0, flags [none], proto TCP (6), length 40)
    10.16.112.99.60256 > 10.20.93.187.22: Flags [R], cksum 0x2ae6 (correct), seq 3044012753, win 3840, length 0

Once I added 'IPQoS 0x00' into /etc/ssh/sshd_config, things are back in
working order.

I suspect that Palo Alto Network's Global Protect VPN our company
uses for remote access is throwing away or corrupting packets with
non-zero QoS.  Unfortunately it seems that Global Protect VPN
prevents wireshark from starting, so I do not have packet trace
from client side.

I'm not sure if there is anything that can be done on Debian/OpenSSH side,
but maybe it will help someone else who suffers from same problem.

Thanks,
Petr Vandrovec
Reply to: