From owner-freebsd-ipfw@freebsd.org Mon May 30 04:56:54 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19730B51B84 for ; Mon, 30 May 2016 04:56:54 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E4A631A7E for ; Mon, 30 May 2016 04:56:53 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-225-151.lns20.per1.internode.on.net [121.45.225.151]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u4U4umEx027609 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 29 May 2016 21:56:51 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: [RFC] ipfw named states support To: freebsd-ipfw@freebsd.org References: <573C803E.5020600@FreeBSD.org> From: Julian Elischer Message-ID: <3c2d7675-926d-5987-fef7-6e6799a43834@freebsd.org> Date: Mon, 30 May 2016 12:56:42 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <573C803E.5020600@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 04:56:54 -0000 On 18/05/2016 10:46 PM, Andrey V. Elsukov wrote: > Hi All, > > We have the patch that adds named states support to ipfw. like it and have wished for this for along time this allows per-interface state. Can state name be set to a variable we can set or something? then we could have subroutines that can be used for multiple interfaces. (I guess we need variables first) > This expands flexibility and functionality. > Imagine the situation: > > [ LAN1 ] <---> [ FW ] <---> [ LAN2 ] > > add skipto 10000 ip from any to any via lan1 > add skipto 20000 ip from any to any via lan2 > add deny ip from any to any > add 10000 count ip from any to any > ... > add allow ip from to any keep-state in > add deny ip from any to any > add 20000 count ip from any to any > ... > add allow ip from to any keep-state in > add deny ip from any to any > > The problem is that a state created by first keep-state rule will act on > second keep-state rule and allow traffic to go into (out from router's > point of view) lan2 without any rules actually allowing that. > > With named states we can create separate states for each interface and > they will not match when we don't want this. what does the ipfw -d list output look like? > What I want to discuss > ---------------------- > > 1. Is this feature useful? > 2. How to commit it? Due to changed syntax it can break existing > rulesets. Probably, we can add some mandatory prefix to state name, e.g. > ':'. > From owner-freebsd-ipfw@freebsd.org Mon May 30 04:58:57 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D0CDB51CAD for ; Mon, 30 May 2016 04:58:57 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D6FAF1B0D; Mon, 30 May 2016 04:58:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-225-151.lns20.per1.internode.on.net [121.45.225.151]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u4U4wk1u027617 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 29 May 2016 21:58:51 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: [RFC] ipfw named states support To: Dmitry Selivanov , "Andrey V. Elsukov" , freebsd-ipfw References: <573C803E.5020600@FreeBSD.org> From: Julian Elischer Message-ID: Date: Mon, 30 May 2016 12:58:40 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 04:58:57 -0000 On 26/05/2016 6:11 PM, Dmitry Selivanov wrote: > 18.05.2016 17:46, Andrey V. Elsukov пишет: >> We have the patch that adds named states support to ipfw. >> The idea is that we add a symbolic name-label to each dynamic state in >> addition to IP addresses, protocol and ports. >> This introduces new syntax for check-state and keep-state rules: >> >> check-state { token | default | any } >> keep-state { token | default } > >> 1. Is this feature useful? > Yes. >> 2. How to commit it? Due to changed syntax it can break existing >> rulesets. Probably, we can add some mandatory prefix to state name, >> e.g. >> ':'. > Maybe create new opcode, e.g. "save-state", and deprecate > "keep-state" with "save-state default". > I'm sorry I didn't understand what Lev Serebryakov suggests, and I > could duplicate his suggestion. I have already hoped for a different version of keep-state, that saves the state without actually acting upon it. > > Maybe there is a sense to add "search-state" option and use it > instead of "check-state" action. E.g. "allow dst-port 80 > search-state NAME". > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > From owner-freebsd-ipfw@freebsd.org Mon May 30 14:33:54 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F7C1B5450B for ; Mon, 30 May 2016 14:33:54 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward3h.cmail.yandex.net (forward3h.cmail.yandex.net [IPv6:2a02:6b8:0:f35::13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B956A1FAE; Mon, 30 May 2016 14:33:53 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward3h.cmail.yandex.net (Yandex) with ESMTP id D817E20C1B; Mon, 30 May 2016 17:33:41 +0300 (MSK) Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 769D82C034A; Mon, 30 May 2016 17:33:41 +0300 (MSK) Received: by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id x7H9IgQDkb-Xe0ml5qw; Mon, 30 May 2016 17:33:40 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1464618820; bh=jiWTTPzp/Dgo6B7E61jWJr3k+0SPojkqm08/C6SxbnU=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; b=YcFOm1T5LsQbzpCz3WKTjqDARrUxQHB3UduFKtqlRQS3x0koZ7q5yVecsDuBAsf6z xMexTJgFHvIwIr/peZde2cl93+GoewjkGQgRPZxwM/opr/+giYmxLOZ965Q2wfFojR pzn5azTLeDlLNUCZRztRTgVUgl24I2j41l0dPZec= Authentication-Results: smtp4h.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0 Subject: Re: [RFC] ipfw named states support To: Julian Elischer , freebsd-ipfw@freebsd.org References: <573C803E.5020600@FreeBSD.org> <3c2d7675-926d-5987-fef7-6e6799a43834@freebsd.org> From: "Andrey V. Elsukov" Message-ID: <574C4F2D.6000304@yandex.ru> Date: Mon, 30 May 2016 17:33:17 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <3c2d7675-926d-5987-fef7-6e6799a43834@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q4UWhR3aTk4dowwLXe93fqihxqhdbNiOP" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 14:33:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q4UWhR3aTk4dowwLXe93fqihxqhdbNiOP Content-Type: multipart/mixed; boundary="6cv9NtNWchVRkXo2SpgHCeOVnPwFFgDw0" From: "Andrey V. Elsukov" To: Julian Elischer , freebsd-ipfw@freebsd.org Message-ID: <574C4F2D.6000304@yandex.ru> Subject: Re: [RFC] ipfw named states support References: <573C803E.5020600@FreeBSD.org> <3c2d7675-926d-5987-fef7-6e6799a43834@freebsd.org> In-Reply-To: <3c2d7675-926d-5987-fef7-6e6799a43834@freebsd.org> --6cv9NtNWchVRkXo2SpgHCeOVnPwFFgDw0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 30.05.16 07:56, Julian Elischer wrote: > On 18/05/2016 10:46 PM, Andrey V. Elsukov wrote: >> Hi All, >> >> We have the patch that adds named states support to ipfw. >=20 > like it and have wished for this for along time > this allows per-interface state. Can state name be set to a variable we= > can set or something? > then we could have subroutines that can be used for multiple interfaces= =2E > (I guess we need variables first) You are specifying the name when adding rule. E.g. # ipfw add allow tcp from me to any out igb1 keep-state igb1 # ipfw -d show 100 00100 317 36316 allow tcp from me to any out via igb1 keep-state igb1 ## Dynamic rules: 00100 5 317 (246s) STATE tcp A.B.C.144 21131 <-> C.D.E.93 22 igb1 00100 0 0 (1s) STATE tcp A.B.C.144 22 <-> F.G.35.120 30876 igb1 # ipfw -d show 200 300 00200 440 42779 allow ip from table(1) to me in keep-state SOME_NET 00300 119 17416 allow tcp from me to any out keep-state MY_OUTGOUING ## Dynamic rules (3 424): 00300 4 254 (286s) STATE tcp A.B.C.144 41280 <-> X.Y.178.135 22 MY_OUTGOUING 00300 3 244 (1s) STATE tcp A.B.C.144 22 <-> C.D.E.93 26951 MY_OUTGOUING 00200 343 33995 (286s) STATE tcp F.G.35.120 62486 <-> A.B.C.144 22 SOME_NET >> With named states we can create separate states for each interface and= >> they will not match when we don't want this. > what does the ipfw -d list output look like? The output is the same, just state name is added to the end of line. --=20 WBR, Andrey V. Elsukov --6cv9NtNWchVRkXo2SpgHCeOVnPwFFgDw0-- --q4UWhR3aTk4dowwLXe93fqihxqhdbNiOP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXTE8tAAoJEAHF6gQQyKF6khsH/2nKb0caQ6kkUiMDhCZDGMac 6cS7pBBEoErGq8LSgZqFFyNSLAveLkhDc51UxHEXYK1eEcw2bO8Mrc+3juQSAGAO KdDZyJpKrogWnN3Alq/VDspnR4TEerv5CSgdyCURxbgRiUp6upkPIaSm8WU/ScYL MVwlYLcSZVDCbxIG9TeFZGNOKVc+P5hltRRVHMYDePQXw2dW/YvaV763cfJ7znE2 3v5Qf+npWq88dYH8B9J+l9sWh75pizEUUARH9dZP1hl29TkK7+aauSkUuaOJVM5B ABs88iD4Dc/fXDVK3uwmvIwjUZ7lcGbHtxR7b5L3LP/mq81/JJXjKfx/vCsvLbU= =e4D3 -----END PGP SIGNATURE----- --q4UWhR3aTk4dowwLXe93fqihxqhdbNiOP-- From owner-freebsd-ipfw@freebsd.org Wed Jun 1 18:48:00 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDE0BB61514 for ; Wed, 1 Jun 2016 18:48:00 +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 mx1.freebsd.org (Postfix) with ESMTPS id CE46F1CFF for ; Wed, 1 Jun 2016 18:48:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u51Im0iB071810 for ; Wed, 1 Jun 2016 18:48:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 209680] ipfw: when enabled, net connections time out/ssh results in "broken pipe" Date: Wed, 01 Jun 2016 18:48:00 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: soeren84@fastmail.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: 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-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 18:48:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209680 soeren84@fastmail.net changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |soeren84@fastmail.net --- Comment #5 from soeren84@fastmail.net --- I believe that I'm seeing the same issue when doing backup transfers via a = SSH tunnel (Fssh_packet_write_wait: Connection to port 22: Broken pipe) However I'm using PF and not ipfw. This is happening using an up-to-date FreeBSD 10.3 (10.3-RELEASE-p4) with the default kernel. I can't say when the issue was introduced since it is a freshly installed machine, but I'm running the exact same SSH tunnel setup on a Linux machine without any issues. A workaround for me seems to be to limit the transfer speed to something way below the link speed. At least it's better than connections breaking. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Sat Jun 4 10:12:50 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF89DB6918B for ; Sat, 4 Jun 2016 10:12:50 +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 mx1.freebsd.org (Postfix) with ESMTPS id C004E16DB for ; Sat, 4 Jun 2016 10:12:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u54ACorU008290 for ; Sat, 4 Jun 2016 10:12:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 209680] ipfw: when enabled, net connections time out/ssh results in "broken pipe" Date: Sat, 04 Jun 2016 10:12:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ohartman@zedat.fu-berlin.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 10:12:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209680 --- Comment #6 from ohartman@zedat.fu-berlin.de --- Today, I made another observation in this matter. On a server that has in-kernel NAT and LIBALIAS and attached to the net via ADSL SoHo connection, serving as a server accessible from the outside world isn't possible anymor= e. It worked a couple of weeks ago with the ipfw-rules I use, inclusive the pr= oper forwarding rules, but since ~ two weeks, when these "broken pipe issues" started getting worse and worse, connecting to the provided www server or s= sh wasn't possible anymore. I started then checking for mistakes in the ipwf ruleset. Today, I had the chance to access the box from the outside world simultanously with access to the server and its IPFW itself and after a cle= an reboot of=20 FreeBSD 11.0-ALPHA2 #10 r301307: Sat Jun 4 11:03:17 CEST 2016 amd64 trying to connect to the server's Apache server or ssh failed. Then we restarted simply several times the local ipfw via "service ipfw restart" and voila - it worked! Sorry for the poor material I can provide at the moment, but time constrain= ts are tight and my abilities of debugging are limited and seting up alternati= ve serving systems circumventing the issue reporting here eat a lot of time. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Sat Jun 4 19:45:57 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6ED51B689DE for ; Sat, 4 Jun 2016 19:45:57 +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 mx1.freebsd.org (Postfix) with ESMTPS id 5F60016ED for ; Sat, 4 Jun 2016 19:45:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u54Jjvi7051445 for ; Sat, 4 Jun 2016 19:45:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 209680] ipfw: when enabled, net connections time out/ssh results in "broken pipe" Date: Sat, 04 Jun 2016 19:45:57 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ohartman@zedat.fu-berlin.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2016 19:45:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209680 --- Comment #7 from ohartman@zedat.fu-berlin.de --- Applying both patches seems to solve the problem of the "broken pipe" with = ssh. So far, connections from one system under load to another server also under heavy load is now with three ssh sessions still active after two hours. This wasn't the case before, the connections died even under relaxed conditions rather quickly. It does not solve the problem with NAT/port forwarding. --=20 You are receiving this mail because: You are the assignee for the bug.=