RE: [FW1] SecureRemote and WINS

["Gaughan, Daniel" <DGaughan@FW1-NOSPAMdcmde.dcma.mil>]

I agree that restarting the management is not needed. I modify the dnsinfo.C
on my firewall, re-push policy, and the client updates the site.... changes
take effect. They can be seen both in the userc.C and the LMHOSTS files on
the client. I have made changes to the crypt.def in FWDIR$/lib to encrypt
dns.

My situation is that the firewall is the device giving the topology - no
unauthenticated topology downloads.
The clients have WINS entry for inside server. (Browse works for network
neighborhood)
W2K clients have SDL enabled - log onto NT4 domain.

Attached text file shows the format of the dnsinfo.C file. <space> indicates
spaces, <tab> indicates tabs. I've found the order of LM section doesn't
seem to matter. (i.e. crypto tech's is different and still works) But syntax
is critical. One you see the way the sections break out you can adjust them
fairly easily. Note the dns_label_count has some bugs, make it more that you
think you need, some entries confuse the code, it is in the release notes if
I recall correctly.

I would hope that some iteration allows us to 'push' WINS entries, but I can
see how that is more difficult to implement.

Daniel Gaughan

-----Original Message-----
From: Scott Hunter [mailto:shunter@appiancom.com]
Sent: Saturday, December 09, 2000 12:46 PM
To: 'CryptoTech'
Cc: 'fw-1-mailinglist@lists.us.checkpoint.com'
Subject: RE: [FW1] SecureRemote and WINS


Thank you once again for your input.  A friend pointed me to CP doc that had
a sample dnsinfo.C with both split DNS and LMdata entries that I modified
for our network and it works like a champ.  I don't have the link to the doc
nor my dnsinfo.C at my disposal at the moment, but I will post it if anyone
is interested.  Just email me directly.  It adds entries to the lmhosts
file, which I don't really care for.  I would prefer that it updated the
WINS entry of the IP stack.  I can't browse the network which some of my
users would want.  I guess I have to settle for that until I can come up
with another solution and if anyone has one, I am all ears (eyes?).  Also,
pushing a policy to the 4.1 FW1 and doing and update on my SecureRemote
client is all I have had to do whenever I modified the dnsinfo.C.  Try it.
I swear it works on my FW.  Lastly, my friend had a good idea for
distributing the customized userc.C.  Simply modify the one in the client
distribution before rolling it out.  The install distribution is not
compressed.  Sweet and simple.  Why didn't I think of that? (no comments,
Ed)  

By the way.  Someone mentioned that one security flaw in the CheckPoint VPN
architecture is the fact that since you don't get an IP address on the
inside of your network like you do with other VPN systems you must configure
all services inside your network to allow connections from pretty much
anywhere.  Not a big deal unless your firewall is comprimised, then it is a
very big deal.  I have seen many posts asking how to resolve this or work
around it and it seems that the best solution would be to get an internal IP
address and route internal traffic through it just like other systems.  Is
this possible with CP VPN and SR?  PPTP through a SR tunnel is a pretty
cumbersome solution.

Scott

(
:dns_servers<space>(
<tab>: (DNSNAME.FWNAME
<tab>:obj<space>(
<tab><tab>:<space>(111.111.111.2)
<tab>)
<tab>:topology<space>(
<tab><tab>: <space>(
<tab><tab><tab>:ipaddr<space>(111.111.111.0)
<tab><tab><tab>:ipmask<space>(255.255.255.0)
<tab><tab>)
<tab>)
<tab>:domain<space>(
<tab><tab>: <space>(
<tab><tab><tab>:dns_label_count<space>(6)
<tab><tab><tab>:domain<space>(.domname.domne.com)
<tab><tab>)
<tab>)
<tab>)
)
:encrypt_dns<space>(true)
:Lmdata<space>(
<tab>:<space>(
<tab><tab>:ipaddr<space>(111.111.111.25)
<tab><tab><tab>:name<space>(mypdc1)
<tab><tab><tab>:domain<space>(NTDOM)
<tab>)
<tab>:<space>(
<tab><tab>:ipaddr<space>(111.111.111.28)
<tab><tab><tab>:name<space>(mybdc1)
<tab><tab><tab>:domain<space>(NTDOM)
<tab>)
)
)