Just for the record the latest OpenBSD snapshot with the changed ssh / sshd
causes ssh connections to fail
across a VMWare Fusion 10 NAT network.
ssh into the box you get a banner sent before the connection is closed.
ssh out of the like updating a CVS tree gets you...
Obtaining OpenBSD-current src tree.
packet_write_wait: Connection to 130.102.79.219 port 22: Broken pipe
cvs [update aborted]: end of file from server (consult above messages if any)
Finished obtaining OpenBSD-current src tree.
Adding
IPQoS lowdelay
to both the ssh_config / ssh_config make this work as before.
Machines on the Internal network can SSH into and out amongst each other but
going across the NAT boundary to the real world fails.
With the state of VMWare (the company) I doubt there will be a fix for Fusion
anytime soon.
Leaving this here for the archives.
Ian McWilliam
________________________________
From: owner-t...@openbsd.org <owner-t...@openbsd.org> on behalf of Stuart
Henderson <s...@spacehopper.org>
Sent: Monday, 2 April 2018 12:06 AM
To: Job Snijders
Cc: tech@openbsd.org
Subject: Re: [PATCH] Update default QoS markers for ssh
On 2018/04/01 13:29, Job Snijders wrote:
> On Sun, Apr 01, 2018 at 11:29:55AM +0100, Stuart Henderson wrote:
> > On 2018/03/31 16:10, Job Snijders wrote:
> > > TL;DR: I propose to update the defaults to use DSCP "AF21" (Low
> > > Latency Data) for interactive session traffic, and CS1 ("Lower
> > > Effort") for non-interactive traffic. This applies to both IPv4 and
> > > IPv6.
> >
> > I think this is the right thing to do, but needs handling in
> > conjunction with changes to PF, which has dual queue-setting
> > (IPTOS_LOWDELAY packets go in one queue along with empty TCP ACKs,
> > other packets can go in another lower priority queue).
> >
> > Since firewalls are often updated less often than hosts I think it
> > would be better if the PF side was done first with some time to give
> > people chance to update, though it doesn't need to be too long (they
> > can set qos in sshd_config if they want to retain the old setting).
> >
> > A few other pieces use IPTOS_LOWDELAY (pfsync, carp, vxlan, etherip)
> > which I think would want switching too.
>
> What we're looking at is some kind of "migrate TOS to DSCP" project.
> There is a few tens of files where TOS values need to be examined and an
> appropiate DSCP value choosen.
Yes, that's clearly a much bigger scope. But if we're starting with ssh
those should be on the radar too IMO.
> I'm not sure I'd go as far as blindly
> replacing IPTOS_LOWDELAY with IPTOS_DSCP_AF21, but perhaps as a
> transition that is what is needed in some places.
Indeed. For some of these uses (like carp) something like CS7 seems
more appropriate. ssh seems a great place to start gaining more
experience with this - in particular any breakage can be handled
more easily than things like carp (since ssh already has config
options for this).
> We can start by treating IPTOS_LOWDELAY and IPTOS_DSCP_AF21 similarly in
> pf (see untested patch below), and then accept patches that migrate from
> TOS to DSCP?
That approach generally makes sense to me. It seems that some other
codepoints should probably also be treated as higher priority but
I'm not quite sure which yet...
> As far as I understand, out-of-the-box pf doesn't do anything with TOS
> values, so users wlil have to have explicitly configured something on
> the firewall or clients anyhow?
Yes, the firewall needs to have queues enabled and traffic assigned with
"set queue (foo, bar)" syntax.
> Kind regards,
>
> Job
>
> share/man/man5/pf.conf.5 | 12 +++++++++---
> sys/net/pf.c | 8 +++++---
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git share/man/man5/pf.conf.5 share/man/man5/pf.conf.5
> index 13e23423daa..f5a65e1b0d4 100644
> --- share/man/man5/pf.conf.5
> +++ share/man/man5/pf.conf.5
> @@ -679,7 +679,9 @@ interface, the queueing priority will also be written as
> the priority
> code point in the 802.1Q VLAN header.
> If two priorities are given, TCP ACKs with no data payload and packets
> which have a TOS of
> -.Cm lowdelay
> +.Cm lowdelay ,
> +or DSCP value
> +.Cm af21 ,
> will be assigned to the second one.
> Packets with a higher priority number are processed first,
> and packets with the same priority are processed
> @@ -702,7 +704,9 @@ section.
> Packets matching this rule will be assigned to the specified
> .Ar queue .
> If two queues are given, packets which have a TOS of
> -.Cm lowdelay
> +.Cm lowdelay ,
> +or DSCP value
> +.Cm af21 ,
> and TCP ACKs with no data payload will be assigned to the second one.
> See
> .Sx QUEUEING
> @@ -1608,7 +1612,9 @@ Normally only one
> .Ar queue
> is specified; when a second one is specified it will instead be used for
> packets which have a TOS of
> -.Cm lowdelay
> +.Cm lowdelay ,
> +or DSCP value
> +.Cm af21 ,
> and for TCP ACKs with no data payload.
> .Pp
> To continue the previous example, the examples below would specify the
> diff --git sys/net/pf.c sys/net/pf.c
> index d841f834af1..aac20603a01 100644
> --- sys/net/pf.c
> +++ sys/net/pf.c
> @@ -2804,7 +2804,7 @@ pf_build_tcp(const struct pf_rule *r, sa_family_t af,
> h->ip_len = htons(tlen);
> h->ip_v = 4;
> h->ip_hl = sizeof(*h) >> 2;
> - h->ip_tos = IPTOS_LOWDELAY;
> + h->ip_tos = IPTOS_DSCP_AF21;
> h->ip_len = htons(len);
> h->ip_off = htons(ip_mtudisc ? IP_DF : 0);
> h->ip_ttl = ttl ? ttl : ip_defttl;
> @@ -7020,7 +7020,8 @@ done:
> pf_scrub(pd.m, s->state_flags, pd.af, s->min_ttl,
> s->set_tos);
> pf_tag_packet(pd.m, s->tag, s->rtableid[pd.didx]);
> - if (pqid || (pd.tos & IPTOS_LOWDELAY)) {
> + if (pqid || (pd.tos & IPTOS_LOWDELAY)
> + || (pd.tos & IPTOS_DSCP_AF21)) {
> qid = s->pqid;
> if (s->state_flags & PFSTATE_SETPRIO)
> pd.m->m_pkthdr.pf.prio =
> s->set_prio[1];
> @@ -7032,7 +7033,8 @@ done:
> } else {
> pf_scrub(pd.m, r->scrub_flags, pd.af, r->min_ttl,
> r->set_tos);
> - if (pqid || (pd.tos & IPTOS_LOWDELAY)) {
> + if (pqid || (pd.tos & IPTOS_LOWDELAY)
> + || (pd.tos & IPTOS_DSCP_AF21)) {
> qid = r->pqid;
> if (r->scrub_flags & PFSTATE_SETPRIO)
> pd.m->m_pkthdr.pf.prio =
> r->set_prio[1];
>
