I have successfully setup NT 4.0 domain trusts through Borderware 6.02, 6.1.1 and 6.1.2 firewalls by doing the following. This is commonly used for Microsft Outlook Web Access. Here is the scenario. We have an internal network of 192.168.1.0 mask 255.255.255.0 gateway 192.168.1.254 The SSN network is 10.10.10.0 mask 255.255.255.0 gateway 10.10.10.254 The gateways are the internal and SSN IP address's of the firewall. The internal networks PDC is called JIMBOB for domain DEATHCORP its IP address is 192.168.1.101 The SSN networks PDC is called DIBBLY and the domain is called DEEMZ its IP address is 10.10.10.21 1/ Create the following Internal to SSN Proxies TCP_139toSSN_PDC Enabled TCP Ports (Min-Max:Dest) 139-139:139 Proxy Type: GENERIC UDP_137toSSN_PDC Enabled UDP Ports (Min-Max:Dest) 137-137:137 Proxy Type: GENERIC UDP_138toSSN_PDC Enabled UDP Ports (Min-Max:Dest) 138-138:138 Proxy Type: GENERIC 2/ Create the following SSN to Internal Proxies. TCP_139toINT_PDC Enabled TCP Ports (Min-Max:Dest) 139-139:139 Proxy Type: GENERIC Destination Address: 192.168.1.101 UDP_137toINT_PDC Enabled UDP Ports (Min-Max:Dest) 137-137:137 Proxy Type: GENERIC Destination Address: 192.168.1.101 UDP_138toINT_PDC Enabled UDP Ports (Min-Max:Dest) 138-138:138 Proxy Type: GENERIC Destination Address: 192.168.1.101 3/ Setup Netbios name resolution. I do this by using lmhosts files. WINS can be used by adding static entries. Make sure that "enable lmhosts lookup" is ticked in the properties of TCP/IP (control panel, network,protocols) Make sure that it is lmhosts and not LMHOSTS.SAM. lmhosts file for internal network. This file called lmhosts goes into \WINNT\system32\drivers\etc on the internal PDC called JIMBOB and has the following line. 10.10.10.21 DIBBLY #PRE #DOM:DEEMZ lmhosts file for SSN network. This file called lmhosts goes into \WINNT\system32\drivers\etc on the SSN PDC called DIBBY and has the following line. 10.10.10.254 JIMBOB #PRE #DOM:DEATHCORP IMPORTANT!!!!!!!!!!!. THE SSN''s lmhosts file must have an entry that points the the SSN interface of the firewall. This is because the traffic is pinholed through to the internal network. So you don't use 192.168.1.101 as the entry. The Borderware firewall will not allow any networks on the SSN or External interfaces to address internal machines directly. 4/ Create the trust. I usually only create a one way trust between the SSN and Internal networks. First go onto the internal network PDC machine called JIMBOB and start User Manager, goto Trust Relationships and add DEEMZ in as trusting. Second goto the SSN PDC called DIBBLY and add DEATHCORP as a trusted domain. 5/ The last thing is that the users from the internal domain have to have the logon right to the OWA server DIBBLY. Create a group with a name such as OWA_INTERNET_GROUP on the internal domain and then open up User Mangler on DIBBLY and goto Polices>User Rights. Add the group OWA_INTERNET_GROUP in. Only users that you add into OWA_INTERNET_GROUP will have access. Note that when you remove a user they can still logon to OWA. The entries are cached for a period of time that I dont know. 6/ Your done! Tips. 1.Use the nbtstat utility to help you with name resolution. nbtstat -c will tell you what names are in the cache. If you have followed my lmhosts example then the entries should be there. For example if you do a nbtstat -c on DIBBLY you get the following. DEATHCORP <1C> GROUP 10.10.10.254 -1 JIMBOB <03> UNIQUE 10.10.10.254 -1 JIMBOB <00> UNIQUE 10.10.10.254 -1 JIMBOB <20> UNIQUE 10.10.10.254 -1 2. In the BWclient proxy settings for the SSN>INT and INT>SSN tick "log rejected packets". From the Borderware console hit ALT-F1 to look at the rejected packets in realtime. 3. Common places to go wrong are> Make sure that the file is lmhosts and not lmhosts.sam. Make sure that the lmhosts entry on the SSN machine points at the firewall SSN ip address and not the real internal IP address. Make sure that netbios will actually use the lmhosts file that you have created. A box has to be ticked in control panel>network>protocols>tcp/ip>wins. Comments on security. There are 2 major concerns. That someone will sniff a user name and password or gain access to the web server via some hole in IIS. 1. Follow Microsoft's Internet Information Server 4.0 Security Checklist, where you can. http://www.microsoft.com/technet/security/iischk.asp EXT proxies. This will stop anyone who has any control on your server from downloading any cracking tools. This is a real biggy. 5. If you DON'T use SSL then make sure that the proxy you create for access to the OWA server from the Internet uses Borderware's HTTP proxy. This means that only HTTP protocol traffic will be translated though to the OWA server. If someone was able to execute some code on your server that tried to download a shell from an FTP server on the Internet (if you didnt follow recommendation 4) then they would have to talk to it via HTTP. This is extremly unlikely. Seton Wingfield trvln@webhosters.co.nz We host web sites! www.webhosters.co.nz