From owner-freebsd-ipfw@freebsd.org Tue May 2 04:40:47 2017 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 D36BED5A536 for ; Tue, 2 May 2017 04:40:47 +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 C2601C3D for ; Tue, 2 May 2017 04:40:47 +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 v424ekbs042765 for ; Tue, 2 May 2017 04:40:47 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 200169] ipfw table list uses IPv6 format for zero IPv4 addresses Date: Tue, 02 May 2017 04:40:46 +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: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc resolution bug_status 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.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 04:40:47 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200169 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org Resolution|--- |FIXED Status|New |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Tue May 2 05:02:48 2017 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 CD376D5AC92 for ; Tue, 2 May 2017 05:02:48 +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 BD253C43 for ; Tue, 2 May 2017 05:02:48 +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 v4252mrA014945 for ; Tue, 2 May 2017 05:02:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 212668] ipfw table all ignores set parameter Date: Tue, 02 May 2017 05:02:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org 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.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 05:02:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212668 --- Comment #1 from commit-hook@freebsd.org --- A commit references this bug: Author: ae Date: Tue May 2 05:02:12 UTC 2017 New revision: 317666 URL: https://svnweb.freebsd.org/changeset/base/317666 Log: Add sets support for ipfw table info/list/flush commands. PR: 212668 MFC after: 1 week Changes: head/sbin/ipfw/tables.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Tue May 2 17:16:53 2017 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 86D95D5A608 for ; Tue, 2 May 2017 17:16:53 +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 76C00DB4 for ; Tue, 2 May 2017 17:16:53 +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 v42HGrDZ021258 for ; Tue, 2 May 2017 17:16:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 212669] change ipfw to all table all destroy Date: Tue, 02 May 2017 17:16:53 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org 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.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:16:53 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212669 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: ae Date: Tue May 2 17:16:24 UTC 2017 New revision: 317682 URL: https://svnweb.freebsd.org/changeset/base/317682 Log: Add `ipfw table all destroy` support. PR: 212669 MFC after: 1 week Changes: head/sbin/ipfw/ipfw.8 head/sbin/ipfw/tables.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Tue May 2 17:28:56 2017 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 951DAD5A9F9 for ; Tue, 2 May 2017 17:28:56 +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 8493F697 for ; Tue, 2 May 2017 17:28:56 +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 v42HSsjQ046744 for ; Tue, 2 May 2017 17:28:56 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 215875] [ipfw] ipfw lookup tables do not support mbuf_tags(9) ipfw cookies lookups Date: Tue, 02 May 2017 17:28:55 +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-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ipfw@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? 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.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:28:56 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215875 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org --- Comment #1 from Andrey V. Elsukov --- Such opcode handling should be a bit complicated than other lookup keys, because a packet can have many tags and you need to make lookup in a table = for each tag in the loop. If you want to try, you can look at the O_IP_DST_LOOKUP opcode handling in ip_fw2.c and add new key support here. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Wed May 3 14:19:04 2017 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 22525D5CCE1 for ; Wed, 3 May 2017 14:19:04 +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 120201E0B for ; Wed, 3 May 2017 14:19:04 +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 v43EJ3nB037439 for ; Wed, 3 May 2017 14:19:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 218993] [patch] [ipfw] ipfw(8) may fail to remove rules Date: Wed, 03 May 2017 14:19:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org 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: assigned_to 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.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:19:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D218993 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-ipfw@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Thu May 4 16:29:24 2017 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 F3A42D5DC0D for ; Thu, 4 May 2017 16:29:24 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id AE8371774 for ; Thu, 4 May 2017 16:29:24 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.10.40] (Karl-Desktop.Denninger.net [192.168.10.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id ACD9A36A3F for ; Thu, 4 May 2017 11:22:21 -0500 (CDT) To: freebsd-ipfw@freebsd.org From: Karl Denninger Subject: Question that has dogged me for a while. Message-ID: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> Date: Thu, 4 May 2017 11:22:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050505020607010608050202" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 16:29:25 -0000 This is a cryptographically signed message in MIME format. --------------ms050505020607010608050202 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Consider the following network configuration. Internet ------- Gateway/Firewall ---------- Inside network (including a web host) 70.16.10.1/28 192.168.0.0/24 =20 The address of the outside is FICTIONAL, by the way. For policy reasons I do NOT want the gateway machine to actually have the host on it. There may be a number of things running on there but for the instant moment let's assume a standard pedestrian web host on port 80. I have DNS pointing at "webhost.domain" @ 70.16.10.1. I have NAT on the gateway (NAT internal to the kernel), and a "hole punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as pat of the nat configuration statement. This works fine for anyone on the outside. HOWEVER, anyone on the INTERNAL network cannot see the host. My NAT configuration looks like this: # # Now divert all inbound packets that should go through NAT. Since this is NAT # it can only match a packet that previously was NATted on the way out. # ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} # # Check stateful rules; we want to go there directly if there is a match # ${fwcmd} add 7000 check-state # # Now pick up all *outbound* packets that originated from an inside addre= ss # and put them through NAT. We then have # a packet with a local source address and we can allow it to be sent. # Therefore, if the packet is outbound let it pass and be done with it. # ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit ${o= if} >> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit ${oif} ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} Without the ">>" line I get nothing; the packets get to the gateway and disappear. With the ">>" line I DO get the packets re-emitted on the internal interface HOWEVER there is no translation to the internal interface IP on the gateway box. So what I see on the internal box is this: 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags [S], seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags [S.], seq 3088872007, ack 292171179, win 65535, options [mss 1460,nop,wscale 6,sackOK,eol], length 0 Which won't work because the internal box got and sent this: 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S], seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 >> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags [S], seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 >> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 But since the gateway emitted the packet back on the wire *without* remapping the source address (to itself) it doesn't match on the client box 'cause there's no way back for it. There has to be a solution to this somewhere and I'm obviously missing it..... :) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050505020607010608050202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MDQxNjIyMDlaME8GCSqGSIb3DQEJBDFCBEDu9r4j m25U+1fOeziaNsGRD6XSosPEQAnCLGUvzWVI7Z1RP594aA+T0DbJrHkmPy+dY10LI2mn+nwD UrL9fmBBMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAp3KYphTYle5+ 80+qyM4ke0EKifRkgR53KZPCJNmEHT6+21rENxtt3CXKhtUHs3cIZDVkDoj8IEfOvKEJTjZ3 NXwXKqtl4QVBvLjUTiiemhp8TG6xwkBdq7rm0zwGDMlHRqk0W9nQDNgnhlLvBav9h4f9YvHr GCarKVsUWPGVTCbvbikm9LVejDPQxddNt5oNAysiB0IYauIUICbtm92SGDWWauS7mDS/TwZ0 pjwr+qaBYexbsmkpJSQOSpaq8xWo4c3FcEP4wM1PN4vDyYUNBefwz+Zhar+LL8xivfg+/NAS IN5HPjqqzwaJke91dsd/BFfm3KvzKV5k3uLsYJgk6wqcg+HopRnLzCfJBbwBJwIt/bxTVkvF 0d3GYpv3ARqlZ1z8jHmm+xEcuLIr3VxyCCzsdoEbJJPJoOnrGgOljuPV/alSwRGpdpsRGACg z98mAmuZxBZR3gVsDynE/KxQq5hyf+IQjRTS5FGTgd/7a3pHnkuajmoqgPYpMJYT/RTwBz1O LldMX9YjniFrffIINc9OoF8BSPuNJbMRYwaaqf44h0dPfQzbYzv6OqqSq/QBsne2eMyt3/0E aHrLNHY0pZNf6mLwKc5we5RG5XS1Kl1jNcTHpuYaQI0P0JTHyStrqgboG9TOdUrcd4tZF4mY wdc+cvZmOcNt3+Wr03eqROwAAAAAAAA= --------------ms050505020607010608050202-- From owner-freebsd-ipfw@freebsd.org Thu May 4 16:51:29 2017 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 5800FD5E3AA for ; Thu, 4 May 2017 16:51:29 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AA6DA06 for ; Thu, 4 May 2017 16:51:28 +0000 (UTC) (envelope-from leeb@ratnaling.org) Received: by mail-vk0-x22a.google.com with SMTP id x71so11515285vkd.0 for ; Thu, 04 May 2017 09:51:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ratnaling-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SCpjp5M0/vHopvdOmmItML52C5AXihiRNM0dzIsJgho=; b=lA3GNuQDPg8RZl3ZX2pfxnNScMtjDwvP+p9osKwXeB3Ky+59FjardCIjDaH7bVjLi6 WZfMPz0t4KH71w6vfaOAAX9pirXTPCk23T1cd5GFuuoRxGVI+8sLFk7TsqVU338VzWzC uMjHTof31yqo19MEEFR3mL6yKuExrOlSQtrAVSpl4m7W+JksHjYX5OAl97sFJfWW24q6 xP/vbsJGKMuv6YnqvEgKMdulMsOXipASKOtNSzg3u135baWfunX20dr00hzYAgehipLx mh/SuNMsCbvl1zA/lq0OTZ2rkCeywukHc8eNje3+nNekaXaTMH4m2dEREy5KO9jhS2P1 PCuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SCpjp5M0/vHopvdOmmItML52C5AXihiRNM0dzIsJgho=; b=KtmbH/gaJZHFtjg55nifbIyFQFtAI1HRLziaIXnjYoKD8dgsIIissZ0B1W68y0DSi0 UTKNKffU6CmIu94P5FmE8JmT1cmBG6nPXPMIarFgDsLyIXyPWMEcVCTj+2z2uIWvZ2k/ gxdiGXP5szOp+iW5MSMVk4A7APxfTDzBBzlm10aKLTP6nzTRH2hXMa1eaT9mcAAsVcCh aBHumm51yUrEDyoNvTon+PmE11gvJAiioydUXm68Og+TUxNsk1RWxviGQskp3wSasiRq S8+dWpjZroeFWsIgI1FFFPHvloPyzP50T5RP8r9e+rBxdPLPfsEYfu7qodFKWWRgOg/s eP+g== X-Gm-Message-State: AN3rC/5uNgM3ljxRTjNCZBm3lVJJy1/WtuXSrMiRTL0675Zv2yGktj4V sTnrNlDe2gZBPZUkIZNhwXjHRXKQMg== X-Received: by 10.31.200.65 with SMTP id y62mr20646312vkf.142.1493916687787; Thu, 04 May 2017 09:51:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.92.133 with HTTP; Thu, 4 May 2017 09:51:27 -0700 (PDT) In-Reply-To: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> From: Lee Brown Date: Thu, 4 May 2017 09:51:27 -0700 Message-ID: Subject: Re: Question that has dogged me for a while. To: Karl Denninger Cc: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 16:51:29 -0000 On Thu, May 4, 2017 at 9:22 AM, Karl Denninger wrote: > Consider the following network configuration. > > > Internet ------- Gateway/Firewall ---------- Inside network (including a > web host) > 70.16.10.1/28 192.168.0.0/24 > > The address of the outside is FICTIONAL, by the way. > > For policy reasons I do NOT want the gateway machine to actually have > the host on it. There may be a number of things running on there but > for the instant moment let's assume a standard pedestrian web host on > port 80. > > I have DNS pointing at "webhost.domain" @ 70.16.10.1. > > I have NAT on the gateway (NAT internal to the kernel), and a "hole > punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as > pat of the nat configuration statement. > > This works fine for anyone on the outside. HOWEVER, anyone on the > INTERNAL network cannot see the host. > > My NAT configuration looks like this: > > # > # Now divert all inbound packets that should go through NAT. Since this > is NAT > # it can only match a packet that previously was NATted on the way out. > # > ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} > # > # Check stateful rules; we want to go there directly if there is a match > # > ${fwcmd} add 7000 check-state > # > # Now pick up all *outbound* packets that originated from an inside address > # and put them through NAT. We then have > # a packet with a local source address and we can allow it to be sent. > # Therefore, if the packet is outbound let it pass and be done with it. > # > ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit > ${oif} > >> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} > ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit > ${oif} > ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} > > Without the ">>" line I get nothing; the packets get to the gateway and > disappear. > > With the ">>" line I DO get the packets re-emitted on the internal > interface HOWEVER there is no translation to the internal interface IP > on the gateway box. So what I see on the internal box is this: > > 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags > [S], seq 292171178, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags > [S.], seq 3088872007, ack 292171179, win 65535, options [mss > 1460,nop,wscale 6,sackOK,eol], length 0 > > Which won't work because the internal box got and sent this: > > 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S], > seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], > length 0 > 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S], > seq 2666765817, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > >> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags > [S], seq 292171178, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > >> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags > [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > > But since the gateway emitted the packet back on the wire *without* > remapping the source address (to itself) it doesn't match on the client > box 'cause there's no way back for it. > > There has to be a solution to this somewhere and I'm obviously missing > it..... :) > > Setup DNS to return the internal address when a query is made from an internal client. I've never been able to do what you are trying, on a few different platforms, I forget the reasons now. From owner-freebsd-ipfw@freebsd.org Thu May 4 16:58:56 2017 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 072B3D5E461 for ; Thu, 4 May 2017 16:58:56 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0949C85 for ; Thu, 4 May 2017 16:58:55 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by mail-qt0-x22f.google.com with SMTP id m91so15189617qte.3 for ; Thu, 04 May 2017 09:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dizhYutbaaEHbEkWDrtMfW1eS/KI/umN/zmrYZsGS2w=; b=ENdO8RCmVMWJWDRvcNdoRLgOpX7sckvDCsG57QSOdEaAnO2Pmdzug7F6vWlDGmLf4Q imhaqP22Mg4Z3S0gk3bWT9x4LeOiEgTOu+PS/A7L+cm30wgdPY15cXG0EQU0NcFoKD1h r5Kv+Ms56GYiiTrur2cWBXQbZ1ByiSxa8tldwbRj0gGDb9wz2LJAM6LpSKWCj0UAdKII 6+SbArbBzCqtpE7U+rQskd0vvojBXUsQBl+c0AbaOszpEIEj9FR9Jp/U4M1udXlom6Qt RqS7n4IAo0CjHr3bVRBIm1zYQq0kcoa+fEMz/XoUQ6BvpHvCq3gaCM9pwmtJu8yzr6gs F0ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dizhYutbaaEHbEkWDrtMfW1eS/KI/umN/zmrYZsGS2w=; b=cqqmqGTLo/OMGZlrB0ABu20uY63sBL0yzQ7U4nTQKN6BBFTTSw43VTVacbV+0yaOOk eBcX/z6x2sMLKZom5ynRrJ991Nn0z9q2mLpW+Qk2Rf1CaaSh3RUXIdrzuQy2SViC+PXG 3btg7AsfnDwI/etJc3HcmvpJfRjwdNumzWQCRYzR+M31Ehl1PPCdJBDeGLCL/rGAtWQ2 vWCxGQoPOUdRxhGHp5CSZNurS3KQYgE1TLyMY/iY6YEM0kC33WlWCxw3YtGoYJDSzUMJ bjrEP7OrfB/mQEgQlRL/lYg+S07j7GJpiVhnYrNuoFgJL/lfcJJ9W+MxO+etO6+dAXve B20A== X-Gm-Message-State: AN3rC/6dQHqOsltk8JbKBYVcC6RyFeGKg8RldlZBlJ2z6oYm4/yQIfxF bKjEmyV6jtnXAJJ2LXlNRAjITPAPqA== X-Received: by 10.200.52.165 with SMTP id w34mr13721810qtb.77.1493917134807; Thu, 04 May 2017 09:58:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.16.199 with HTTP; Thu, 4 May 2017 09:58:37 -0700 (PDT) In-Reply-To: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> From: Freddie Cash Date: Thu, 4 May 2017 09:58:37 -0700 Message-ID: Subject: Re: Question that has dogged me for a while. To: Karl Denninger Cc: "freebsd-ipfw@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 16:58:56 -0000 On Thu, May 4, 2017 at 9:22 AM, Karl Denninger wrote: > Consider the following network configuration. > > > Internet ------- Gateway/Firewall ---------- Inside network (including a > web host) > 70.16.10.1/28 192.168.0.0/24 > > The address of the outside is FICTIONAL, by the way. > > For policy reasons I do NOT want the gateway machine to actually have > the host on it. There may be a number of things running on there but > for the instant moment let's assume a standard pedestrian web host on > port 80. > > I have DNS pointing at "webhost.domain" @ 70.16.10.1. > > I have NAT on the gateway (NAT internal to the kernel), and a "hole > punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as > pat of the nat configuration statement. > > This works fine for anyone on the outside. HOWEVER, anyone on the > INTERNAL network cannot see the host. > > My NAT configuration looks like this: > > # > # Now divert all inbound packets that should go through NAT. Since this > is NAT > # it can only match a packet that previously was NATted on the way out. > # > ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} > # > # Check stateful rules; we want to go there directly if there is a match > # > ${fwcmd} add 7000 check-state > # > # Now pick up all *outbound* packets that originated from an inside addre= ss > # and put them through NAT. We then have > # a packet with a local source address and we can allow it to be sent. > # Therefore, if the packet is outbound let it pass and be done with it. > # > ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit > ${oif} > >> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} > ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit > ${oif} > ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} > > Without the ">>" line I get nothing; the packets get to the gateway and > disappear. > > With the ">>" line I DO get the packets re-emitted on the internal > interface HOWEVER there is no translation to the internal interface IP > on the gateway box. So what I see on the internal box is this: > > 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags > [S], seq 292171178, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags > [S.], seq 3088872007, ack 292171179, win 65535, options [mss > 1460,nop,wscale 6,sackOK,eol], length 0 > > Which won't work because the internal box got and sent this: > > 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S], > seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], > length 0 > 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S], > seq 2666765817, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > >> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags > [S], seq 292171178, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > >> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags > [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > > But since the gateway emitted the packet back on the wire *without* > remapping the source address (to itself) it doesn't match on the client > box 'cause there's no way back for it. > > There has to be a solution to this somewhere and I'm obviously missing > it..... :) =E2=80=8BYou need to do a double-NAT (or hairpin-NAT or whatever you want t= o call it), where you first NAT the destination address on the incoming interface which will initiate the routing decision for where to send the packet next, then NAT the source address on the outgoing interface (which can be the same interface) in order to get the return packets sent back to the correct gateway. Something along the lines of: ipfw nat 100 blah blah blah ipfw nat 200 blah blah blah ipfw add nat 200 tcp from 192.168.0.0/16 to 70.16.10.1 80 in recv ipfw add nat 100 tcp from 192.168.0.0/16 to 192.168.1.1 80 out xmit ipfw add nat 100 tcp from 192.168.1.1 80 to 70.16.10.x in recv ipfw add nat 200 tcp from 70.16.10.1 80 to 192.168.0.0/16 out xmit 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 349D8D5E7EE for ; Thu, 4 May 2017 17:12:22 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1C09514C1 for ; Thu, 4 May 2017 17:12:21 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v44HCFSH005272; Thu, 4 May 2017 10:12:15 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v44HCF3s005271; Thu, 4 May 2017 10:12:15 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201705041712.v44HCF3s005271@pdx.rh.CN85.dnsmgr.net> Subject: Re: Question that has dogged me for a while. In-Reply-To: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> To: Karl Denninger Date: Thu, 4 May 2017 10:12:15 -0700 (PDT) CC: freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 17:12:22 -0000 > Consider the following network configuration. > > > Internet ------- Gateway/Firewall ---------- Inside network (including a > web host) > 70.16.10.1/28 192.168.0.0/24 > > The address of the outside is FICTIONAL, by the way. > > For policy reasons I do NOT want the gateway machine to actually have > the host on it. There may be a number of things running on there but > for the instant moment let's assume a standard pedestrian web host on > port 80. > > I have DNS pointing at "webhost.domain" @ 70.16.10.1. > > I have NAT on the gateway (NAT internal to the kernel), and a "hole > punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as > pat of the nat configuration statement. > > This works fine for anyone on the outside. HOWEVER, anyone on the > INTERNAL network cannot see the host. > > My NAT configuration looks like this: > > # > # Now divert all inbound packets that should go through NAT. Since this > is NAT > # it can only match a packet that previously was NATted on the way out. > # > ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} > # > # Check stateful rules; we want to go there directly if there is a match > # > ${fwcmd} add 7000 check-state > # > # Now pick up all *outbound* packets that originated from an inside address > # and put them through NAT. We then have > # a packet with a local source address and we can allow it to be sent. > # Therefore, if the packet is outbound let it pass and be done with it. > # > ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif} > >> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} > ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit > ${oif} > ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} > > Without the ">>" line I get nothing; the packets get to the gateway and > disappear. > > With the ">>" line I DO get the packets re-emitted on the internal > interface HOWEVER there is no translation to the internal interface IP > on the gateway box. So what I see on the internal box is this: > > 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags > [S], seq 292171178, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags > [S.], seq 3088872007, ack 292171179, win 65535, options [mss > 1460,nop,wscale 6,sackOK,eol], length 0 > > Which won't work because the internal box got and sent this: What is the NAT command running at instance 100? Does it have an -alias_address of inside IP of router? Are you tryint to use the same Nat instance to do both the global internet acess translation and this special inside loop back translation? If so that usually can not be made to work. > 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S], > seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], > length 0 > 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S], > seq 2666765817, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > >> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags > [S], seq 292171178, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > >> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags > [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > > But since the gateway emitted the packet back on the wire *without* > remapping the source address (to itself) it doesn't match on the client > box 'cause there's no way back for it. Yep. > > There has to be a solution to this somewhere and I'm obviously missing > it..... :) > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ This is the classical "Loopback Nat Problem" of accessing machines behind a NAT device that does not do the proper NATTing and routing of these packets. Many small consumer routers got this wrong for years, just like most ipfw code I have seen. Most of the consumber devices have been fixed. The trickery is you need to NAT packets coming from the inside destined for the outside IP into the internal IP. That internal box MUST route back via the NAT device, so the NATTED addresses for these packets must be the inside IP of the router. Your code looks to get this mostly right, but I think you have missed something someplace. I dont use kernel nat, and it looks like you do so you well have to adjust these a little. inside_ip_router="192.168.10.40" outside_ip_router="70.16.10.1" inside_ip_webserver="192.168.10.100" #natd-vmxZ.conf should just be an empty file for this type of nat /sbin/natd -f /etc/firewall/natd-vmxZ.conf -port 8888 -alias_address ${192.168.10.40} Something like # This takes inside traffic to outside port 80 address and # remaps it to inside IP of router to send to web server ${fwcmd} add X divert 8888 tcp from 192.168.0.0/24 to ${outside_ip_router} port 80 # This translates the returning packets ${fwcmd} add X divert 8888 tcp from 192.168.0.0/24 port 80 to ${inside_ip_router} -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-ipfw@freebsd.org Thu May 4 17:19:14 2017 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 E02A2D5E8C8 for ; Thu, 4 May 2017 17:19:14 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9CA6165D for ; Thu, 4 May 2017 17:19:14 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v44HJBCZ005293; Thu, 4 May 2017 10:19:11 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v44HJBgF005292; Thu, 4 May 2017 10:19:11 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201705041719.v44HJBgF005292@pdx.rh.CN85.dnsmgr.net> Subject: Re: Question that has dogged me for a while. In-Reply-To: To: Freddie Cash Date: Thu, 4 May 2017 10:19:11 -0700 (PDT) CC: Karl Denninger , "freebsd-ipfw@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 17:19:15 -0000 [ Charset UTF-8 unsupported, converting... ] > On Thu, May 4, 2017 at 9:22 AM, Karl Denninger wrote: > > > Consider the following network configuration. > > > > > > Internet ------- Gateway/Firewall ---------- Inside network (including a > > web host) > > 70.16.10.1/28 192.168.0.0/24 > > > > The address of the outside is FICTIONAL, by the way. > > > > For policy reasons I do NOT want the gateway machine to actually have > > the host on it. There may be a number of things running on there but > > for the instant moment let's assume a standard pedestrian web host on > > port 80. > > > > I have DNS pointing at "webhost.domain" @ 70.16.10.1. > > > > I have NAT on the gateway (NAT internal to the kernel), and a "hole > > punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as > > pat of the nat configuration statement. > > > > This works fine for anyone on the outside. HOWEVER, anyone on the > > INTERNAL network cannot see the host. > > > > My NAT configuration looks like this: > > > > # > > # Now divert all inbound packets that should go through NAT. Since this > > is NAT > > # it can only match a packet that previously was NATted on the way out. > > # > > ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} > > # > > # Check stateful rules; we want to go there directly if there is a match > > # > > ${fwcmd} add 7000 check-state > > # > > # Now pick up all *outbound* packets that originated from an inside address > > # and put them through NAT. We then have > > # a packet with a local source address and we can allow it to be sent. > > # Therefore, if the packet is outbound let it pass and be done with it. > > # > > ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit > > ${oif} > > >> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} > > ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit > > ${oif} > > ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} > > > > Without the ">>" line I get nothing; the packets get to the gateway and > > disappear. > > > > With the ">>" line I DO get the packets re-emitted on the internal > > interface HOWEVER there is no translation to the internal interface IP > > on the gateway box. So what I see on the internal box is this: > > > > 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags > > [S], seq 292171178, win 8192, options [mss 1460,nop,wscale > > 8,nop,nop,sackOK], length 0 > > 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags > > [S.], seq 3088872007, ack 292171179, win 65535, options [mss > > 1460,nop,wscale 6,sackOK,eol], length 0 > > > > Which won't work because the internal box got and sent this: > > > > 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S], > > seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], > > length 0 > > 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S], > > seq 2666765817, win 8192, options [mss 1460,nop,wscale > > 8,nop,nop,sackOK], length 0 > > >> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags > > [S], seq 292171178, win 8192, options [mss 1460,nop,wscale > > 8,nop,nop,sackOK], length 0 > > >> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags > > [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale > > 8,nop,nop,sackOK], length 0 > > > > But since the gateway emitted the packet back on the wire *without* > > remapping the source address (to itself) it doesn't match on the client > > box 'cause there's no way back for it. > > > > There has to be a solution to this somewhere and I'm obviously missing > > it..... :) > > > ?You need to do a double-NAT (or hairpin-NAT or whatever you want to call > it), where you first NAT the destination address on the incoming interface > which will initiate the routing decision for where to send the packet next, > then NAT the source address on the outgoing interface (which can be the > same interface) in order to get the return packets sent back to the correct > gateway. > > Something along the lines of: > > ipfw nat 100 blah blah blah > ipfw nat 200 blah blah blah > > ipfw add nat 200 tcp from 192.168.0.0/16 to 70.16.10.1 80 in recv > ipfw add nat 100 tcp from 192.168.0.0/16 to 192.168.1.1 80 out xmit > > ipfw add nat 100 tcp from 192.168.1.1 80 to 70.16.10.x in recv > ipfw add nat 200 tcp from 70.16.10.1 80 to 192.168.0.0/16 out xmit > ?Note: I've only ever done this with non-stateful rulesets. Once you add > state keeping, NAT configuration becomes horribly, horribly complex with > IPFW. Stateless rules are super easy, though. :) > ? This looks good too. Note that you can do this inside loop back NAT in a stateless manner, your only doing this to make it work, your not trying to do any keep state type protection. Then leave the NAT that is going out to the world as a keep state type NAT. I am a strong advocate of stateless firewalls, but they have security concerns that can often be addressed by use of keep state. No one says you can not make firewalls that mixes the technologies :-) For critical and often abused TCP ports that I need to allow some traffic to I often shovel those off to a keep state, for other less dangerious, and especially high volume traffic I send that to a stateless filter. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-ipfw@freebsd.org Thu May 4 17:48:15 2017 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 08942D5E10B for ; Thu, 4 May 2017 17:48:15 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EE33937 for ; Thu, 4 May 2017 17:48:14 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1493920090; l=5256; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=3WBOKFIVQgRJoOCajnkUDTXb0ub1tlnQriZe8WwiT9A=; b=iAAxMvD79H37eN4NglfhpgBhCSTcegvZ3dI7bD8cSODIwKDSn9Ai95IxoxswuS2l6U XqRyeIIvDUhcXNJdDE8JmLTLlNS2cTw4XYljnLgTRMmIiidRBhfnW37/hz6WHoeyQtts UwiVqCUlZdzYDcjlwPMDniu6pFiC7CqiQ9H60= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGhIn99HqS2s= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02aec2.virtua.com.br [187.2.174.194]) by smtp.strato.de (RZmta 40.6 DYNA|AUTH) with ESMTPSA id a04df1t44Hm8UJx (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Thu, 4 May 2017 19:48:08 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 19E817506DB2; Thu, 4 May 2017 14:48:05 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Question that has dogged me for a while. From: "Dr. Rolf Jansen" In-Reply-To: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> Date: Thu, 4 May 2017 14:48:03 -0300 Cc: freebsd-ipfw@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 17:48:15 -0000 Resolving this with ipfw/NAT may easily become quite complicated, if not = impossible if you want to run a stateful nat'ting firewall, which is = usually the better choice. IMHO a DNS based solution is much more effective. On my gateway I have running the caching DNS resolver Unbound. Now let's = assume, the second level domain name in question is example.com, and = your web server would be accessed by www.example.com, while other = services, e.g. mail are served from other sites on the internet. In unbound.conf you would place two additional lines before any = forwarding directive: local-zone: "example.com" transparent local-data: "www.example.com" A 192.168.1.1 All the clients on the LAN should use the DNS service on the gateway. In = the first place Unbound does higher level DNS lookups locally, however, = the transparent attribute lets it fall through to its normal recursive = or forwarding behaviour in case a given domain could not be resolved = locally. For example, the query of www.example.com would return = 192.168.1.1 and the query for mail.example.com would be passed either to = the forwarder or resolved recursively from the internet. By this way, local clients would directly access your web server from = the inside, no NAT is needed. IMHO, a DNS server on the gateway got more advantages. It can be used to = block access to fraudulent or otherwise useless services on the internet = for the whole LAN. Best regards Rolf Am 04.05.2017 um 13:22 schrieb Karl Denninger : > Consider the following network configuration. >=20 >=20 > Internet ------- Gateway/Firewall ---------- Inside network (including = a > web host) > 70.16.10.1/28 192.168.0.0/24 =20 >=20 > The address of the outside is FICTIONAL, by the way. >=20 > For policy reasons I do NOT want the gateway machine to actually have > the host on it. There may be a number of things running on there but > for the instant moment let's assume a standard pedestrian web host on > port 80. >=20 > I have DNS pointing at "webhost.domain" @ 70.16.10.1. >=20 > I have NAT on the gateway (NAT internal to the kernel), and a "hole > punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as > pat of the nat configuration statement. >=20 > This works fine for anyone on the outside. HOWEVER, anyone on the > INTERNAL network cannot see the host. >=20 > My NAT configuration looks like this: >=20 > # > # Now divert all inbound packets that should go through NAT. Since = this > is NAT > # it can only match a packet that previously was NATted on the way = out. > # > ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} > # > # Check stateful rules; we want to go there directly if there is a = match > # > ${fwcmd} add 7000 check-state > # > # Now pick up all *outbound* packets that originated from an inside = address > # and put them through NAT. We then have > # a packet with a local source address and we can allow it to be sent. > # Therefore, if the packet is outbound let it pass and be done with = it. > # > ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit = ${oif} >>> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} > ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit > ${oif} > ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} >=20 > Without the ">>" line I get nothing; the packets get to the gateway = and > disappear. >=20 > With the ">>" line I DO get the packets re-emitted on the internal > interface HOWEVER there is no translation to the internal interface IP > on the gateway box. So what I see on the internal box is this: >=20 > 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags > [S], seq 292171178, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 > 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags > [S.], seq 3088872007, ack 292171179, win 65535, options [mss > 1460,nop,wscale 6,sackOK,eol], length 0 >=20 > Which won't work because the internal box got and sent this: >=20 > 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags = [S], > seq 292171178, win 8192, options [mss 1460,nop,wscale = 8,nop,nop,sackOK], > length 0 > 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags = [S], > seq 2666765817, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 >>> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags > [S], seq 292171178, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 >>> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags > [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale > 8,nop,nop,sackOK], length 0 >=20 > But since the gateway emitted the packet back on the wire *without* > remapping the source address (to itself) it doesn't match on the = client > box 'cause there's no way back for it. >=20 > There has to be a solution to this somewhere and I'm obviously missing > it..... :) >=20 > --=20 > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ From owner-freebsd-ipfw@freebsd.org Thu May 4 18:06:22 2017 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 C4555D5E5B1 for ; Thu, 4 May 2017 18:06:22 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 666F02DE for ; Thu, 4 May 2017 18:06:22 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.10.40] (Karl-Desktop.Denninger.net [192.168.10.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id B269536B92 for ; Thu, 4 May 2017 13:06:20 -0500 (CDT) Subject: Re: Question that has dogged me for a while. To: freebsd-ipfw@freebsd.org References: <201705041719.v44HJBgF005292@pdx.rh.CN85.dnsmgr.net> From: Karl Denninger Message-ID: Date: Thu, 4 May 2017 13:06:16 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <201705041719.v44HJBgF005292@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080709020609080503070301" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 18:06:22 -0000 This is a cryptographically signed message in MIME format. --------------ms080709020609080503070301 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/4/2017 12:12, Rodney W. Grimes wrote: >> Consider the following network configuration. >> >> >> Internet ------- Gateway/Firewall ---------- Inside network (including= a >> web host) >> 70.16.10.1/28 192.168.0.0/24 =20 >> >> The address of the outside is FICTIONAL, by the way. >> >> For policy reasons I do NOT want the gateway machine to actually have >> the host on it. There may be a number of things running on there but >> for the instant moment let's assume a standard pedestrian web host on >> port 80. >> >> I have DNS pointing at "webhost.domain" @ 70.16.10.1. >> >> I have NAT on the gateway (NAT internal to the kernel), and a "hole >> punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as= >> pat of the nat configuration statement. >> >> This works fine for anyone on the outside. HOWEVER, anyone on the >> INTERNAL network cannot see the host. >> >> My NAT configuration looks like this: >> >> # >> # Now divert all inbound packets that should go through NAT. Since thi= s >> is NAT >> # it can only match a packet that previously was NATted on the way out= =2E >> # >> ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} >> # >> # Check stateful rules; we want to go there directly if there is a mat= ch >> # >> ${fwcmd} add 7000 check-state >> # >> # Now pick up all *outbound* packets that originated from an inside ad= dress >> # and put them through NAT. We then have >> # a packet with a local source address and we can allow it to be sent.= >> # Therefore, if the packet is outbound let it pass and be done with it= =2E >> # >> ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit = ${oif} >>>> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} >> ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit= >> ${oif} >> ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} >> >> Without the ">>" line I get nothing; the packets get to the gateway an= d >> disappear. >> >> With the ">>" line I DO get the packets re-emitted on the internal >> interface HOWEVER there is no translation to the internal interface IP= >> on the gateway box. So what I see on the internal box is this: >> >> 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags >> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale >> 8,nop,nop,sackOK], length 0 >> 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags >> [S.], seq 3088872007, ack 292171179, win 65535, options [mss >> 1460,nop,wscale 6,sackOK,eol], length 0 >> >> Which won't work because the internal box got and sent this: > What is the NAT command running at instance 100? > Does it have an -alias_address of inside IP of router? > Are you tryint to use the same Nat instance to do both > the global internet acess translation and this special > inside loop back translation? If so that usually can > not be made to work. Aha. That's probably the problem -- I need a second instance. Here's the entire salient section: # Set up the NAT configuration; there are multiple entries that have to be here # because we redirect a bunch of ports around so we can see things from t= he # outside -- specifically, webcams and the HomeDaemon server. # ${fwcmd} nat 100 config ip ${oip} log same_ports reset redirect_port tcp.... (whole bunch of stuff) # # Stop spoofing # ${fwcmd} add 2010 deny log all from ${inet} to any not ipsec in via ${oif} ${fwcmd} add 2020 deny log all from ${onet} to any in via ${iif} if [ -n "$inet6" ]; then ${fwcmd} add 2040 deny all from ${inet6} to any in via ${oif6} if [ -n "$onet6" ]; then ${fwcmd} add 2050 deny log all from ${onet6} to any in \ via ${iif6} fi fi ${fwcmd} add 3000 deny log all from ${onet} to any recv ${iif} # # This table is a list of denied addresses that tried to attack us. Upda= ted # by sshguard. Anything coming inbound from the outside is blocked. We also # block anything on the "screw you" lists (two) # ${fwcmd} add 4000 deny log all from table\(22\) to any recv ${oif= } ${fwcmd} add 4010 deny all from any to ${foscam} ${fwcmd} add 4020 deny log all from ${china} to any via ${oif} # # Anything related to RFC1918 or the Manning range that comes in on # the external interface (shouldn't happen) gets tossed immediately, EXCE= PT # for RFC1918 stuff coming in via IPSEC. That we must pass or our IPSEC # gateway will not work. # ${fwcmd} add 5000 deny log all from ${rfc1918} to any not ipsec recv ${oif} ${fwcmd} add 5010 deny log all from ${manning} to any recv ${oif}= # # Now divert all inbound packets that should go through NAT. Since this is NAT # it can only match a packet that previously was NATted on the way out. # ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} # # Check stateful rules; we want to go there directly if there is a match # ${fwcmd} add 7000 check-state # # Now pick up all *outbound* packets that originated from an inside addre= ss # (including IPSEC tunneled stuff) and put them through NAT. We $then ha= ve # a packet with a local source address and we can allow it to be sent. # Therefore, if the packet is outbound let it pass and be done with it. # ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit ${o= if} ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit ${oif} ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} =46rom the above I assume I need to direct 8001 through a nat 200, and define that as "twist anything that comes through there to be aliased from the INTERNAL IP address", yes? So I changed the above to be this: =20 ${fwcmd} add 8000 nat 200 ip4 from 192.168.0.0/16 to ${oip} ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oi= f} So the first one would catch any inside packet that was headed to the outside IP before the other gets ahold of it. And added: ipfw nat 200 config ip ${iip} same_ports reset Up above for the second NAT channel; "iip" is the gateway's internal IP address. But that winds up doing nothing; I get no packets back out on the inside interface at all (just as if the "200" nat stuff was not there at all) >> 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S]= , >> seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK= ], >> length 0 >> 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S]= , >> seq 2666765817, win 8192, options [mss 1460,nop,wscale >> 8,nop,nop,sackOK], length 0 >>>> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags= >> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale >> 8,nop,nop,sackOK], length 0 >>>> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags= >> [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale >> 8,nop,nop,sackOK], length 0 >> >> But since the gateway emitted the packet back on the wire *without* >> remapping the source address (to itself) it doesn't match on the clien= t >> box 'cause there's no way back for it. > Yep. > >> There has to be a solution to this somewhere and I'm obviously missing= >> it..... :) >> >> --=20 >> Karl Denninger >> karl@denninger.net >> /The Market Ticker/ >> /[S/MIME encrypted email preferred]/ > This is the classical "Loopback Nat Problem" of accessing machines > behind a NAT device that does not do the proper NATTing and=20 > routing of these packets. Many small consumer routers got this > wrong for years, just like most ipfw code I have seen. > > Most of the consumber devices have been fixed. The trickery is > you need to NAT packets coming from the inside destined for the > outside IP into the internal IP. That internal box MUST route > back via the NAT device, so the NATTED addresses for these > packets must be the inside IP of the router. > > Your code looks to get this mostly right, but I think you have > missed something someplace. I dont use kernel nat, and it looks > like you do so you well have to adjust these a little. > > inside_ip_router=3D"192.168.10.40" > outside_ip_router=3D"70.16.10.1" > inside_ip_webserver=3D"192.168.10.100" > > #natd-vmxZ.conf should just be an empty file for this type of nat > /sbin/natd -f /etc/firewall/natd-vmxZ.conf -port 8888 -alias_address $= {192.168.10.40}=20 > > Something like > # This takes inside traffic to outside port 80 address and > # remaps it to inside IP of router to send to web server > ${fwcmd} add X divert 8888 tcp from 192.168.0.0/24 to ${outside_ip_rout= er} port 80 > # This translates the returning packets > ${fwcmd} add X divert 8888 tcp from 192.168.0.0/24 port 80 to ${inside_= ip_router} > --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080709020609080503070301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MDQxODA2MTZaME8GCSqGSIb3DQEJBDFCBEA7hTMU QLlqUa1YEB+XjxdRTU2Hc3QzsQkJrI7EJEka05CT9K7cR+EjqgBrhDKMWtLiMpQOgDZZxU9J AZkufGYzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAPrh4JekNdB81 XnMuY96cRCPrq4YQfvv3g+8kt9MNjGkL4b5m0IIdNY5JKPu8H76wgFFVJep86B6DCXdrEZUe +y4Vmv7VLU0CFT0cx+eO7qaxkuntFWx5ymxTi3Jf4Eo7ZPMmmg9NYPRXjjo3af/lXyeLZ7cj Ogu6KOgWPeQ+sOn6Gj9osyY0JlyWr0KMXvlglIKbYI50k0IwONbsYonGk532Ub+im6TNudgf oxhUGnXvKYrEb4jOqQ4nQxrRJlqkJYgpVtOwP0lrp7p2gmpOwMZZxp6M3BGzIP2RA/lDQ9+b VP1w+j8FwmcK9tuIIXWfGxxjJ4Cg6FYkalhzBUnMPXFPBMNWfTP+Bjyt1QrFfw8nDtAngEXy NNcZWl3MS9B2FnwCN+i0XfjuMprtZqX05MsHOwUwsV517cVWOyFXMSuPoLwoispYYH9Rt8Dt ZS0IF1VSRkHweCNEdcmu/QCUjzd7UzxtoPdIUB98yxUxTSBQ2gNmDqaLY7x6Pf2oTvVvHjpB mUnEtO3GMQHaKXhF2S4wnnfLPaGrqKvuRYu0LJLsaa0QxWO3A7VayaqpENLPK7XswTtcHPim cpNxo8QHav+A5OacAT2eiuyyUlmlx4gfpoWdlas5fsQ3rkyOytWGGHv+hhGplk5NI8lM08IH YEaJvLKSIzbsOycosMW0Tu4AAAAAAAA= --------------ms080709020609080503070301-- From owner-freebsd-ipfw@freebsd.org Thu May 4 18:07:48 2017 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 7C2A8D5E64E for ; Thu, 4 May 2017 18:07:48 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 3670A39F for ; Thu, 4 May 2017 18:07:48 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.10.40] (Karl-Desktop.Denninger.net [192.168.10.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 66B9D36B9C for ; Thu, 4 May 2017 13:07:47 -0500 (CDT) Subject: Re: Question that has dogged me for a while. To: freebsd-ipfw@freebsd.org References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> From: Karl Denninger Message-ID: Date: Thu, 4 May 2017 13:07:47 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080501050205010002010804" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 18:07:48 -0000 This is a cryptographically signed message in MIME format. --------------ms080501050205010002010804 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/4/2017 12:48, Dr. Rolf Jansen wrote: > Resolving this with ipfw/NAT may easily become quite complicated, if no= t impossible if you want to run a stateful nat'ting firewall, which is us= ually the better choice. > > IMHO a DNS based solution is much more effective. > > On my gateway I have running the caching DNS resolver Unbound. Now let'= s assume, the second level domain name in question is example.com, and yo= ur web server would be accessed by www.example.com, while other services,= e.g. mail are served from other sites on the internet. > > In unbound.conf you would place two additional lines before any forward= ing directive: > > local-zone: "example.com" transparent > local-data: "www.example.com" A 192.168.1.1 > > All the clients on the LAN should use the DNS service on the gateway. I= n the first place Unbound does higher level DNS lookups locally, however,= the transparent attribute lets it fall through to its normal recursive o= r forwarding behaviour in case a given domain could not be resolved local= ly. For example, the query of www.example.com would return 192.168.1.1 an= d the query for mail.example.com would be passed either to the forwarder = or resolved recursively from the internet. > > By this way, local clients would directly access your web server from t= he inside, no NAT is needed. > > IMHO, a DNS server on the gateway got more advantages. It can be used t= o block access to fraudulent or otherwise useless services on the interne= t for the whole LAN. > > Best regards > > Rolf > That's another alternative I'm considering which might wind up being the way I ultimately go.... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080501050205010002010804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MDQxODA3NDdaME8GCSqGSIb3DQEJBDFCBEAsCdg3 KyDoFGdSr6jb9RVm2NYZQVeGhE5AAhlv+CumIyQHCsQtLaJHmZMbyR2G6Y91CNKqRyCBxTrp dRyftSjwMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAIs03sEPJ7YIh bE7HINAfuk5xdCHk3rY58ELoRX8pM80VFcuZeEH9PZIEpb/0y0sKEfApq7Q0TmfK+qPNsAk5 kyDdcmR9eHE5a6NqGycN+oaKZKcFb9Fj+soY7MCCTWg2961Dg0IXFdAQzSpwjQaAOtX7gEds Zcy0T0u2dSq9NnkiirKwCHdItAg2fGoOlQi4iCgDvel8SqV+x4ngoQvOPxrQIzDF6GV9KSRN Hk3Kub82UrTh6jdpk8sqNN1I5RuXCbf3FGmCjHF3YZsbzdj6pjkzvWWEugerQt2fVe+EV2nl aavCiuKz7iqEBcBDkFDoNOJen3puusuHQcz4Odr8yUvWhJT5wnUOeQ3M5nNcT4iDPWpyposV t3kZ388oGbVe7ioPSO93PpEmTZE/8rLmbsoNv8bAOQWT86rUUQYNkvo8YK6RKcgAVOi8Z4Ow k7/Wzio/laMO3jJpe5KzKzOokPTXV+XMWBmBiysqjkFCGKY5/GWjH3xo2Lc7dGY4AveV+OLP WxmgHwkUF7z2aV+RFp/1zC7n3PnKojtLME2FF3zQ8llYvZKxWs7fQ0OrHx+Y9wiWNhgqpGwD FEe7w7pjgtljgSfWD6vQJ1jrHdOF8Lsny/3MjllzAEE/Z4gcmbmP7Gpi8Cir7Musu3eRssza G/hA/g4CvavsJ+XlXzswb6cAAAAAAAA= --------------ms080501050205010002010804-- From owner-freebsd-ipfw@freebsd.org Thu May 4 18:47:28 2017 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 AE43FD5EF4F for ; Thu, 4 May 2017 18:47:28 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77B471DC7 for ; Thu, 4 May 2017 18:47:28 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v44IlOVr005603; Thu, 4 May 2017 11:47:24 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v44IlOgn005602; Thu, 4 May 2017 11:47:24 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201705041847.v44IlOgn005602@pdx.rh.CN85.dnsmgr.net> Subject: Re: Question that has dogged me for a while. In-Reply-To: To: Karl Denninger Date: Thu, 4 May 2017 11:47:24 -0700 (PDT) CC: freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 18:47:28 -0000 > > On 5/4/2017 12:12, Rodney W. Grimes wrote: > >> Consider the following network configuration. > >> > >> > >> Internet ------- Gateway/Firewall ---------- Inside network (including a > >> web host) > >> 70.16.10.1/28 192.168.0.0/24 > >> > >> The address of the outside is FICTIONAL, by the way. > >> > >> For policy reasons I do NOT want the gateway machine to actually have > >> the host on it. There may be a number of things running on there but > >> for the instant moment let's assume a standard pedestrian web host on > >> port 80. > >> > >> I have DNS pointing at "webhost.domain" @ 70.16.10.1. > >> > >> I have NAT on the gateway (NAT internal to the kernel), and a "hole > >> punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as > >> pat of the nat configuration statement. > >> > >> This works fine for anyone on the outside. HOWEVER, anyone on the > >> INTERNAL network cannot see the host. > >> > >> My NAT configuration looks like this: > >> > >> # > >> # Now divert all inbound packets that should go through NAT. Since this > >> is NAT > >> # it can only match a packet that previously was NATted on the way out. > >> # > >> ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} > >> # > >> # Check stateful rules; we want to go there directly if there is a match > >> # > >> ${fwcmd} add 7000 check-state > >> # > >> # Now pick up all *outbound* packets that originated from an inside address > >> # and put them through NAT. We then have > >> # a packet with a local source address and we can allow it to be sent. > >> # Therefore, if the packet is outbound let it pass and be done with it. > >> # > >> ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif} > >>>> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} > >> ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit > >> ${oif} > >> ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} > >> > >> Without the ">>" line I get nothing; the packets get to the gateway and > >> disappear. > >> > >> With the ">>" line I DO get the packets re-emitted on the internal > >> interface HOWEVER there is no translation to the internal interface IP > >> on the gateway box. So what I see on the internal box is this: > >> > >> 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags > >> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale > >> 8,nop,nop,sackOK], length 0 > >> 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags > >> [S.], seq 3088872007, ack 292171179, win 65535, options [mss > >> 1460,nop,wscale 6,sackOK,eol], length 0 > >> > >> Which won't work because the internal box got and sent this: > > What is the NAT command running at instance 100? > > Does it have an -alias_address of inside IP of router? > > Are you tryint to use the same Nat instance to do both > > the global internet acess translation and this special > > inside loop back translation? If so that usually can > > not be made to work. > Aha. That's probably the problem -- I need a second instance. > > Here's the entire salient section: > > > # Set up the NAT configuration; there are multiple entries that have to > be here > # because we redirect a bunch of ports around so we can see things from the > # outside -- specifically, webcams and the HomeDaemon server. > # > ${fwcmd} nat 100 config ip ${oip} log same_ports reset > redirect_port tcp.... (whole bunch of stuff) > > # > # Stop spoofing > # > ${fwcmd} add 2010 deny log all from ${inet} to any not ipsec in > via ${oif} > ${fwcmd} add 2020 deny log all from ${onet} to any in via ${iif} > if [ -n "$inet6" ]; then > ${fwcmd} add 2040 deny all from ${inet6} to any in via > ${oif6} > if [ -n "$onet6" ]; then > ${fwcmd} add 2050 deny log all from ${onet6} to > any in \ > via ${iif6} > fi > fi > > ${fwcmd} add 3000 deny log all from ${onet} to any recv ${iif} > > # > # This table is a list of denied addresses that tried to attack us. Updated > # by sshguard. Anything coming inbound from the outside is blocked. We > also > # block anything on the "screw you" lists (two) > # > ${fwcmd} add 4000 deny log all from table\(22\) to any recv ${oif} > ${fwcmd} add 4010 deny all from any to ${foscam} > ${fwcmd} add 4020 deny log all from ${china} to any via ${oif} > # > # Anything related to RFC1918 or the Manning range that comes in on > # the external interface (shouldn't happen) gets tossed immediately, EXCEPT > # for RFC1918 stuff coming in via IPSEC. That we must pass or our IPSEC > # gateway will not work. > # > ${fwcmd} add 5000 deny log all from ${rfc1918} to any not ipsec > recv ${oif} > ${fwcmd} add 5010 deny log all from ${manning} to any recv ${oif} > > # > # Now divert all inbound packets that should go through NAT. Since this > is NAT > # it can only match a packet that previously was NATted on the way out. > # > ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} > # > # Check stateful rules; we want to go there directly if there is a match > # > ${fwcmd} add 7000 check-state > # > # Now pick up all *outbound* packets that originated from an inside address > # (including IPSEC tunneled stuff) and put them through NAT. We $then have > # a packet with a local source address and we can allow it to be sent. > # Therefore, if the packet is outbound let it pass and be done with it. > # > ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif} > ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} > ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit > ${oif} > ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} > > From the above I assume I need to direct 8001 through a nat 200, and > define that as "twist anything that comes through there to be aliased > from the INTERNAL IP address", yes? > > So I changed the above to be this: > > ${fwcmd} add 8000 nat 200 ip4 from 192.168.0.0/16 to ${oip} > ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif} > > So the first one would catch any inside packet that was headed to the > outside IP before the other gets ahold of it. What is your net.inet.ip.fw.one_pass set to? Are we getting counts on rule 8000 from a ipfw -a list 8000? > > And added: > > ipfw nat 200 config ip ${iip} same_ports reset > > Up above for the second NAT channel; "iip" is the gateway's internal IP > address. Yep yep, that looks good. > > But that winds up doing nothing; I get no packets back out on the inside > interface at all (just as if the "200" nat stuff was not there at all) Lets see if there are packets matching the rule, and if so maybe add log to the rule, and add a log rule after it to catch what the packets may look like after that nat. You may also be falling on down and denying the packet it some future rule, like a keep state rule???? It is almost impossible to remotly debug this type of stuff without a complete and full picture of all elements involved. As a minimum: ifconfig -a ipfw -a list sysctl net.inet.ip.fw.one_pass sysctl net.inet.ip.forwarding I know this can be made to work, I think even dd-wrt has it right.... And here is a good jumping off point from a very quick google: http://www.nycnetworkers.com/real-world/nat-reflectionnat-loopbacknat-hairpinning/ > >> 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S], > >> seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], > >> length 0 > >> 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S], > >> seq 2666765817, win 8192, options [mss 1460,nop,wscale > >> 8,nop,nop,sackOK], length 0 > >>>> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags > >> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale > >> 8,nop,nop,sackOK], length 0 > >>>> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags > >> [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale > >> 8,nop,nop,sackOK], length 0 > >> > >> But since the gateway emitted the packet back on the wire *without* > >> remapping the source address (to itself) it doesn't match on the client > >> box 'cause there's no way back for it. > > Yep. > > > >> There has to be a solution to this somewhere and I'm obviously missing > >> it..... :) > >> > >> -- > >> Karl Denninger > >> karl@denninger.net > >> /The Market Ticker/ > >> /[S/MIME encrypted email preferred]/ > > This is the classical "Loopback Nat Problem" of accessing machines > > behind a NAT device that does not do the proper NATTing and > > routing of these packets. Many small consumer routers got this > > wrong for years, just like most ipfw code I have seen. > > > > Most of the consumber devices have been fixed. The trickery is > > you need to NAT packets coming from the inside destined for the > > outside IP into the internal IP. That internal box MUST route > > back via the NAT device, so the NATTED addresses for these > > packets must be the inside IP of the router. > > > > Your code looks to get this mostly right, but I think you have > > missed something someplace. I dont use kernel nat, and it looks > > like you do so you well have to adjust these a little. > > > > inside_ip_router="192.168.10.40" > > outside_ip_router="70.16.10.1" > > inside_ip_webserver="192.168.10.100" > > > > #natd-vmxZ.conf should just be an empty file for this type of nat > > /sbin/natd -f /etc/firewall/natd-vmxZ.conf -port 8888 -alias_address ${192.168.10.40} > > > > Something like > > # This takes inside traffic to outside port 80 address and > > # remaps it to inside IP of router to send to web server > > ${fwcmd} add X divert 8888 tcp from 192.168.0.0/24 to ${outside_ip_router} port 80 > > # This translates the returning packets > > ${fwcmd} add X divert 8888 tcp from 192.168.0.0/24 port 80 to ${inside_ip_router} > > > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-ipfw@freebsd.org Thu May 4 19:17:55 2017 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 147E5D5BA39 for ; Thu, 4 May 2017 19:17:55 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id C389E1698 for ; Thu, 4 May 2017 19:17:54 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.10.40] (Karl-Desktop.Denninger.net [192.168.10.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 7121B36CCE for ; Thu, 4 May 2017 14:17:53 -0500 (CDT) Subject: Re: Question that has dogged me for a while. To: freebsd-ipfw@freebsd.org References: <201705041847.v44IlOgn005602@pdx.rh.CN85.dnsmgr.net> From: Karl Denninger Message-ID: <5c22b7f9-f120-5912-21c8-1de481b2f3c7@denninger.net> Date: Thu, 4 May 2017 14:17:52 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <201705041847.v44IlOgn005602@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050606000007060306090100" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 19:17:55 -0000 This is a cryptographically signed message in MIME format. --------------ms050606000007060306090100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/4/2017 13:47, Rodney W. Grimes wrote: >> On 5/4/2017 12:12, Rodney W. Grimes wrote: >>>> Consider the following network configuration. >>>> >>>> >>>> Internet ------- Gateway/Firewall ---------- Inside network (includi= ng a >>>> web host) >>>> 70.16.10.1/28 192.168.0.0/24 =20 >>>> >>>> The address of the outside is FICTIONAL, by the way. >>>> >>>> For policy reasons I do NOT want the gateway machine to actually hav= e >>>> the host on it. There may be a number of things running on there bu= t >>>> for the instant moment let's assume a standard pedestrian web host o= n >>>> port 80. >>>> >>>> I have DNS pointing at "webhost.domain" @ 70.16.10.1. >>>> >>>> I have NAT on the gateway (NAT internal to the kernel), and a "hole >>>> punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 = as >>>> pat of the nat configuration statement. >>>> >>>> This works fine for anyone on the outside. HOWEVER, anyone on the >>>> INTERNAL network cannot see the host. >>>> >>>> My NAT configuration looks like this: >>>> >>>> # >>>> # Now divert all inbound packets that should go through NAT. Since t= his >>>> is NAT >>>> # it can only match a packet that previously was NATted on the way o= ut. >>>> # >>>> ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} >>>> # >>>> # Check stateful rules; we want to go there directly if there is a m= atch >>>> # >>>> ${fwcmd} add 7000 check-state >>>> # >>>> # Now pick up all *outbound* packets that originated from an inside = address >>>> # and put them through NAT. We then have >>>> # a packet with a local source address and we can allow it to be sen= t. >>>> # Therefore, if the packet is outbound let it pass and be done with = it. >>>> # >>>> ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmi= t ${oif} >>>>>> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} >>>> ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xm= it >>>> ${oif} >>>> ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} >>>> >>>> Without the ">>" line I get nothing; the packets get to the gateway = and >>>> disappear. >>>> >>>> With the ">>" line I DO get the packets re-emitted on the internal >>>> interface HOWEVER there is no translation to the internal interface = IP >>>> on the gateway box. So what I see on the internal box is this: >>>> >>>> 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags= >>>> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale >>>> 8,nop,nop,sackOK], length 0 >>>> 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags= >>>> [S.], seq 3088872007, ack 292171179, win 65535, options [mss >>>> 1460,nop,wscale 6,sackOK,eol], length 0 >>>> >>>> Which won't work because the internal box got and sent this: >>> What is the NAT command running at instance 100? >>> Does it have an -alias_address of inside IP of router? >>> Are you tryint to use the same Nat instance to do both >>> the global internet acess translation and this special >>> inside loop back translation? If so that usually can >>> not be made to work. >> Aha. That's probably the problem -- I need a second instance. >> >> Here's the entire salient section: >> >> >> # Set up the NAT configuration; there are multiple entries that have t= o >> be here >> # because we redirect a bunch of ports around so we can see things fro= m the >> # outside -- specifically, webcams and the HomeDaemon server. >> # >> ${fwcmd} nat 100 config ip ${oip} log same_ports reset >> redirect_port tcp.... (whole bunch of stuff) >> >> # >> # Stop spoofing >> # >> ${fwcmd} add 2010 deny log all from ${inet} to any not ipsec i= n >> via ${oif} >> ${fwcmd} add 2020 deny log all from ${onet} to any in via ${ii= f} >> if [ -n "$inet6" ]; then >> ${fwcmd} add 2040 deny all from ${inet6} to any in via= >> ${oif6} >> if [ -n "$onet6" ]; then >> ${fwcmd} add 2050 deny log all from ${onet6} t= o >> any in \ >> via ${iif6} >> fi >> fi >> >> ${fwcmd} add 3000 deny log all from ${onet} to any recv ${iif}= >> >> # >> # This table is a list of denied addresses that tried to attack us. U= pdated >> # by sshguard. Anything coming inbound from the outside is blocked. = We >> also >> # block anything on the "screw you" lists (two) >> # >> ${fwcmd} add 4000 deny log all from table\(22\) to any recv ${= oif} >> ${fwcmd} add 4010 deny all from any to ${foscam} >> ${fwcmd} add 4020 deny log all from ${china} to any via ${oif}= >> # >> # Anything related to RFC1918 or the Manning range that comes in on >> # the external interface (shouldn't happen) gets tossed immediately, E= XCEPT >> # for RFC1918 stuff coming in via IPSEC. That we must pass or our IPS= EC >> # gateway will not work. >> # >> ${fwcmd} add 5000 deny log all from ${rfc1918} to any not ipse= c >> recv ${oif} >> ${fwcmd} add 5010 deny log all from ${manning} to any recv ${o= if} >> >> # >> # Now divert all inbound packets that should go through NAT. Since thi= s >> is NAT >> # it can only match a packet that previously was NATted on the way out= =2E >> # >> ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} >> # >> # Check stateful rules; we want to go there directly if there is a mat= ch >> # >> ${fwcmd} add 7000 check-state >> # >> # Now pick up all *outbound* packets that originated from an inside ad= dress >> # (including IPSEC tunneled stuff) and put them through NAT. We $then= have >> # a packet with a local source address and we can allow it to be sent.= >> # Therefore, if the packet is outbound let it pass and be done with it= =2E >> # >> ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit = ${oif} >> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} >> ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit= >> ${oif} >> ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} >> >> From the above I assume I need to direct 8001 through a nat 200, and >> define that as "twist anything that comes through there to be aliased >> from the INTERNAL IP address", yes? >> >> So I changed the above to be this: >> =20 >> ${fwcmd} add 8000 nat 200 ip4 from 192.168.0.0/16 to ${oip} >> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to any xmit $= {oif} >> >> So the first one would catch any inside packet that was headed to the >> outside IP before the other gets ahold of it. > What is your net.inet.ip.fw.one_pass set to? 0. (This config on the host IS working generally for NAT) > > Are we getting counts on rule 8000 from a ipfw -a list 8000? Yes. >> And added: >> >> ipfw nat 200 config ip ${iip} same_ports reset >> >> Up above for the second NAT channel; "iip" is the gateway's internal I= P >> address. > Yep yep, that looks good. > >> But that winds up doing nothing; I get no packets back out on the insi= de >> interface at all (just as if the "200" nat stuff was not there at all)= > Lets see if there are packets matching the rule, and if so maybe add lo= g to the rule, > and add a log rule after it to catch what the packets may look like aft= er that nat. > You may also be falling on down and denying the packet it some future r= ule, like > a keep state rule???? Don't think so. There's a rule right under it that should pass it (and thus terminate.) > It is almost impossible to remotly debug this type of stuff without a > complete and full picture of all elements involved. > As a minimum: > ifconfig -a > ipfw -a list > sysctl net.inet.ip.fw.one_pass > sysctl net.inet.ip.forwarding > > I know this can be made to work, I think even dd-wrt has it right.... > And here is a good jumping off point from a very quick google: > http://www.nycnetworkers.com/real-world/nat-reflectionnat-loopbacknat-h= airpinning/=20 root@IPGw:/usr/local/etc # ifconfig -a lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=3D21 ue0: flags=3D8843 metric 0 mtu 15= 00 options=3D80009 ether b8:27:eb:4e:88:64 inet 192.168.10.200 netmask 0xffffff00 broadcast 192.168.10.255 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D29 ue1: flags=3D8843 metric 0 mtu 15= 00 options=3D8000b ether 00:50:b6:5d:1d:9f inet 70.169.168.7 netmask 0xffffff80 broadcast 70.169.168.127 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D29 ue0.3: flags=3D8843 metric 0 mtu = 1500 ether b8:27:eb:4e:88:64 inet 192.168.4.200 netmask 0xffffff00 broadcast 192.168.4.255 groups: vlan vlan: 3 vlanpcp: 0 parent interface: ue0 media: Ethernet autoselect (100baseTX ) status: active nd6 options=3D29 root@IPGw:/usr/local/etc # ipfw -a list 00100 14 1042 allow ip from any to any via lo0 00200 0 0 deny log ip from any to 127.0.0.0/8 00300 0 0 deny log ip from 127.0.0.0/8 to any 00400 0 0 deny log ip from any to ::1 00500 0 0 deny log ip from ::1 to any 02000 0 0 allow ip from 192.168.100.1 to any in via ue1 02010 0 0 deny log ip from 192.168.0.0/16 to any not ipsec in via ue1 02020 0 0 deny log ip from 70.169.168.0/25 to any in via ue0 03000 0 0 deny log ip from 70.169.168.0/25 to any recv ue0 04000 0 0 deny log ip from table(22) to any recv ue1 04010 0 0 deny ip from any to 114.215.179.104,122.226.84.253,122.248.234.207,167.206.87.147,168.1.83.89= ,175.41.238.100,176.58.116.160,202.96.134.133,203.143.89.106,220.181.111.= 147,23.234.53.61,23.234.53.67,46.137.188.54,50.19.254.134,50.7.114.59,50.= 7.124.48,50.7.176.18,50.7.235.90,50.7.44.82,61.188.37.216,68.192.249.119,= 74.125.31.99 04020 0 0 deny log ip from 218.90.0.0/16,218.91.0.0/16,218.92.0.0/16,218.93.0.0/16,218.94.0.0/16 to any via ue1 05000 0 0 deny log ip from 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 to any not ipsec recv ue1 05010 0 0 deny log ip from 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 to any recv ue1 06000 8726 10333291 nat 100 ip4 from any to me recv ue1 07000 0 0 check-state :default 08000 21 1064 nat 200 ip4 from 192.168.0.0/16 to 70.169.168.7 08001 4834 264258 nat 100 ip4 from 192.168.0.0/16 to any xmit ue1 08009 0 0 deny log ip4 from 192.168.0.0/16 to any xmit ue1 08010 4836 264410 allow ip4 from 70.169.168.0/25 to any xmit ue1 08011 0 0 allow log ip from 192.168.10.200 to 192.168.0.0/16 dst-port 2552 08020 5374 306553 allow ip from 192.168.0.0/16 to any recv ue0 08030 2 104 allow ip from 192.168.4.0/25 to any recv ue0.3 08500 0 0 deny log ip from 192.168.0.0/16 to any xmit ue1 09000 17823 20712366 allow ip from any to 192.168.0.0/16 22000 0 0 allow tcp from any to any established 22700 0 0 allow tcp from any to me dst-port 2200 setup 22710 0 0 allow tcp from any to me dst-port 22 setup 22800 0 0 allow icmp from any to me 23100 0 0 allow udp from any to me dst-port 33434-34000 23110 0 0 allow udp from any 33434-34000 to me 23410 0 0 allow udp from any to me dst-port 53 23420 0 0 allow udp from me 53 to any 23430 4 545 allow udp from any 53 to me 23500 0 0 allow tcp from any to 192.168.1.214 dst-port 8080 se= tup 23510 0 0 allow tcp from any to 192.168.4.210 dst-port 443 set= up 23520 0 0 allow tcp from any to 192.168.4.211 dst-port 443 set= up 23530 0 0 allow tcp from any to 192.168.4.211 dst-port 554 set= up 24430 0 0 allow udp from any 123 to me dst-port 123 24500 0 0 allow udp from any to me dst-port 500 24510 0 0 allow udp from me 500 to any 24520 0 0 allow udp from any to me dst-port 4500 24530 0 0 allow udp from me 4500 to any 24600 46 2760 deny tcp from 192.168.4.211 to any dst-port 80 setup= 29999 5 272 deny log ip from any to any 65535 2603 379766 deny ip from any to any onepass is 0, forwarding is 1 of course. root@IPGw:/usr/local/etc # sysctl -a|grep forwarding net.inet.ip.forwarding: 1 net.inet6.ip6.forwarding: 0 root@IPGw:/usr/local/etc # sysctl -a | grep one_pass net.inet.ip.fw.one_pass: 0 If it matters this is running on -HEAD (it's running on a PI3, so -HEAD is a mandate at this point.) The 0.3 interface is a VLAN for things that I have DMZd off so they can't play "send back data to poppa and scan the LAN" games (think consumer appliances.) Line 8000 does have packets that match. There IS a "check-state" right above it, but that shouldn't kill the output side -- and I moved it to 10000 (below the pass lines) without effect, just in case it was. NAT is working perfectly well for someone on the internal network but connecting to something outside on the Internet and the "hole punches" for a connection outside to the interior host work as well. Note that the line 8011, which SHOULD trap a "telnet 70.169.168.7 2552" from the inside network (and which DOES generate the packet counts on line 8000) does NOT register counts nor log anything, so whatever is nailing it it's happening before it gets there -- which is why I'm confused here. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050606000007060306090100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MDQxOTE3NTJaME8GCSqGSIb3DQEJBDFCBEAV5wvk uz0gtQEDSbEtOhRWaXw/9CjjKzKgDMMUxB3DKwyQ04uclSjbPiiWOP7WT3oAOXgqA9mb7J8j wmeXTNbqMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAwt7VbSqh7vP7 1+CkleC3i52zDYJKhIsEESaxsvORaaks5EkMnUW+vG00yZTSsq+fxLpN9mDdxv8u6EpomrYQ k9nxs65LxVDv+stlcNSE/rkpdqEQPDei7G+pV5imEi3H9ROyqVetWSCFvOxCBSQwrPlAToz4 6+wYaMJXpnOanU4X5Ww5aDOtC4zD1JihicGAJlaIycCEUpF5Jv6Y4BixcLqMbpgACRFjAiKp xrynlg8Biev6q5th9nJ0Y0IhqXk8TdJoN/4F5vzMyhjGyWU6IngABXBGbuUUoY06hPlzSGG9 CRRyVR9P1FBFIeSpsen6fM0PL0TtAx0Mv4jF3sFBJMggNZ0NG8y/iBDR8yuc+0Xu42Vwz9tX twUlLCSUvDBdJj/XEFT3aFIPifKeitpITnRY1mxOeLVaG+8lISw79B4IKb21CU8cmOE8YD8M ZlhidcsEIkn3NWNFDNN39u1hYDp6nKqu5BeJdXeDybUiNNW4t0MPpXdJViqySBu1RGRCKIGj Kn5JxDc1aqFjSN/zcc3I/uWnnsw0hUuqXxRsfcBfaxugP/PlzxVkTlr9Nmut6vRqLcOIMDjy Zd3qtda8fq9FhIJQSi6zLb6Qb1AcEl/jvND227l75s8WJ3yki8M2RRVck9tZKXLA6xTgD5Dp U1o4eV6bZTTnOxOf4i52VZYAAAAAAAA= --------------ms050606000007060306090100-- From owner-freebsd-ipfw@freebsd.org Thu May 4 19:44:41 2017 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 6CBA3D5D2EB for ; Thu, 4 May 2017 19:44:41 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 43C608EC for ; Thu, 4 May 2017 19:44:40 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v44JibYC005861; Thu, 4 May 2017 12:44:37 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v44JibiT005860; Thu, 4 May 2017 12:44:37 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201705041944.v44JibiT005860@pdx.rh.CN85.dnsmgr.net> Subject: Re: Question that has dogged me for a while. In-Reply-To: <5c22b7f9-f120-5912-21c8-1de481b2f3c7@denninger.net> To: Karl Denninger Date: Thu, 4 May 2017 12:44:37 -0700 (PDT) CC: freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 19:44:41 -0000 > On 5/4/2017 13:47, Rodney W. Grimes wrote: > >> On 5/4/2017 12:12, Rodney W. Grimes wrote: > >>>> Consider the following network configuration. > >>>> > >>>> > >>>> Internet ------- Gateway/Firewall ---------- Inside network (including a > >>>> web host) > >>>> 70.16.10.1/28 192.168.0.0/24 ... > > It is almost impossible to remotly debug this type of stuff without a > > complete and full picture of all elements involved. > > As a minimum: > > ifconfig -a > > ipfw -a list > > sysctl net.inet.ip.fw.one_pass > > sysctl net.inet.ip.forwarding > > > > I know this can be made to work, I think even dd-wrt has it right.... > > And here is a good jumping off point from a very quick google: > > http://www.nycnetworkers.com/real-world/nat-reflectionnat-loopbacknat-hairpinning/ > root@IPGw:/usr/local/etc # ifconfig -a > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 > inet 127.0.0.1 netmask 0xff000000 > groups: lo > nd6 options=21 > ue0: flags=8843 metric 0 mtu 1500 > options=80009 > ether b8:27:eb:4e:88:64 > inet 192.168.10.200 netmask 0xffffff00 broadcast 192.168.10.255 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > ue1: flags=8843 metric 0 mtu 1500 > options=8000b > ether 00:50:b6:5d:1d:9f > inet 70.169.168.7 netmask 0xffffff80 broadcast 70.169.168.127 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > ue0.3: flags=8843 metric 0 mtu 1500 > ether b8:27:eb:4e:88:64 > inet 192.168.4.200 netmask 0xffffff00 broadcast 192.168.4.255 > groups: vlan > vlan: 3 vlanpcp: 0 parent interface: ue0 > media: Ethernet autoselect (100baseTX ) > status: active > nd6 options=29 > > root@IPGw:/usr/local/etc # ipfw -a list > 00100 14 1042 allow ip from any to any via lo0 > 00200 0 0 deny log ip from any to 127.0.0.0/8 > 00300 0 0 deny log ip from 127.0.0.0/8 to any > 00400 0 0 deny log ip from any to ::1 > 00500 0 0 deny log ip from ::1 to any > 02000 0 0 allow ip from 192.168.100.1 to any in via ue1 > 02010 0 0 deny log ip from 192.168.0.0/16 to any not ipsec in > via ue1 > 02020 0 0 deny log ip from 70.169.168.0/25 to any in via ue0 > 03000 0 0 deny log ip from 70.169.168.0/25 to any recv ue0 > 04000 0 0 deny log ip from table(22) to any recv ue1 > 04010 0 0 deny ip from any to > 114.215.179.104,122.226.84.253,122.248.234.207,167.206.87.147,168.1.83.89,175.41.238.100,176.58.116.160,202.96.134.133,203.143.89.106,220.181.111.147,23.234.53.61,23.234.53.67,46.137.188.54,50.19.254.134,50.7.114.59,50.7.124.48,50.7.176.18,50.7.235.90,50.7.44.82,61.188.37.216,68.192.249.119,74.125.31.99 > 04020 0 0 deny log ip from > 218.90.0.0/16,218.91.0.0/16,218.92.0.0/16,218.93.0.0/16,218.94.0.0/16 to > any via ue1 > 05000 0 0 deny log ip from > 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 to any not ipsec recv ue1 > 05010 0 0 deny log ip from > 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 to any > recv ue1 > 06000 8726 10333291 nat 100 ip4 from any to me recv ue1 > 07000 0 0 check-state :default > 08000 21 1064 nat 200 ip4 from 192.168.0.0/16 to 70.169.168.7 Where is the other half of nat 200? This is from inside to outside IP, there needs to be a return nat occuring to de Nat the packets ipfw add 8000 nat 200 ip4 from 192.168.0.0/16 to 192.168.10.200,192.168.4.200 It takes 2 rules to the same NAT to have working NAT usually, one for outbound packets, and one for inbound packets (relative to the NAT instance). Do we see atleast the packets this nats on the wire with tcpdump? > 08001 4834 264258 nat 100 ip4 from 192.168.0.0/16 to any xmit ue1 > 08009 0 0 deny log ip4 from 192.168.0.0/16 to any xmit ue1 > 08010 4836 264410 allow ip4 from 70.169.168.0/25 to any xmit ue1 > 08011 0 0 allow log ip from 192.168.10.200 to 192.168.0.0/16 > dst-port 2552 > 08020 5374 306553 allow ip from 192.168.0.0/16 to any recv ue0 > 08030 2 104 allow ip from 192.168.4.0/25 to any recv ue0.3 > 08500 0 0 deny log ip from 192.168.0.0/16 to any xmit ue1 > 09000 17823 20712366 allow ip from any to 192.168.0.0/16 > 22000 0 0 allow tcp from any to any established Interesting that the count on this is 0? This is usually a stateless packet matching rule that goes with your setups. Nvm, there are not packets maching the setup rules, so no change to have this matter. > 22700 0 0 allow tcp from any to me dst-port 2200 setup > 22710 0 0 allow tcp from any to me dst-port 22 setup > 22800 0 0 allow icmp from any to me > 23100 0 0 allow udp from any to me dst-port 33434-34000 > 23110 0 0 allow udp from any 33434-34000 to me > 23410 0 0 allow udp from any to me dst-port 53 > 23420 0 0 allow udp from me 53 to any > 23430 4 545 allow udp from any 53 to me > 23500 0 0 allow tcp from any to 192.168.1.214 dst-port 8080 setup > 23510 0 0 allow tcp from any to 192.168.4.210 dst-port 443 setup > 23520 0 0 allow tcp from any to 192.168.4.211 dst-port 443 setup > 23530 0 0 allow tcp from any to 192.168.4.211 dst-port 554 setup > 24430 0 0 allow udp from any 123 to me dst-port 123 > 24500 0 0 allow udp from any to me dst-port 500 > 24510 0 0 allow udp from me 500 to any > 24520 0 0 allow udp from any to me dst-port 4500 > 24530 0 0 allow udp from me 4500 to any > 24600 46 2760 deny tcp from 192.168.4.211 to any dst-port 80 setup What are these denied packets? Part of our issue? > 29999 5 272 deny log ip from any to any And these? > 65535 2603 379766 deny ip from any to any > > onepass is 0, forwarding is 1 of course. > root@IPGw:/usr/local/etc # sysctl -a|grep forwarding > net.inet.ip.forwarding: 1 > net.inet6.ip6.forwarding: 0 > root@IPGw:/usr/local/etc # sysctl -a | grep one_pass > net.inet.ip.fw.one_pass: 0 > > If it matters this is running on -HEAD (it's running on a PI3, so -HEAD > is a mandate at this point.) The 0.3 interface is a VLAN for things > that I have DMZd off so they can't play "send back data to poppa and > scan the LAN" games (think consumer appliances.) > > Line 8000 does have packets that match. There IS a "check-state" right > above it, but that shouldn't kill the output side -- and I moved it to > 10000 (below the pass lines) without effect, just in case it was. NAT > is working perfectly well for someone on the internal network but > connecting to something outside on the Internet and the "hole punches" > for a connection outside to the interior host work as well. Note that > the line 8011, which SHOULD trap a "telnet 70.169.168.7 2552" from the > inside network (and which DOES generate the packet counts on line 8000) > does NOT register counts nor log anything, so whatever is nailing it > it's happening before it gets there -- which is why I'm confused here. > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-ipfw@freebsd.org Thu May 4 20:02:08 2017 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 A62E0D5DDE0 for ; Thu, 4 May 2017 20:02:08 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 62BFC7E1 for ; Thu, 4 May 2017 20:02:08 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.10.40] (Karl-Desktop.Denninger.net [192.168.10.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 7E91A36D3F for ; Thu, 4 May 2017 15:02:07 -0500 (CDT) Subject: Re: Question that has dogged me for a while. To: freebsd-ipfw@freebsd.org References: <201705041944.v44JibiT005860@pdx.rh.CN85.dnsmgr.net> From: Karl Denninger Message-ID: <2d59cd7e-2064-5304-9c6d-1fc205c48feb@denninger.net> Date: Thu, 4 May 2017 15:02:07 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <201705041944.v44JibiT005860@pdx.rh.CN85.dnsmgr.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050100060403040602020503" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 20:02:08 -0000 This is a cryptographically signed message in MIME format. --------------ms050100060403040602020503 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/4/2017 14:44, Rodney W. Grimes wrote: >> On 5/4/2017 13:47, Rodney W. Grimes wrote: >>>> On 5/4/2017 12:12, Rodney W. Grimes wrote: >>>>>> Consider the following network configuration. >>>>>> >>>>>> >>>>>> Internet ------- Gateway/Firewall ---------- Inside network (inclu= ding a >>>>>> web host) >>>>>> 70.16.10.1/28 192.168.0.0/24 =20 > ... > >>> It is almost impossible to remotly debug this type of stuff without a= >>> complete and full picture of all elements involved. >>> As a minimum: >>> ifconfig -a >>> ipfw -a list >>> sysctl net.inet.ip.fw.one_pass >>> sysctl net.inet.ip.forwarding >>> >>> I know this can be made to work, I think even dd-wrt has it right....= >>> And here is a good jumping off point from a very quick google: >>> http://www.nycnetworkers.com/real-world/nat-reflectionnat-loopbacknat= -hairpinning/=20 >> root@IPGw:/usr/local/etc # ifconfig -a >> lo0: flags=3D8049 metric 0 mtu 16384 >> options=3D600003 >> inet6 ::1 prefixlen 128 >> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 >> inet 127.0.0.1 netmask 0xff000000 >> groups: lo >> nd6 options=3D21 >> ue0: flags=3D8843 metric 0 mtu= 1500 >> options=3D80009 >> ether b8:27:eb:4e:88:64 >> inet 192.168.10.200 netmask 0xffffff00 broadcast 192.168.10.25= 5 >> media: Ethernet autoselect (100baseTX ) >> status: active >> nd6 options=3D29 >> ue1: flags=3D8843 metric 0 mtu= 1500 >> options=3D8000b >> ether 00:50:b6:5d:1d:9f >> inet 70.169.168.7 netmask 0xffffff80 broadcast 70.169.168.127 >> media: Ethernet autoselect (100baseTX ) >> status: active >> nd6 options=3D29 >> ue0.3: flags=3D8843 metric 0 m= tu 1500 >> ether b8:27:eb:4e:88:64 >> inet 192.168.4.200 netmask 0xffffff00 broadcast 192.168.4.255 >> groups: vlan >> vlan: 3 vlanpcp: 0 parent interface: ue0 >> media: Ethernet autoselect (100baseTX ) >> status: active >> nd6 options=3D29 >> >> root@IPGw:/usr/local/etc # ipfw -a list >> 00100 14 1042 allow ip from any to any via lo0 >> 00200 0 0 deny log ip from any to 127.0.0.0/8 >> 00300 0 0 deny log ip from 127.0.0.0/8 to any >> 00400 0 0 deny log ip from any to ::1 >> 00500 0 0 deny log ip from ::1 to any >> 02000 0 0 allow ip from 192.168.100.1 to any in via ue1 >> 02010 0 0 deny log ip from 192.168.0.0/16 to any not ipsec = in >> via ue1 >> 02020 0 0 deny log ip from 70.169.168.0/25 to any in via ue= 0 >> 03000 0 0 deny log ip from 70.169.168.0/25 to any recv ue0 >> 04000 0 0 deny log ip from table(22) to any recv ue1 >> 04010 0 0 deny ip from any to >> 114.215.179.104,122.226.84.253,122.248.234.207,167.206.87.147,168.1.83= =2E89,175.41.238.100,176.58.116.160,202.96.134.133,203.143.89.106,220.181= =2E111.147,23.234.53.61,23.234.53.67,46.137.188.54,50.19.254.134,50.7.114= =2E59,50.7.124.48,50.7.176.18,50.7.235.90,50.7.44.82,61.188.37.216,68.192= =2E249.119,74.125.31.99 >> 04020 0 0 deny log ip from >> 218.90.0.0/16,218.91.0.0/16,218.92.0.0/16,218.93.0.0/16,218.94.0.0/16 = to >> any via ue1 >> 05000 0 0 deny log ip from >> 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 to any not ipsec recv ue1 >> 05010 0 0 deny log ip from >> 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 to any >> recv ue1 >> 06000 8726 10333291 nat 100 ip4 from any to me recv ue1 >> 07000 0 0 check-state :default >> 08000 21 1064 nat 200 ip4 from 192.168.0.0/16 to 70.169.168.7 > Where is the other half of nat 200? This is from inside to outside IP,= > there needs to be a return nat occuring to de Nat the packets > ipfw add 8000 nat 200 ip4 from 192.168.0.0/16 to 192.168.10.200,192.168= =2E4.200 > It takes 2 rules to the same NAT to have working NAT usually, one for > outbound packets, and one for inbound packets (relative to the NAT inst= ance). > > > Do we see atleast the packets this nats on the wire with tcpdump? Nope! That's the problem at this point. I know there needs to be another one; I'll add it but it shouldn't matter until after I see the packets come out on the wire, right? (Added, no difference) >> 08001 4834 264258 nat 100 ip4 from 192.168.0.0/16 to any xmit ue1 >> 08009 0 0 deny log ip4 from 192.168.0.0/16 to any xmit ue1 >> 08010 4836 264410 allow ip4 from 70.169.168.0/25 to any xmit ue1 >> 08011 0 0 allow log ip from 192.168.10.200 to 192.168.0.0/1= 6 >> dst-port 2552 >> 08020 5374 306553 allow ip from 192.168.0.0/16 to any recv ue0 >> 08030 2 104 allow ip from 192.168.4.0/25 to any recv ue0.3 >> 08500 0 0 deny log ip from 192.168.0.0/16 to any xmit ue1 >> 09000 17823 20712366 allow ip from any to 192.168.0.0/16 >> 22000 0 0 allow tcp from any to any established > Interesting that the count on this is 0? This is usually a stateless > packet matching rule that goes with your setups. Nvm, there are not > packets maching the setup rules, so no change to have this matter. > >> 22700 0 0 allow tcp from any to me dst-port 2200 setup >> 22710 0 0 allow tcp from any to me dst-port 22 setup >> 22800 0 0 allow icmp from any to me >> 23100 0 0 allow udp from any to me dst-port 33434-34000 >> 23110 0 0 allow udp from any 33434-34000 to me >> 23410 0 0 allow udp from any to me dst-port 53 >> 23420 0 0 allow udp from me 53 to any >> 23430 4 545 allow udp from any 53 to me >> 23500 0 0 allow tcp from any to 192.168.1.214 dst-port 8080= setup >> 23510 0 0 allow tcp from any to 192.168.4.210 dst-port 443 = setup >> 23520 0 0 allow tcp from any to 192.168.4.211 dst-port 443 = setup >> 23530 0 0 allow tcp from any to 192.168.4.211 dst-port 554 = setup >> 24430 0 0 allow udp from any 123 to me dst-port 123 >> 24500 0 0 allow udp from any to me dst-port 500 >> 24510 0 0 allow udp from me 500 to any >> 24520 0 0 allow udp from any to me dst-port 4500 >> 24530 0 0 allow udp from me 4500 to any >> 24600 46 2760 deny tcp from 192.168.4.211 to any dst-port 80 se= tup > What are these denied packets? Part of our issue? No, those are packets coming from an IP cam that is trying to "phone home" and which I'm intentionally blocking. I am attempting to connect to port 2552 for the purpose of proving it up, not 80 (there IS a listener there and it's also an uncommon port so I don't get the noise from people trying to bang on the box when I'm tracing it.) >> 29999 5 272 deny log ip from any to any > And these? Nope -- random other people trying to bang things on the host from the Internet. root@IPGw:/usr/local/etc # grep 2552 /var/log/security root@IPGw:/usr/local/etc # Nothing in the log at all denying any packets. net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 1 This is all I get with tcpdump: root@IPGw:/usr/local/etc # tcpdump -n -i ue0 port 2552 14:51:23.968124 IP 192.168.10.40.50756 > 70.169.168.7.2552: Flags [S], seq 3005777928, win 8192, options [mss 1460,nop,nop,sackOK], length 0 14:51:23.968187 IP 192.168.10.40.50755 > 70.169.168.7.2552: Flags [S], seq 1100017986, win 8192, options [mss 1460,nop,nop,sackOK], length 0 14:51:24.217125 IP 192.168.10.40.50757 > 70.169.168.7.2552: Flags [S], seq 4201089264, win 8192, options [mss 1460,nop,nop,sackOK], length 0 The original packets headed to the gateway are on the wire but I never see the translated ones on the wire at all. It's like the 200 NAT swallowed the packets and never re-emitted them, nor do I have any indication where they went; they're not getting logged off any of the deny lines nor can I find them on the wire. With the changes to try to isolate it, here it is..... nothing (as expected) showing on 6000 and no packets on the wire from the attempted twist. root@IPGw:/usr/local/etc # ipfw -a list 00100 52 4660 allow ip from any to any via lo0 00200 0 0 deny log ip from any to 127.0.0.0/8 00300 0 0 deny log ip from 127.0.0.0/8 to any 00400 0 0 deny log ip from any to ::1 00500 0 0 deny log ip from ::1 to any 02000 0 0 allow ip from 192.168.100.1 to any in via ue1 02010 0 0 deny log ip from 192.168.0.0/16 to any not ipsec in via ue1 02020 0 0 deny log ip from 70.169.168.0/25 to any in via ue0 03000 0 0 deny log ip from 70.169.168.0/25 to any recv ue0 04000 0 0 deny log ip from table(22) to any recv ue1 04010 0 0 deny ip from any to 114.215.179.104,122.226.84.253,122.248.234.207,167.206.87.147,168.1.83.89= ,175.41.238.100,176.58.116.160,202.96.134.133,203.143.89.106,220.181.111.= 147,23.234.53.61,23.234.53.67,46.137.188.54,50.19.254.134,50.7.114.59,50.= 7.124.48,50.7.176.18,50.7.235.90,50.7.44.82,61.188.37.216,68.192.249.119,= 74.125.31.99 04020 0 0 deny log ip from 218.90.0.0/16,218.91.0.0/16,218.92.0.0/16,218.93.0.0/16,218.94.0.0/16 to any via ue1 05000 0 0 deny log ip from 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 to any not ipsec recv ue1 05010 0 0 deny log ip from 0.0.0.0/8,169.254.0.0/16,192.0.2.0/24,224.0.0.0/4,240.0.0.0/4 to any recv ue1 06000 0 0 nat 200 ip4 from 192.168.0.0/16 2552 to 192.168.10.2= 00 06010 9528 11688747 nat 100 ip4 from any to me recv ue1 07000 0 0 check-state :default 08000 15 768 nat 200 ip4 from 192.168.0.0/16 to 70.169.168.7 08001 5314 286721 nat 100 ip4 from 192.168.0.0/16 to any xmit ue1 08009 0 0 deny log ip4 from 192.168.0.0/16 to any xmit ue1 08010 5319 287081 allow ip4 from 70.169.168.0/25 to any xmit ue1 08011 0 0 allow log ip from 192.168.10.200 to 192.168.0.0/16 dst-port 2552 08020 5905 328699 allow ip from 192.168.0.0/16 to any recv ue0 08030 0 0 allow ip from 192.168.4.0/25 to any recv ue0.3 08500 0 0 deny log ip from 192.168.0.0/16 to any xmit ue1 09000 19682 23487591 allow ip from any to 192.168.0.0/16 22000 0 0 allow tcp from any to any established 22700 0 0 allow tcp from any to me dst-port 2200 setup 22710 0 0 allow tcp from any to me dst-port 22 setup 22800 4 284 allow icmp from any to me 23100 0 0 allow udp from any to me dst-port 33434-34000 23110 0 0 allow udp from any 33434-34000 to me 23410 0 0 allow udp from any to me dst-port 53 23420 0 0 allow udp from me 53 to any 23430 0 0 allow udp from any 53 to me 23500 0 0 allow tcp from any to 192.168.1.214 dst-port 8080 se= tup 23510 0 0 allow tcp from any to 192.168.4.210 dst-port 443 set= up 23520 0 0 allow tcp from any to 192.168.4.211 dst-port 443 set= up 23530 0 0 allow tcp from any to 192.168.4.211 dst-port 554 set= up 24430 0 0 allow udp from any 123 to me dst-port 123 24500 0 0 allow udp from any to me dst-port 500 24510 0 0 allow udp from me 500 to any 24520 0 0 allow udp from any to me dst-port 4500 24530 0 0 allow udp from me 4500 to any 24600 35 2100 deny tcp from 192.168.4.211 to any dst-port 80 setup= 29999 2 80 deny log ip from any to any 65535 2709 484767 deny ip from any to any --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050100060403040602020503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MDQyMDAyMDdaME8GCSqGSIb3DQEJBDFCBECi2au+ k3QyoR5ZESJ1YVJJzjAlbkYZ9X5MmvIkcHFHbW1VTLA2e7t4jK+yolEFvu7vjLZP4X0Govn+ ZzHowpsUMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAEvpa8D6riNdE OsPXEzKfqsGXyZGY0dHsAGZZPdCkl3XjCi4vgc7GB3U7V71YaJicEyo205geWUCT5BR3s9oZ byh7x3n9S1sEG0c5pQ3Rwjc1EQgS/96aw304Be/hDNK5ghuky0FzWqwYiYAWzD4XcL36uI4m chUTj34A0lN2PWr2TsHW07ZOWy7pmFLiwC2sd0OEitbuYO5/38w+oxkKLHyeupn7zyx/++Gu SPIMCV/V0KCxFSCnfEHd1hWSFhZ7HL55vtNmNFn6ewYexwWwoqCH54GAsZJ2koTAc3l8schs 221HfJWr/ZZcUTH5cVOdXvFKEpAuiryGoTaOks4W5xhlBRPsixD49yHu5gTDW6OAEl7nJlbI Dok+Hv9jXCd8QRb9yRl8hd06NoUS92W1a7Cvo7UN5t75CoIlAUG5uNkQu7aTQ+bx2htz1UZ8 krHPg6YbptsuQfr8aHJL8I5iz3Hj97PpSHXZzTyq8dXYEvFbHLC0C5/XX5EEr/L+m/iSBfH9 VXfQwkvVd+UFpb6bDSYV9UN7BrSREHFy8jxzxMg0mvxxKTM52wWBs2ymgYmxhZZ8rdF3avQe T15NlW3Pk+3X928RGnNnOfDVrABEVEcki0asOoM/aeeKFhocA9twaWryj7gfyMhcfvLeVJYz IUTUjjX7tjvsMOqXHqarpesAAAAAAAA= --------------ms050100060403040602020503-- From owner-freebsd-ipfw@freebsd.org Thu May 4 21:46:28 2017 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 398CFD5E753 for ; Thu, 4 May 2017 21:46:28 +0000 (UTC) (envelope-from marco@tols.org) Received: from tolstoy.tols.org (tolstoy-a1.tols.org [IPv6:2a02:898:57:3::1]) (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 0A3B7B19 for ; Thu, 4 May 2017 21:46:27 +0000 (UTC) (envelope-from marco@tols.org) Received: from [2a02:898:57:1:6d68:35bc:71cb:c1d6] by tolstoy.tols.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87_1 (FreeBSD)) (envelope-from ) id 1d6OZr-0007yl-Sa; Thu, 04 May 2017 23:46:23 +0200 From: Marco van Tol Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: equivalent for pf's max-src-conn-rate in ipfw Message-Id: Date: Thu, 4 May 2017 23:46:21 +0200 Cc: Marco van Tol To: freebsd-ipfw@freebsd.org X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 21:46:28 -0000 Hi there, Possibly this questions pops up regularly. I have tried to find the = answer myself and have been unable to so far. My current way to drastically slow-down ssh brute force attacks is by = using the pf feature "max-src-conn-rate" with an argument of 5/60 = meaning only 5 syn packets are allowed per source IP to my ssh port per = minute. The rest get dropped. This works both for IPv4 and IPv6. I = typically don't login more then 5 times per minute to my hosts. I have tried several ways to get the same behaviour using ipfw and = dummynet. But when combining the rules with keep-state I don't get to = the point where I get wire-speed ssh connections for those that make it = while keeping the number of new connections per source IP at a very low = number (a few per minute). Is there an equivalent in ipfw for the pf feature max-src-conn-rate? Thank you very much in advance, please keep cc'ing me as I have not = subscribed to the ipfw list yet. Thanks! Marco van Tol= From owner-freebsd-ipfw@freebsd.org Fri May 5 05:52:23 2017 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 436ABD5D13D for ; Fri, 5 May 2017 05:52:23 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B8C49D18 for ; Fri, 5 May 2017 05:52:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id v455Ufbd024248; Fri, 5 May 2017 15:30:41 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 5 May 2017 15:30:41 +1000 (EST) From: Ian Smith To: Marco van Tol cc: freebsd-ipfw@freebsd.org Subject: Re: equivalent for pf's max-src-conn-rate in ipfw In-Reply-To: Message-ID: <20170505150345.X34672@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 05:52:23 -0000 On Thu, 4 May 2017 23:46:21 +0200, Marco van Tol wrote: > Possibly this questions pops up regularly. I have tried to find the > answer myself and have been unable to so far. > > My current way to drastically slow-down ssh brute force attacks is by > using the pf feature "max-src-conn-rate" with an argument of 5/60 > meaning only 5 syn packets are allowed per source IP to my ssh port > per minute. The rest get dropped. This works both for IPv4 and > IPv6. I typically don't login more then 5 times per minute to my > hosts. > > I have tried several ways to get the same behaviour using ipfw and > dummynet. But when combining the rules with keep-state I don't get > to the point where I get wire-speed ssh connections for those that > make it while keeping the number of new connections per source IP at > a very low number (a few per minute). > > Is there an equivalent in ipfw for the pf feature max-src-conn-rate? No, and dummynet won't help to accomplish connection rate limiting. I've used inetd(8) (aka TCPwrappers) for limiting both ftp and pop3 connections to good effect. Sendmail fortunately includes rate-limiting configuration internally. An example inetd.conf entry for pop3: pop3 stream tcp nowait/7/4 root /usr/local/libexec/qpopper qpopper -s -T 120 limiting connections to 7 concurrent, maximum 4 per minute. Logging as: May 26 23:58:42 sola inetd[3497]: pop3 from 58.185.139.68 exceeded counts/min (limit 4/min) May 27 00:00:24 sola inetd[3497]: pop3 from 58.185.139.68 exceeded counts/min (limit 4/min) May 27 00:01:57 sola inetd[3497]: pop3 from 58.185.139.68 exceeded counts/min (limit 4/min) I haven't used it with sshd myself; instead I use a table of permissable addresses, but that's no use if you need connections from random IPs. > Thank you very much in advance, please keep cc'ing me as I have not > subscribed to the ipfw list yet. cheers, Ian From owner-freebsd-ipfw@freebsd.org Fri May 5 08:25:01 2017 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 B9CAAD5E94C for ; Fri, 5 May 2017 08:25:01 +0000 (UTC) (envelope-from sd@mostnet.ru) Received: from mail.rlan.ru (mail.rlan.ru [213.234.25.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6EA32AD9 for ; Fri, 5 May 2017 08:25:00 +0000 (UTC) (envelope-from sd@mostnet.ru) Subject: Re: equivalent for pf's max-src-conn-rate in ipfw To: Marco van Tol , freebsd-ipfw@freebsd.org References: From: Dmitry Selivanov Message-ID: Date: Fri, 5 May 2017 10:51:38 +0300 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:45.0) Gecko/20100101 Thunderbird/45.8.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.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 08:25:01 -0000 you can try using "limit src-addr" keyword and maybe tune net.inet.ip.fw.dyn_syn_lifetime. See "Examples/DYNAMIC RULES" section at ipfw(8). 05.05.2017 0:46, Marco van Tol пишет: > Hi there, > > Possibly this questions pops up regularly. I have tried to find the answer myself and have been unable to so far. > > My current way to drastically slow-down ssh brute force attacks is by using the pf feature "max-src-conn-rate" with an argument of 5/60 meaning only 5 syn packets are allowed per source IP to my ssh port per minute. The rest get dropped. This works both for IPv4 and IPv6. I typically don't login more then 5 times per minute to my hosts. > > I have tried several ways to get the same behaviour using ipfw and dummynet. But when combining the rules with keep-state I don't get to the point where I get wire-speed ssh connections for those that make it while keeping the number of new connections per source IP at a very low number (a few per minute). > > Is there an equivalent in ipfw for the pf feature max-src-conn-rate? > > Thank you very much in advance, please keep cc'ing me as I have not subscribed to the ipfw list yet. From owner-freebsd-ipfw@freebsd.org Fri May 5 19:27:21 2017 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 6F13BD5F2E1 for ; Fri, 5 May 2017 19:27:21 +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 56BB1FD8 for ; Fri, 5 May 2017 19:27:20 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (58-7-94-137.dyn.iinet.net.au [58.7.94.137]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v45JR9OJ096783 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 5 May 2017 12:27:13 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Question that has dogged me for a while. To: Karl Denninger , freebsd-ipfw@freebsd.org References: <201705041719.v44HJBgF005292@pdx.rh.CN85.dnsmgr.net> From: Julian Elischer Message-ID: <0693848c-ea52-28e0-118e-d6c4221b5843@freebsd.org> Date: Sat, 6 May 2017 03:27:04 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 19:27:21 -0000 On 5/5/17 2:06 am, Karl Denninger wrote: > On 5/4/2017 12:12, Rodney W. Grimes wrote: >>> Consider the following network configuration. >>> >>> >>> Internet ------- Gateway/Firewall ---------- Inside network (including a >>> web host) >>> 70.16.10.1/28 192.168.0.0/24 >>> >>> The address of the outside is FICTIONAL, by the way. >>> >>> For policy reasons I do NOT want the gateway machine to actually have >>> the host on it. There may be a number of things running on there but >>> for the instant moment let's assume a standard pedestrian web host on >>> port 80. >>> >>> I have DNS pointing at "webhost.domain" @ 70.16.10.1. >>> >>> I have NAT on the gateway (NAT internal to the kernel), and a "hole >>> punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as >>> pat of the nat configuration statement. >>> >>> This works fine for anyone on the outside. HOWEVER, anyone on the >>> INTERNAL network cannot see the host. >>> >>> My NAT configuration looks like this: >>> >>> # >>> # Now divert all inbound packets that should go through NAT. Since this >>> is NAT >>> # it can only match a packet that previously was NATted on the way out. >>> # >>> ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} >>> # >>> # Check stateful rules; we want to go there directly if there is a match >>> # >>> ${fwcmd} add 7000 check-state >>> # >>> # Now pick up all *outbound* packets that originated from an inside address >>> # and put them through NAT. We then have >>> # a packet with a local source address and we can allow it to be sent. >>> # Therefore, if the packet is outbound let it pass and be done with it. >>> # >>> ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif} >>>>> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} >>> ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit >>> ${oif} >>> ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} >>> >>> Without the ">>" line I get nothing; the packets get to the gateway and >>> disappear. >>> >>> With the ">>" line I DO get the packets re-emitted on the internal >>> interface HOWEVER there is no translation to the internal interface IP >>> on the gateway box. So what I see on the internal box is this: >>> >>> 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags >>> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale >>> 8,nop,nop,sackOK], length 0 >>> 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags >>> [S.], seq 3088872007, ack 292171179, win 65535, options [mss >>> 1460,nop,wscale 6,sackOK,eol], length 0 >>> >>> Which won't work because the internal box got and sent this: >> What is the NAT command running at instance 100? >> Does it have an -alias_address of inside IP of router? >> Are you tryint to use the same Nat instance to do both >> the global internet acess translation and this special >> inside loop back translation? If so that usually can >> not be made to work. > Aha. That's probably the problem -- I need a second instance. > > Here's the entire salient section: > > > # Set up the NAT configuration; there are multiple entries that have to > be here > # because we redirect a bunch of ports around so we can see things from the > # outside -- specifically, webcams and the HomeDaemon server. > # > ${fwcmd} nat 100 config ip ${oip} log same_ports reset > redirect_port tcp.... (whole bunch of stuff) > > # > # Stop spoofing > # > ${fwcmd} add 2010 deny log all from ${inet} to any not ipsec in > via ${oif} > ${fwcmd} add 2020 deny log all from ${onet} to any in via ${iif} > if [ -n "$inet6" ]; then > ${fwcmd} add 2040 deny all from ${inet6} to any in via > ${oif6} > if [ -n "$onet6" ]; then > ${fwcmd} add 2050 deny log all from ${onet6} to > any in \ > via ${iif6} > fi > fi > > ${fwcmd} add 3000 deny log all from ${onet} to any recv ${iif} > > # > # This table is a list of denied addresses that tried to attack us. Updated > # by sshguard. Anything coming inbound from the outside is blocked. We > also > # block anything on the "screw you" lists (two) > # > ${fwcmd} add 4000 deny log all from table\(22\) to any recv ${oif} > ${fwcmd} add 4010 deny all from any to ${foscam} > ${fwcmd} add 4020 deny log all from ${china} to any via ${oif} > # > # Anything related to RFC1918 or the Manning range that comes in on > # the external interface (shouldn't happen) gets tossed immediately, EXCEPT > # for RFC1918 stuff coming in via IPSEC. That we must pass or our IPSEC > # gateway will not work. > # > ${fwcmd} add 5000 deny log all from ${rfc1918} to any not ipsec > recv ${oif} > ${fwcmd} add 5010 deny log all from ${manning} to any recv ${oif} > > # > # Now divert all inbound packets that should go through NAT. Since this > is NAT > # it can only match a packet that previously was NATted on the way out. > # > ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} > # > # Check stateful rules; we want to go there directly if there is a match > # > ${fwcmd} add 7000 check-state > # > # Now pick up all *outbound* packets that originated from an inside address > # (including IPSEC tunneled stuff) and put them through NAT. We $then have > # a packet with a local source address and we can allow it to be sent. > # Therefore, if the packet is outbound let it pass and be done with it. > # > ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif} > ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} > ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit > ${oif} > ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} > > From the above I assume I need to direct 8001 through a nat 200, and > define that as "twist anything that comes through there to be aliased > from the INTERNAL IP address", yes? > > So I changed the above to be this: > > ${fwcmd} add 8000 nat 200 ip4 from 192.168.0.0/16 to ${oip} > ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif} > > So the first one would catch any inside packet that was headed to the > outside IP before the other gets ahold of it. > > And added: > > ipfw nat 200 config ip ${iip} same_ports reset > > Up above for the second NAT channel; "iip" is the gateway's internal IP > address. > > But that winds up doing nothing; I get no packets back out on the inside > interface at all (just as if the "200" nat stuff was not there at all) > > > >>> 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S], >>> seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], >>> length 0 >>> 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S], >>> seq 2666765817, win 8192, options [mss 1460,nop,wscale >>> 8,nop,nop,sackOK], length 0 >>>>> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags >>> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale >>> 8,nop,nop,sackOK], length 0 >>>>> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags >>> [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale >>> 8,nop,nop,sackOK], length 0 >>> >>> But since the gateway emitted the packet back on the wire *without* >>> remapping the source address (to itself) it doesn't match on the client >>> box 'cause there's no way back for it. >> Yep. >> >>> There has to be a solution to this somewhere and I'm obviously missing >>> it..... :) >>> >>> -- >>> Karl Denninger >>> karl@denninger.net >>> /The Market Ticker/ >>> /[S/MIME encrypted email preferred]/ >> This is the classical "Loopback Nat Problem" of accessing machines >> behind a NAT device that does not do the proper NATTing and >> routing of these packets. Many small consumer routers got this >> wrong for years, just like most ipfw code I have seen. >> >> Most of the consumber devices have been fixed. The trickery is >> you need to NAT packets coming from the inside destined for the >> outside IP into the internal IP. That internal box MUST route >> back via the NAT device, so the NATTED addresses for these >> packets must be the inside IP of the router. >> >> Your code looks to get this mostly right, but I think you have >> missed something someplace. I dont use kernel nat, and it looks >> like you do so you well have to adjust these a little. >> >> inside_ip_router="192.168.10.40" >> outside_ip_router="70.16.10.1" >> inside_ip_webserver="192.168.10.100" >> >> #natd-vmxZ.conf should just be an empty file for this type of nat >> /sbin/natd -f /etc/firewall/natd-vmxZ.conf -port 8888 -alias_address ${192.168.10.40} >> >> Something like >> # This takes inside traffic to outside port 80 address and >> # remaps it to inside IP of router to send to web server >> ${fwcmd} add X divert 8888 tcp from 192.168.0.0/24 to ${outside_ip_router} port 80 >> # This translates the returning packets >> ${fwcmd} add X divert 8888 tcp from 192.168.0.0/24 port 80 to ${inside_ip_router} >> I'd use ipfw fwd on the internal interface of the firewall to forward the packet to the inside host, and assuming the host is a freebsd machine use another ipfw fwd to localhost to 'capture' it locally. the packets from hte internal client to the internal server would go via the router but the return packets would go direct. sort of: on the firewall: ipfw add xxx fwd $WEBSERVER tcp from any to $EXTERNAL_IP 80,443 in recv $INSIDE_INTERFACE on hte web server, same rule.. ipfw add xxx fwd $WEBSERVER tcp from any to $EXTERNAL_IP 80,433 in recv $INSIDE_INTERFACE internal packets will get redirected to the web server which will process them directly using the transparent proxy code. You may need to make sure you have the right options set in your kernel to support this. so: packet to OUTSIDE:80 leaves client packet hits firewall which sends it completely unmodified to server, which openes an "illegal" socket using the firewall's address, Return packets leave the server saying they have come from the firewall address, but addressed to the internal client address and go there directly. From owner-freebsd-ipfw@freebsd.org Fri May 5 19:33:45 2017 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 15982D5F4EB for ; Fri, 5 May 2017 19:33:45 +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 DB9551456 for ; Fri, 5 May 2017 19:33:44 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (58-7-94-137.dyn.iinet.net.au [58.7.94.137]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v45JXaIw096813 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 5 May 2017 12:33:39 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Question that has dogged me for a while. To: "Dr. Rolf Jansen" , Karl Denninger References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> Cc: freebsd-ipfw@freebsd.org From: Julian Elischer Message-ID: <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> Date: Sat, 6 May 2017 03:33:30 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 19:33:45 -0000 On 5/5/17 1:48 am, Dr. Rolf Jansen wrote: > Resolving this with ipfw/NAT may easily become quite complicated, if not impossible if you want to run a stateful nat'ting firewall, which is usually the better choice. > > IMHO a DNS based solution is much more effective. > > On my gateway I have running the caching DNS resolver Unbound. Now let's assume, the second level domain name in question is example.com, and your web server would be accessed by www.example.com, while other services, e.g. mail are served from other sites on the internet. I believe this is a much cleaner solution thanusing double NAT. (see also my solution for if the server is also freebsd) even though we have a nice set of new IPFW capabilities that can do this, I still think double nat is an over complication of the system. > > In unbound.conf you would place two additional lines before any forwarding directive: > > local-zone: "example.com" transparent > local-data: "www.example.com" A 192.168.1.1 > > All the clients on the LAN should use the DNS service on the gateway. In the first place Unbound does higher level DNS lookups locally, however, the transparent attribute lets it fall through to its normal recursive or forwarding behaviour in case a given domain could not be resolved locally. For example, the query of www.example.com would return 192.168.1.1 and the query for mail.example.com would be passed either to the forwarder or resolved recursively from the internet. > > By this way, local clients would directly access your web server from the inside, no NAT is needed. > > IMHO, a DNS server on the gateway got more advantages. It can be used to block access to fraudulent or otherwise useless services on the internet for the whole LAN. > > Best regards > > Rolf > > > Am 04.05.2017 um 13:22 schrieb Karl Denninger : > >> Consider the following network configuration. >> >> >> Internet ------- Gateway/Firewall ---------- Inside network (including a >> web host) >> 70.16.10.1/28 192.168.0.0/24 >> >> The address of the outside is FICTIONAL, by the way. >> >> For policy reasons I do NOT want the gateway machine to actually have >> the host on it. There may be a number of things running on there but >> for the instant moment let's assume a standard pedestrian web host on >> port 80. >> >> I have DNS pointing at "webhost.domain" @ 70.16.10.1. >> >> I have NAT on the gateway (NAT internal to the kernel), and a "hole >> punch" in there with redirect_port tcp 192.168.1.1:80 70.16.10.1:80 as >> pat of the nat configuration statement. >> >> This works fine for anyone on the outside. HOWEVER, anyone on the >> INTERNAL network cannot see the host. >> >> My NAT configuration looks like this: >> >> # >> # Now divert all inbound packets that should go through NAT. Since this >> is NAT >> # it can only match a packet that previously was NATted on the way out. >> # >> ${fwcmd} add 6000 nat 100 ip4 from any to me recv ${oif} >> # >> # Check stateful rules; we want to go there directly if there is a match >> # >> ${fwcmd} add 7000 check-state >> # >> # Now pick up all *outbound* packets that originated from an inside address >> # and put them through NAT. We then have >> # a packet with a local source address and we can allow it to be sent. >> # Therefore, if the packet is outbound let it pass and be done with it. >> # >> ${fwcmd} add 8000 nat 100 ip4 from 192.168.0.0/16 to any xmit ${oif} >>>> ${fwcmd} add 8001 nat 100 ip4 from 192.168.0.0/16 to ${oip} >> ${fwcmd} add 8009 deny log ip4 from 192.168.0.0/16 to any xmit >> ${oif} >> ${fwcmd} add 8010 pass ip4 from ${onet} to any xmit ${oif} >> >> Without the ">>" line I get nothing; the packets get to the gateway and >> disappear. >> >> With the ">>" line I DO get the packets re-emitted on the internal >> interface HOWEVER there is no translation to the internal interface IP >> on the gateway box. So what I see on the internal box is this: >> >> 11:19:16.369634 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags >> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale >> 8,nop,nop,sackOK], length 0 >> 11:19:16.369662 IP 192.168.10.100.11443 > 192.168.10.40.60924: Flags >> [S.], seq 3088872007, ack 292171179, win 65535, options [mss >> 1460,nop,wscale 6,sackOK,eol], length 0 >> >> Which won't work because the internal box got and sent this: >> >> 11:19:16.369337 IP 192.168.10.40.60924 > 70.169.168.7.11443: Flags [S], >> seq 292171178, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], >> length 0 >> 11:19:16.369433 IP 192.168.10.40.60925 > 70.169.168.7.11443: Flags [S], >> seq 2666765817, win 8192, options [mss 1460,nop,wscale >> 8,nop,nop,sackOK], length 0 >>>> 11:19:16.369502 IP 192.168.10.40.60924 > 192.168.10.100.11443: Flags >> [S], seq 292171178, win 8192, options [mss 1460,nop,wscale >> 8,nop,nop,sackOK], length 0 >>>> 11:19:16.369511 IP 192.168.10.40.60925 > 192.168.10.100.11443: Flags >> [S], seq 2666765817, win 8192, options [mss 1460,nop,wscale >> 8,nop,nop,sackOK], length 0 >> >> But since the gateway emitted the packet back on the wire *without* >> remapping the source address (to itself) it doesn't match on the client >> box 'cause there's no way back for it. >> >> There has to be a solution to this somewhere and I'm obviously missing >> it..... :) >> >> -- >> Karl Denninger >> karl@denninger.net >> /The Market Ticker/ >> /[S/MIME encrypted email preferred]/ > _______________________________________________ > 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 Fri May 5 23:53:46 2017 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 6FB88D5F873 for ; Fri, 5 May 2017 23:53:46 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 297A21B2D for ; Fri, 5 May 2017 23:53:45 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.10.40] (Karl-Desktop.Denninger.net [192.168.10.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 25A2F36AD9 for ; Fri, 5 May 2017 18:53:39 -0500 (CDT) Subject: Re: Question that has dogged me for a while. To: freebsd-ipfw@freebsd.org References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> From: Karl Denninger Message-ID: <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> Date: Fri, 5 May 2017 18:53:37 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000802060008000209050604" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 23:53:46 -0000 This is a cryptographically signed message in MIME format. --------------ms000802060008000209050604 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/5/2017 14:33, Julian Elischer wrote: > On 5/5/17 1:48 am, Dr. Rolf Jansen wrote: >> Resolving this with ipfw/NAT may easily become quite complicated, if >> not impossible if you want to run a stateful nat'ting firewall, which >> is usually the better choice. >> >> IMHO a DNS based solution is much more effective. >> >> On my gateway I have running the caching DNS resolver Unbound. Now >> let's assume, the second level domain name in question is >> example.com, and your web server would be accessed by >> www.example.com, while other services, e.g. mail are served from >> other sites on the internet. > > I believe this is a much cleaner solution thanusing double NAT. > (see also my solution for if the server is also freebsd) > even though we have a nice set of new IPFW capabilities that can do > this, I still think double nat is an over complication of the system. > Well, the DNS answer is one that works IF you control the zone in question every time. I'm loathe to stick "illegal" (e.g. bad IP number) packets on a network in any event, so while yeah, that'll work I'd rather not. The "set up a fake forward" zone thing works too, but it shouldn't have t= o. This /should /work on a generalized basis but doesn't (ue1 is on the public address 70.169.168.7, ue0 on private address 192.168.10.200, the host being "twisted to/hole punched" is on 192.168.10.100: # Set up the NAT configuration # ${fwcmd} nat 100 config if ue1 log same_ports reset redirect_port tcp 192.168.10.100:2552 2552 ${fwcmd} nat 200 config ip 192.168.10.200 log same_ports reset =2E... 06000 0 0 nat 200 ip4 from 192.168.0.0/16 2552 to 192.168.10.200= 06010 1521 726601 nat 100 ip4 from any to me recv ue1 07000 0 0 check-state :default 08000 6 312 nat 200 ip4 from 192.168.0.0/16 to 70.169.168.7 08001 0 0 count log ip4 from 192.168.10.200 to any dst-port 2552= 08002 2125 2408339 nat 100 ip4 from 192.168.0.0/16 to any xmit ue1 08009 0 0 deny log ip4 from 192.168.0.0/16 to any xmit ue1 A "telnet 70.169.168.7 2552" from outside works perfectly well. But the second NAT should cause a "telnet 70.169.168.7 2552" from an internet-network host to work also. It doesn't. 8000 gets the packet (a telnet attempt from inside to port 2552) and allegedly is supposed to NAT it. It does not. The following rule, which is where execution should continue after it NATs it, should match but no packet ever comes back into the stack -- nor does it show up on the wire (tcpdump fails to show it.) I have verbose logging on in sysctl and none of the deny lines in the remainder of the ipfw config file trap it either. The *other* NAT instance on the same box (to translate other things on the same network out to the Internet at large and perform the hole punch) works perfectly well. This looks like a bug in the code -- unless there's a requirement that a packet in the kernel is marked to be enqueued for emission on an actual physical interface before it will translate (e.g. a "forward" NAT has to be associated with an "xmit ...." clause in order to work) in which case it's impossible to make in-kernel NAT work for the "double twist" case since the packet never leaves the box until it goes through the hole-punch in the first NAT statement (which it *should* do in 8002, right?) Is that a bug (ought to PR it), a "feature" (e.g. design choice and thus "working as intended") or do I (still) have it configured incorrectly? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000802060008000209050604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MDUyMzUzMzdaME8GCSqGSIb3DQEJBDFCBEDPnrYJ XxjATfOyATbbvsh2M/B4MgrRiPeeNhA9jLehrbZhQWEgTBxnQ9d735GHjsbnOpLif98eXHkz BvKqm8vQMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAYpiVEwCrxGJV 06IoaQ2WaNHJLITbOvk5I7KQ+s/+pirLItga5RyU7OfCPyf/Ljs/feqnWTewf79jIniRHRr7 4ufv5hq9UdiolaKIMtgsyMu4Pton4mpTER2/fu9dumzlvD8I/MY6S9xzM/bRaqLA4pghsXC2 M8pHZcUeK4WawHxcqsWQ0sS95RwS2QL2oeZSx1Gs7KFzdQiJkBugasqz236PBcQu+wt1iQR4 twdMmG6/4REAQY+70V2zTlgeaBeHkwxkbwX2ybF4b3ReAnDZinRhVUobQxglKx+GdBxrl1Ql azy0BkOC/c4vBfMpYBu14Pdsngv8U6E+D+Ru1s8j5FuhBk54o9w2aHE9TjiPtc1fao+v+bsc 3rbytG4W7MOYKpIC3h5kqT496tbXgzSD+T7djcHG8clRvDv96dY5iR94dysy/eR0hUi9PLp6 meKma6zReYe1E1P3sNnuymvwRrYZSnLXO9qIT3oINlftRmRCpUhllIChuBdnJk2NWjvYKNqC Q+IGJya8etuZooZs+2RET7VcMiTmKPd/BTsWa37AlLc5id2AbBlEzT+F0r3LYp4xl7mMkFUR Q+F4SR9VMv3NT953yyOny+un32rOnt0kNbSGmG/lWjv21JIr+6DXy4mnEuv2Iyy6GNAIstHq E28TMhEzUKMNa/CottY+WlAAAAAAAAA= --------------ms000802060008000209050604-- From owner-freebsd-ipfw@freebsd.org Fri May 5 23:55:20 2017 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 D9249D5F8F9 for ; Fri, 5 May 2017 23:55:20 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 929D51BEE for ; Fri, 5 May 2017 23:55:20 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.10.40] (Karl-Desktop.Denninger.net [192.168.10.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 9945636AE8 for ; Fri, 5 May 2017 18:55:19 -0500 (CDT) Subject: Re: Question that has dogged me for a while. To: freebsd-ipfw@freebsd.org References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> From: Karl Denninger Message-ID: <4d6e0530-3a43-a9fe-54cb-8c8ebc7fadbc@denninger.net> Date: Fri, 5 May 2017 18:55:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080607050703050405080409" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 23:55:20 -0000 This is a cryptographically signed message in MIME format. --------------ms080607050703050405080409 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/5/2017 18:53, Karl Denninger wrote: > A "telnet 70.169.168.7 2552" from outside works perfectly well. But th= e > second NAT should cause a "telnet 70.169.168.7 2552" from an > internet-network host to work also. It doesn't. s/internet-network/inside-network/ :-) --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080607050703050405080409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MDUyMzU1MTdaME8GCSqGSIb3DQEJBDFCBEAus728 olylWiooNsn7cotN3Lq3dKUKjc/rQZGXxFG8dpmpRxjlh1Gbdv4A/HOwBKEKVVbLFaYsoyTb JPGoeOA+MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAqToqn/45+gu4 e4XMlcLtjShRMrCs5N91BK1s/WuLgUo8S+5Ln1EFmtnzwJO+yaqOwgbdrCZyAK+fXXLzU9AR W0MzbUfF6vK8/gApSmO4i3VethuABeUpzXBmLL2jNYZ54DQ6BWJDZ4jIAaFEt6qspMrCZfAV couT56yMnqMQ3ge6xqPo0cvoJxz0mFAxVDXYd8Dkspy+9KorrRW0zvlWuIFW1qkxXP4tn/o3 +AfUQzE3rGw3OZCckelCIGtKYOfWK780phpwZs2mP2arRFFiNgCuHU3W5QqNOMWeV8Uyl5D6 fIp1w9+kyOI7PQ4mLJWPHIkGVxsasUTSNugjGiCiJ8/dmb8jsCUFxeoJgmnDqQTCxs/zlI4g s0+vAm/DTr8RzWKfsN8WIfvL+/4U7WnwKaDRsBCIM01RS389Qw0JgLF2741hWjUReH5wksD9 1CPjeyCuktZp6cUcNI9ZmS4s0x57GXvOePo5Vb4zYEFej6HxLdq8QI3Vk3oYaz8z19eCO2b/ irlXdFo4fgNFPDxB/uRA1NLbnlkse45md7M9iHu01P8BD0uZGU9YbLCUVUmqOmwKPeC8665E ltqiBajAPHofDLXyGKsPYs1w8x6W1Nnc9Q6gb44iuZD4Ge316tJbEo0BMxNn4TgxHUCrQyfe rzVfnoHx9xoEMnR0/8It9KcAAAAAAAA= --------------ms080607050703050405080409-- From owner-freebsd-ipfw@freebsd.org Sat May 6 00:08:40 2017 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 A2CAED60000 for ; Sat, 6 May 2017 00:08:40 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4098C323 for ; Sat, 6 May 2017 00:08:39 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1494029316; l=1425; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=y0QTZdj4jmjus+cYBbzf10XeUxI/q3yyf3mSjBZsF/k=; b=GdMb2FeM/RykJSeGPGNPNYLs6HksQUVnbsuBg1qIqJ+/Bh90QMpTpjsR2JJ2krbBlh oTlZWfv6zT5THAOvAg+iAVeQnmfje0cXQRCzmEuJHrBL61tzDCqvfGZBf7jxJzKlqQaJ V1jiOYoEVSnS8Hceft6zj3XValb7PWuYSjQHw= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGhIn99HqS2s= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02aec2.virtua.com.br [187.2.174.194]) by smtp.strato.de (RZmta 40.6 DYNA|AUTH) with ESMTPSA id L0a6f6t4608YSbs (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 6 May 2017 02:08:34 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 72FFB7506DB2; Fri, 5 May 2017 21:08:31 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Question that has dogged me for a while. From: "Dr. Rolf Jansen" In-Reply-To: <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> Date: Fri, 5 May 2017 21:08:30 -0300 Cc: freebsd-ipfw@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <11FA2DA2-85AB-4E70-B9B5-CDADAAA3C295@obsigna.com> References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 00:08:40 -0000 Am 05.05.2017 um 20:53 schrieb Karl Denninger : > On 5/5/2017 14:33, Julian Elischer wrote: >> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote: >>> Resolving this with ipfw/NAT may easily become quite complicated, if >>> not impossible if you want to run a stateful nat'ting firewall, = which >>> is usually the better choice. >>>=20 >>> IMHO a DNS based solution is much more effective. >>>=20 >>> On my gateway I have running the caching DNS resolver Unbound. Now >>> let's assume, the second level domain name in question is >>> example.com, and your web server would be accessed by >>> www.example.com, while other services, e.g. mail are served from >>> other sites on the internet. >>=20 >> I believe this is a much cleaner solution thanusing double NAT. >> (see also my solution for if the server is also freebsd) >> even though we have a nice set of new IPFW capabilities that can do >> this, I still think double nat is an over complication of the system. >>=20 > Well, the DNS answer is one that works IF you control the zone in > question every time. ... I do not understand "control the zone ... every time". I set up my transparent zones 5 years ago and never touched it again, = and I don't see any "illegal" packets on my network caused by this = either. I understand that you actually didn't grasp the transparent zone = technic. Happy double nat'ting :-D From owner-freebsd-ipfw@freebsd.org Sat May 6 00:14:49 2017 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 75E8FD5D30B for ; Sat, 6 May 2017 00:14:49 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 2FF2B981 for ; Sat, 6 May 2017 00:14:48 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.10.40] (Karl-Desktop.Denninger.net [192.168.10.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 4B81D36B2F for ; Fri, 5 May 2017 19:14:48 -0500 (CDT) Subject: Re: Question that has dogged me for a while. To: freebsd-ipfw@freebsd.org References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> <11FA2DA2-85AB-4E70-B9B5-CDADAAA3C295@obsigna.com> From: Karl Denninger Message-ID: <29c05b94-be21-2090-03c5-f3905d3e2e06@denninger.net> Date: Fri, 5 May 2017 19:14:46 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <11FA2DA2-85AB-4E70-B9B5-CDADAAA3C295@obsigna.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050102010609070601080905" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 00:14:49 -0000 This is a cryptographically signed message in MIME format. --------------ms050102010609070601080905 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/5/2017 19:08, Dr. Rolf Jansen wrote: > Am 05.05.2017 um 20:53 schrieb Karl Denninger : >> On 5/5/2017 14:33, Julian Elischer wrote: >>> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote: >>>> Resolving this with ipfw/NAT may easily become quite complicated, if= >>>> not impossible if you want to run a stateful nat'ting firewall, whic= h >>>> is usually the better choice. >>>> >>>> IMHO a DNS based solution is much more effective. >>>> >>>> On my gateway I have running the caching DNS resolver Unbound. Now >>>> let's assume, the second level domain name in question is >>>> example.com, and your web server would be accessed by >>>> www.example.com, while other services, e.g. mail are served from >>>> other sites on the internet. >>> I believe this is a much cleaner solution thanusing double NAT. >>> (see also my solution for if the server is also freebsd) >>> even though we have a nice set of new IPFW capabilities that can do >>> this, I still think double nat is an over complication of the system.= >>> >> Well, the DNS answer is one that works IF you control the zone in >> question every time. ... > I do not understand "control the zone ... every time". > > I set up my transparent zones 5 years ago and never touched it again, a= nd I don't see any "illegal" packets on my network caused by this either.= > > I understand that you actually didn't grasp the transparent zone techni= c. > > Happy double nat'ting :-D On the contrary I do understand it (and how to do it), along with how to throw "off-network" packets at the other host. Both ways work (unbound is arguably simpler than BIND, but it'll work in both cases) but the point is that you then must keep two things in sync rather than do one thing in one place. If double-nat'ing isn't supposed to work with in-kernel ipfw nat because the first nat never leaves an interface then it is what it is, but if it IS supposed to work then is not this misfeature a roach on the floor that perhaps ought to get squashed? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050102010609070601080905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MDYwMDE0NDZaME8GCSqGSIb3DQEJBDFCBEDFIQgS EEILaOIy3MinV2Wcs/2iIrqz+HLPKfsNwgkbIYVVYmrFJUQHG9C7DMDkl053k1oaQ1Nu2RrV 67Jid6TvMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAqKELDQm1lMZa oK5UFSHnxSBKoe5QQ9dM9fTaefye98LaXS54TrrKHhMGjHMu8yYAMO0APag9ewV2zEIqbpqZ C74GrttNT6V3kslXFFkq7/u34CrATvp/Adlz4w+GD/aNuZCK1JJMi8wZ9It5kLMTyEsmLt4P yJz/4XWkmmbNdd7jTotOSAh5XsJqxnVGuJkJe9ipcxrNfbrw9lNV4E8OMdaQOXC6NXD/aMhM 2TH3aSi1JnoNqGyduZGLRIuFQjH9cxQvpCOLcoMAFW1int9/ZqeEuimSY7MuQp7QVn93kBMY Hjf/EAPCK9SwQELDUsVLYMn/Igp6y4oikBNaL/tVXD1rDx5alYzAdJ53qrz1M2RBew4jOcyG IXU7KGEDZ3NqpAXAVCm9h38PgS+x0XfQLFQTyzRz5vR402+ShqIsc7eu2nvxU8OKqYxOLdEK iad6cwpGTuzqHD1DZ6Hl0CGs5YJnNeGdColLK6qrT9A5Gykk5B+bR7ZkKmLbJpX0JSxoryOW AyUPniHIaJPN6tWdvcpgBWuA8XzUmTvRKgvpmrSEwSgZwgNH7ILud5tHWJPT7mvx3sFLTCtt ICgvNZvJhBs5RTR7VOrX2ZxmgNYW85K3eSyo5VZ3+FrJ5Bb8kynw/ETyOK/rlMGT8tn/4lcj RUJHZxGVXsOKDwOOWamSHvgAAAAAAAA= --------------ms050102010609070601080905-- From owner-freebsd-ipfw@freebsd.org Sat May 6 02:56:53 2017 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 C969CD608F5 for ; Sat, 6 May 2017 02:56:53 +0000 (UTC) (envelope-from rj@obsigna.com) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 66FD97F for ; Sat, 6 May 2017 02:56:53 +0000 (UTC) (envelope-from rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1494039410; l=2058; s=domk; d=obsigna.com; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Subject:Mime-Version:Content-Type; bh=Nqjve4kaEg6ex9Hryp05qaCPG+mXLtCb7/X6hEtKn94=; b=Yo/wPTYHYikf/vOctgOOlKQaQhOcEM+2QWg+5Eva+6LAhISYBSfITjOSklME2RIk0P F9PvTiweY/WvR6hotZrpm7NZMw63QngFVdYdOcHY4vkY98itsulb4iT/Q7II65beaU2m RHPyx6LveZo/8FVlCSpDNQhYy3OGW9DS/SRJo= X-RZG-AUTH: :O2kGeEG7b/pS1EK7WHa0hxqKZr4lnx6UhT0M0o35iAdWtoM07Gt3wQHFGhIn99HqS2s= X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com (bb02aec2.virtua.com.br [187.2.174.194]) by smtp.strato.de (RZmta 40.6 DYNA|AUTH) with ESMTPSA id 4041fft462ulClR (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 6 May 2017 04:56:47 +0200 (CEST) Received: from rolf.projectworld.net (rolf.projectworld.net [192.168.222.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id 9C3D07506DB2; Fri, 5 May 2017 23:56:44 -0300 (BRT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Question that has dogged me for a while. From: "Dr. Rolf Jansen" In-Reply-To: <29c05b94-be21-2090-03c5-f3905d3e2e06@denninger.net> Date: Fri, 5 May 2017 23:56:43 -0300 Cc: freebsd-ipfw@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> <11FA2DA2-85AB-4E70-B9B5-CDADAAA3C295@obsigna.com> <29c05b94-be21-2090-03c5-f3905d3e2e06@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 02:56:53 -0000 Am 05.05.2017 um 21:14 schrieb Karl Denninger : > On 5/5/2017 19:08, Dr. Rolf Jansen wrote: >> Am 05.05.2017 um 20:53 schrieb Karl Denninger : >>> On 5/5/2017 14:33, Julian Elischer wrote: >>>> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote: >>>>> Resolving this with ipfw/NAT may easily become quite complicated, = if >>>>> not impossible if you want to run a stateful nat'ting firewall, = which >>>>> is usually the better choice. >>>>>=20 >>>>> IMHO a DNS based solution is much more effective. >>>>>=20 >>>>> On my gateway I have running the caching DNS resolver Unbound. Now >>>>> let's assume, the second level domain name in question is >>>>> example.com, and your web server would be accessed by >>>>> www.example.com, while other services, e.g. mail are served from >>>>> other sites on the internet. >>>> I believe this is a much cleaner solution thanusing double NAT. >>>> (see also my solution for if the server is also freebsd) >>>> even though we have a nice set of new IPFW capabilities that can do >>>> this, I still think double nat is an over complication of the = system. >>>>=20 >>> Well, the DNS answer is one that works IF you control the zone in >>> question every time. ... >> I do not understand "control the zone ... every time". >>=20 >> I set up my transparent zones 5 years ago and never touched it again, = and I don't see any "illegal" packets on my network caused by this = either. >>=20 >> I understand that you actually didn't grasp the transparent zone = technic. >>=20 >> Happy double nat'ting :-D > On the contrary I do understand it (and how to do it), along with how = to > throw "off-network" packets at the other host. Both ways work = (unbound > is arguably simpler than BIND, but it'll work in both cases) but the > point is that you then must keep two things in sync rather than do one > thing in one place. With BIND you cannot setup a selectively transparent zone. You are = talking about split DNS, and that's a different animal. From owner-freebsd-ipfw@freebsd.org Sat May 6 03:32:33 2017 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 D4E4BD604D8 for ; Sat, 6 May 2017 03:32:33 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id A60ED34F for ; Sat, 6 May 2017 03:32:33 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.10.40] (Karl-Desktop.Denninger.net [192.168.10.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id A78BD36C91 for ; Fri, 5 May 2017 22:32:31 -0500 (CDT) Subject: Re: Question that has dogged me for a while. To: freebsd-ipfw@freebsd.org References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> <11FA2DA2-85AB-4E70-B9B5-CDADAAA3C295@obsigna.com> <29c05b94-be21-2090-03c5-f3905d3e2e06@denninger.net> From: Karl Denninger Message-ID: Date: Fri, 5 May 2017 22:32:29 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms000706050204070202040305" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 03:32:33 -0000 This is a cryptographically signed message in MIME format. --------------ms000706050204070202040305 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/5/2017 21:56, Dr. Rolf Jansen wrote: > Am 05.05.2017 um 21:14 schrieb Karl Denninger : >> On 5/5/2017 19:08, Dr. Rolf Jansen wrote: >>> Am 05.05.2017 um 20:53 schrieb Karl Denninger : >>>> On 5/5/2017 14:33, Julian Elischer wrote: >>>>> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote: >>>>>> Resolving this with ipfw/NAT may easily become quite complicated, = if >>>>>> not impossible if you want to run a stateful nat'ting firewall, wh= ich >>>>>> is usually the better choice. >>>>>> >>>>>> IMHO a DNS based solution is much more effective. >>>>>> >>>>>> On my gateway I have running the caching DNS resolver Unbound. Now= >>>>>> let's assume, the second level domain name in question is >>>>>> example.com, and your web server would be accessed by >>>>>> www.example.com, while other services, e.g. mail are served from >>>>>> other sites on the internet. >>>>> I believe this is a much cleaner solution thanusing double NAT. >>>>> (see also my solution for if the server is also freebsd) >>>>> even though we have a nice set of new IPFW capabilities that can do= >>>>> this, I still think double nat is an over complication of the syste= m. >>>>> >>>> Well, the DNS answer is one that works IF you control the zone in >>>> question every time. ... >>> I do not understand "control the zone ... every time". >>> >>> I set up my transparent zones 5 years ago and never touched it again,= and I don't see any "illegal" packets on my network caused by this eithe= r. >>> >>> I understand that you actually didn't grasp the transparent zone tech= nic. >>> >>> Happy double nat'ting :-D >> On the contrary I do understand it (and how to do it), along with how = to >> throw "off-network" packets at the other host. Both ways work (unboun= d >> is arguably simpler than BIND, but it'll work in both cases) but the >> point is that you then must keep two things in sync rather than do one= >> thing in one place. > With BIND you cannot setup a selectively transparent zone. You are talk= ing about split DNS, and that's a different animal. > Well, sort of you can. Look at "response-policy" in the options section of named.conf.... It does basically the same sort of thing that you can do with unbound; it's been there for a while. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms000706050204070202040305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC BlwwggZYMIIEQKADAgECAgE9MA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND dWRhIFN5c3RlbXMgTExDIENBMB4XDTE2MTIxODE5NDUzNVoXDTIxMTIxNzE5NDUzNVowVzEL MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxGzAZBgNVBAMUEmthcmxAZGVubmluZ2VyLm5ldDCCAiIwDQYJKoZIhvcNAQEBBQADggIP ADCCAgoCggIBAM2N5maxs7NkoY9g5NMxFWll0TYiO7gXrGZTo3q25ZJgNdPMwrntLz/5ewE9 07TEbwJ3ah/Ep9BfZm7JF9vTtE1HkgKtXNKi0pawNGm1Yn26Dz5AbUr1byby6dFtDJr14E07 trzDCtRRvTkOVSBj6PQPal0fAnDtkIYQBVcuMkXkuMCtyfE95pjm8g4K9l7lAcKii3T1/3rE hCc1o2nBnb7EN1/XwBeCDGB+I2SN/ftZDbKQqGAF5q9dUn+iXU7Z/CVSfUWmhVh6cVZA4Ftv TglUqj410OuPx+cUQch3h1kFgsuhQR63HiJc3HbRJllHsV0rihvL1CjeARQkhnA6uY9NLFST p5I/PfzBzW2MSmtN/tGZvmfKKnmtbfUNgkzbIR1K3lsum+yEL71kB93Xtz/4f1demEx5c8TJ RBIniDHjDeLGK1aoBu8nfnvXAvgthFNTWBOEoR49AHEPjC3kZj0l8JQml1Y8bTQD5gtC5txl klO60WV0EufU7Hy9CmynMuFtjiA2v71pm097rXeCdrAKgisdYeEESB+SFrlY65rLiLv4n8o1 PX7DqRfqKkOYIakZ0ug/yHVKcq2EM3RiJxwzls5gT70CoOBlKbrC98O8TA6teON0Jq30M06t NTI2HhvNbJDLbBH+Awf4h1UKB+0ufENwjVvF5Jfz8Ww/FaSDAgMBAAGjgfQwgfEwNwYIKwYB BQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgwCQYD VR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIBDQQf Fh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUpfAI3y+751pp9A0w 6vJHx8RoR/MwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYwFIES a2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBiB6MlugxYJdccD8boZ/u8 d8VxmLkJCtbfyYHRjYdyoABLW5hE3k3xSpYCM9L7vzWyV/UWwDYKi4ZzxHo4g+jG/GQZfKhx v38BQjL2G9xD0Hn2d+cygOq3UPjVYlbbfQoew6JbyCFXrrZ7/0jvRMLAN2+bRC7ynaFUixPH Whnj9JSH7ieYdzak8KN+G2coIC2t2iyfXVKehzi5gdNQ0vJ7+ypbGsRm4gE8Mdo9N/WgFPvZ HPFqR9Dwas7Z+aHwOabpk5r/336SyjOaZsn3MqKJQZL6GqDKusVOCWt+9uFAD8kadg7FetZe atIoD9I+zbp59oVoMnkMDMx7Hi85faU03csusqMGsjSsAzWSI1N8PJytZlchLiykokLKc3OL G87QKlErotlou7cfPX2BbEAH5wmkj9oiqZhxIL/wwAUA+PkiTbEmksKBNompSjUq/6UsR8EA s74gnu17lmijv8mrg2qMlwRirE7qG8pnE8egLtCDxcjd0Of9WMi2NJskn0/ovC7P+J60Napl m3ZIgPJst1piYSE0Zc1FIat4fFphMfK5v4iLblo1tFSlkdx1UNDGdg/U+LaXkNVXlMp8fyPm R80V6cIrCAlEWnBJNxG1UyfbbsvNMCCZBM4faGGsR/hhQOiydlruxhjL6P8J2WV8p11DdeGx KymWoil2s1J5WTGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxv cmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRww GgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5c3Rl bXMgTExDIENBAgE9MA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA1MDYwMzMyMjlaME8GCSqGSIb3DQEJBDFCBEAF0uzo HIpqW6VO76nHRjkAP0MVnniahOLJXeEVK2520MQhAF18eZ/OxA7KLClYcv6e7x0UfSyvRvQE wIRksWCqMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI hvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNVBAgT B0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExM QzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3VkYSBT eXN0ZW1zIExMQyBDQQIBPTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYTAlVT MRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEg U3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG9w0B CQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECAT0wDQYJKoZIhvcNAQEBBQAEggIAoHBemC4Pro+O ZfZE+ph51bWO/JFBR2yXdte5Q/RtywuDrs5L1pXsqRrWBqz4x0Asd1qv8Kkq6txRxaJky5tv fcbA+O2o5Kcrzkq4O0SS+B4N4j7pcGqL8Rm3hV+HElhNvFNJgthxaLcs0ZHFboHRThnB7hjq X97Ri/EsSyYOVIFqALnZUgOd4UnerOsNmZx4I3SAxdI2bZpTi0/WbLc4z9JdQpN0/RUnjw+F h7lWWw7xYgjj9CPXUbuwVkJtWhiFE3eByNuXV6gFndlhe7Gdwv15wt0tXmfkH6q9u/sY4iYT 7ECQPIL3ispz2bfj/AnFQGX+TDe+Wv1X3CHvhGkZuFl1LTDmanqVGnDOfC3CmvwgBCyXHtXP lmNYaHWaCffYWoz9U6Ma0bLx3eFXKooFzc8ZkrBs1Xz3UxRcyQnekiKoICwM5TBA4u6GgUFl XU9h5xdrStskrtxx8xeLMjwCvO3PUwIcUkyiryXZ5gZG38Y5zw7e0Ytvikrt7VIaxoMDsxQM e+5MrEwyoZZmRKAtfAc7v7wW4DIAS4TTFFoLfL8IpC39IcT6ic56Lt2beeeNTXcD7BG0pw8O ylV1FscS3MBZK5gwoPGuYZHa8qwDbd8kG/tRM/Yn9CF8oISqcIO9U5wmWiqDugetrzmK70Sb grhtaC01aqI1fSCmqgF/CQQAAAAAAAA= --------------ms000706050204070202040305-- From owner-freebsd-ipfw@freebsd.org Sat May 6 03:59:57 2017 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 3517ED60028 for ; Sat, 6 May 2017 03:59: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 153141E31 for ; Sat, 6 May 2017 03:59:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (58-7-94-137.dyn.iinet.net.au [58.7.94.137]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v463xnL6098397 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 5 May 2017 20:59:53 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Question that has dogged me for a while. To: freebsd-ipfw@freebsd.org References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> From: Julian Elischer Message-ID: <3dc44501-26c2-7b93-66b3-5a9ffa12a8dd@freebsd.org> Date: Sat, 6 May 2017 11:59:43 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 03:59:57 -0000 On 6/5/17 7:53 am, Karl Denninger wrote: > On 5/5/2017 14:33, Julian Elischer wrote: >> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote: >>> Resolving this with ipfw/NAT may easily become quite complicated, if >>> not impossible if you want to run a stateful nat'ting firewall, which >>> is usually the better choice. >>> >>> IMHO a DNS based solution is much more effective. >>> >>> On my gateway I have running the caching DNS resolver Unbound. Now >>> let's assume, the second level domain name in question is >>> example.com, and your web server would be accessed by >>> www.example.com, while other services, e.g. mail are served from >>> other sites on the internet. >> I believe this is a much cleaner solution thanusing double NAT. >> (see also my solution for if the server is also freebsd) >> even though we have a nice set of new IPFW capabilities that can do >> this, I still think double nat is an over complication of the system. >> > Well, the DNS answer is one that works IF you control the zone in > question every time. I'm loathe to stick "illegal" (e.g. bad IP number) > packets on a network in any event, so while yeah, that'll work I'd > rather not. Interestingly the "bad" IP packets are no different than the packets you are seeing on the network anyhow (with nat). You just deliver them to a different place. Effectively you are turning on the transparent proxy support in the kernel and making the gateway a transparent proxy for your clients. (but only for your own server) for example if your client is 192.168.0.2 and your server is 192.168.0.3 and your external address is 8.8.8.9, Then what you are asking for is a way that your client can make a session where the remote address is 8.8.8.9 and the local address is 192.168.0.2. You are going to generate these packets no matter what you do because they are what you asked to do even if you are NATing. The packets when bounced to the server STILL look like src=192.169.0.2, dest=8.8.8.9 and the server(FreeBSD or Linux with TP support only) will consume them as such. The server will produce a packet that looks like src=8.8.8.9, dest=192.168.0.2. These packets look exactly like the packets that would be returning from the NAT to the client had you used nat. so, overall, you are not introducing any packets onto your network that wouldn't have been there anyhow. They look exactly like the traffic would look between the NAT and the client. The difference is that it is way more efficient, because the return packets take no processing at all. The advantage of setting up a DNS (mostly) forwarding proxy is that what is happening is absolutely visible on the wire. Nothing is pretending to be anything it is not. The nat option on the other hand. (don't get me wrong, I am sure it would work given enough work) is that it just has more moving parts and will make it more complicated to get your firewall correct in other cases. I like ipfw and it's nat, it's just more complicated in some cases. > The "set up a fake forward" zone thing works too, but it shouldn't have to. > > This /should /work on a generalized basis but doesn't (ue1 is on the > public address 70.169.168.7, ue0 on private address 192.168.10.200, the > host being "twisted to/hole punched" is on 192.168.10.100: > > # Set up the NAT configuration > # > ${fwcmd} nat 100 config if ue1 log same_ports reset > redirect_port tcp 192.168.10.100:2552 2552 > ${fwcmd} nat 200 config ip 192.168.10.200 log same_ports reset shouldn't one of these be declared to be a reverse nat? > > .... > 06000 0 0 nat 200 ip4 from 192.168.0.0/16 2552 to 192.168.10.200 > 06010 1521 726601 nat 100 ip4 from any to me recv ue1 > 07000 0 0 check-state :default > > 08000 6 312 nat 200 ip4 from 192.168.0.0/16 to 70.169.168.7 > 08001 0 0 count log ip4 from 192.168.10.200 to any dst-port 2552 > 08002 2125 2408339 nat 100 ip4 from 192.168.0.0/16 to any xmit ue1 > 08009 0 0 deny log ip4 from 192.168.0.0/16 to any xmit ue1 > > A "telnet 70.169.168.7 2552" from outside works perfectly well. But the > second NAT should cause a "telnet 70.169.168.7 2552" from an > internet-network host to work also. It doesn't. > > 8000 gets the packet (a telnet attempt from inside to port 2552) and > allegedly is supposed to NAT it. It does not. The following rule, > which is where execution should continue after it NATs it, should match > but no packet ever comes back into the stack -- nor does it show up on > the wire (tcpdump fails to show it.) I have verbose logging on in > sysctl and none of the deny lines in the remainder of the ipfw config > file trap it either. > > The *other* NAT instance on the same box (to translate other things on > the same network out to the Internet at large and perform the hole > punch) works perfectly well. > > This looks like a bug in the code -- unless there's a requirement that a > packet in the kernel is marked to be enqueued for emission on an actual > physical interface before it will translate (e.g. a "forward" NAT has to > be associated with an "xmit ...." clause in order to work) in which case > it's impossible to make in-kernel NAT work for the "double twist" case > since the packet never leaves the box until it goes through the > hole-punch in the first NAT statement (which it *should* do in 8002, > right?) > > Is that a bug (ought to PR it), a "feature" (e.g. design choice and thus > "working as intended") or do I (still) have it configured incorrectly? > From owner-freebsd-ipfw@freebsd.org Sat May 6 04:11:16 2017 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 09E4AD604C1 for ; Sat, 6 May 2017 04:11:16 +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 E43E2F9C for ; Sat, 6 May 2017 04:11:15 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (58-7-94-137.dyn.iinet.net.au [58.7.94.137]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v464B8QI098453 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 5 May 2017 21:11:12 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Question that has dogged me for a while. To: Karl Denninger , freebsd-ipfw@freebsd.org References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> <11FA2DA2-85AB-4E70-B9B5-CDADAAA3C295@obsigna.com> <29c05b94-be21-2090-03c5-f3905d3e2e06@denninger.net> From: Julian Elischer Message-ID: <06caae0c-2342-71af-0456-342c68b82c2a@freebsd.org> Date: Sat, 6 May 2017 12:11:02 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <29c05b94-be21-2090-03c5-f3905d3e2e06@denninger.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 May 2017 04:11:16 -0000 On 6/5/17 8:14 am, Karl Denninger wrote: > On 5/5/2017 19:08, Dr. Rolf Jansen wrote: >> Am 05.05.2017 um 20:53 schrieb Karl Denninger : >>> On 5/5/2017 14:33, Julian Elischer wrote: >>>> On 5/5/17 1:48 am, Dr. Rolf Jansen wrote: >>>>> Resolving this with ipfw/NAT may easily become quite complicated, if >>>>> not impossible if you want to run a stateful nat'ting firewall, which >>>>> is usually the better choice. >>>>> >>>>> IMHO a DNS based solution is much more effective. >>>>> >>>>> On my gateway I have running the caching DNS resolver Unbound. Now >>>>> let's assume, the second level domain name in question is >>>>> example.com, and your web server would be accessed by >>>>> www.example.com, while other services, e.g. mail are served from >>>>> other sites on the internet. >>>> I believe this is a much cleaner solution thanusing double NAT. >>>> (see also my solution for if the server is also freebsd) >>>> even though we have a nice set of new IPFW capabilities that can do >>>> this, I still think double nat is an over complication of the system. >>>> >>> Well, the DNS answer is one that works IF you control the zone in >>> question every time. ... >> I do not understand "control the zone ... every time". >> >> I set up my transparent zones 5 years ago and never touched it again, and I don't see any "illegal" packets on my network caused by this either. >> >> I understand that you actually didn't grasp the transparent zone technic. >> >> Happy double nat'ting :-D > On the contrary I do understand it (and how to do it), along with how to > throw "off-network" packets at the other host. Both ways work (unbound > is arguably simpler than BIND, but it'll work in both cases) but the > point is that you then must keep two things in sync rather than do one > thing in one place. > > If double-nat'ing isn't supposed to work with in-kernel ipfw nat because > the first nat never leaves an interface then it is what it is, but if it > IS supposed to work then is not this misfeature a roach on the floor > that perhaps ought to get squashed? I think the problem MAY be that the return packets from the internal (reverse) nat are taking the same path as the original packets. (confusing libalias) You are saying that the packets coming from 192.168.x.x are CLIENT packets and then you expect the packets from the server to be treated the differently, even tough they are the same. I think the NAT doesn't know which way to apply them as. >