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--