[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [FW1] SecureRemote and WINS
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:[email protected]] Sent: Saturday, December 09, 2000 12:46 PM To: 'CryptoTech' Cc: '[email protected]' 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>) ) )
|