Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 May 2017 14:17:52 -0500
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-ipfw@freebsd.org
Subject:   Re: Question that has dogged me for a while.
Message-ID:  <5c22b7f9-f120-5912-21c8-1de481b2f3c7@denninger.net>
In-Reply-To: <201705041847.v44IlOgn005602@pdx.rh.CN85.dnsmgr.net>
References:  <201705041847.v44IlOgn005602@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.

--------------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<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=3D600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
        groups: lo
        nd6 options=3D21<PERFORMNUD,AUTO_LINKLOCAL>
ue0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15=
00
        options=3D80009<RXCSUM,VLAN_MTU,LINKSTATE>
        ether b8:27:eb:4e:88:64
        inet 192.168.10.200 netmask 0xffffff00 broadcast 192.168.10.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
        nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
ue1: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 15=
00
        options=3D8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE>
        ether 00:50:b6:5d:1d:9f
        inet 70.169.168.7 netmask 0xffffff80 broadcast 70.169.168.127
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
        nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
ue0.3: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex>)
        status: active
        nd6 options=3D29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5c22b7f9-f120-5912-21c8-1de481b2f3c7>