From owner-freebsd-bugs@freebsd.org Sun May 12 18:45:10 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C0D9159EE84 for ; Sun, 12 May 2019 18:45:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E8D1383ADA for ; Sun, 12 May 2019 18:45:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A8B6C159EE83; Sun, 12 May 2019 18:45:09 +0000 (UTC) Delivered-To: bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84CDF159EE82 for ; Sun, 12 May 2019 18:45:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2212483AD9 for ; Sun, 12 May 2019 18:45:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 422401E263 for ; Sun, 12 May 2019 18:45:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x4CIj8Wi068194 for ; Sun, 12 May 2019 18:45:08 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x4CIj8i1068190 for bugs@FreeBSD.org; Sun, 12 May 2019 18:45:08 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 237853] pfsync does not sync state's "tag"? Date: Sun, 12 May 2019 18:45:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: johan@stromnet.se X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2019 18:45:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237853 Bug ID: 237853 Summary: pfsync does not sync state's "tag"? Product: Base System Version: 11.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: johan@stromnet.se In short, if a state is received via pfsync, and it's associated with a rule that has a tag, should that tag be applied to matching packet(s) the same w= ay it would have been if the state was used on the original machine creating t= he state? It seems that this is not the case. pfsync_state_import (https://github.com/freebsd/freebsd/blob/master/sys/netpfil/pf/if_pfsync.c#= L459) does not seem to set pf_state->tag, something which pf_create_state does on= the origin machine (https://github.com/freebsd/freebsd/blob/master/sys/netpfil/pf/pf.c#L3786). Not sure if this is a bug or just me missing something, but looking at the = code it seems it *could* be something that's missing, unless there is an undocumented (?) design decision. Longer version: I got two 11.2 machines (gw1, gw2) doing routing with vlans, carp interface= s, PF and PFSync. The PF rulesets are in sync (same checksum). There are multi= ple vlans, and one vlan (vlan2) is just used between gw1 and gw2 for pfsync, an= d in some cases some traffic exchange due to potential asymmetric routing. In the example below, we also have a machine "srv1", 172.28.1.2/24 on vlan1= 0, which uses the carp IP of gw1/2 as default gateway (here gw1 is master). The problematic scenario is when gw2 (backup) tries to communicate with srv= 1, and is sending from a "loopback" IP 172.28.3.249/30 (this also happens to be the one on vlan2, I use that to universally reach the box, regardless from which network). gw2 will send UDP directly out on vlan10, but when srv1 replies to 172.28.3.249, it uses it's default gw so it ends up at gw1. Then gw1 is supposed to forward this to gw2 via vlan2. The outbound traffic from gw2 reaches srv1, and the return traffic from srv1 reaches gw1. But here it is *partially* blocked by pf. I have the following rule (148) to allow this traffic out from (in this cas= e) gw2, and some other relevant rules: @2 block return log on vlan2 all @117 pass out all flags S/SA keep state tagged FWD @148 pass out on vlan10 inet proto udp from any to 172.28.1.2 port =3D 1514= keep state (udp.first 1000, udp.single 1000, udp.multiple 1000) tag FWD The ideas is that the outbound packet on vlan10 creates a state which has t= he tag FWD, and if needed the potential return traffic via the other gw, can be passed out on vlan2. A state gets created on gw2, and is synced fine to gw1 (with same rule ID in pfctl -vvss) As seen on gw1: all udp 172.28.3.249:29940 -> 172.28.1.2:1514 MULTIPLE:MULTIPLE age 00:20:21, expires in 00:16:21, 0:3 pkts, 0:335 bytes, rule 148 id: 010000005cb20e38 creatorid: 14f0eda0 As seen on gw2: all udp 172.28.3.249:29940 -> 172.28.1.2:1514 MULTIPLE:MULTIPLE age 00:20:21, expires in 00:16:20, 41:2 pkts, 9813:202 bytes, rule 148 id: 010000005cb20e38 creatorid: 14f0eda0 When 172.8.1.2 is replying to 172.28.3.249, the state packet counter on gw1= is incremented, indicating that it is matched. The intention is that it should go out on vlan2 on gw1, to finally reach gw= 2. The routing itself works, but it is blocked by rule2: 13:00:16.094793 rule 2/0(match): block out on vlan2: (tos 0x0, ttl 63, id 14679, offset 0, flags [none], proto UDP (17), length 101) 172.28.1.2.1514 > 172.28.3.249.29940: [udp sum ok] UDP, length 73 As the packet has matched a state associated with rule @148, I would expect that it was tagged with the FWD tag, and thus allowed out on vlan2 as per r= ule @117. A simple workaround in this particular case is to just make sure the traffic origins from IP on vlan10, so it can reply directly, but in some other cases this might be more tricky. --=20 You are receiving this mail because: You are the assignee for the bug.=