Date: Fri, 5 May 2017 18:53:37 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-ipfw@freebsd.org Subject: Re: Question that has dogged me for a while. Message-ID: <52f73440-c1f0-7f08-0f8e-f912436ee686@denninger.net> In-Reply-To: <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org> References: <26ccc7eb-bed3-680c-2c86-2a83684299fb@denninger.net> <08BB50FC-510C-4FCF-8443-0BB16EA2D032@obsigna.com> <6f304edb-ad2e-cb2a-eea9-7b6bbe0be760@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mailto: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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52f73440-c1f0-7f08-0f8e-f912436ee686>