Date: Thu, 4 May 2017 13:06:16 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-ipfw@freebsd.org Subject: Re: Question that has dogged me for a while. Message-ID: <ecb5d259-876d-bb4b-035f-ffd3f7032885@denninger.net> In-Reply-To: <201705041719.v44HJBgF005292@pdx.rh.CN85.dnsmgr.net> References: <201705041719.v44HJBgF005292@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mailto: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 <mailto: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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ecb5d259-876d-bb4b-035f-ffd3f7032885>