Novell Home

Pushing Proxy Settings for Two Subnets

Novell Cool Solutions: Trench

Digg This - Slashdot This

Posted: 27 Sep 2000
 

Current Version: ZENworks for Desktops 3

On September 20, 2000, we posted an open call for ideas about this problem:

Ed M. wrote: We are in a school environment, and are authenticating proxy users (BorderManager 3.5). My problem is that most of our schools (18 total) have two subnets. We would like to push proxy settings out during login. Not a problem for one subnet, but it has stumped me for two subnets. The only thing I can figure (using ZEN 2) is to register all the workstations and push the applications. While this would work, I was wondering if anyone knew of a more dynamic (possibly in the login script) way to do this so that the snAppShot of Netscape (for example) would have the correct proxy settings in place when distributed. I've tried the "%NETWORK", but it only provides the mac address (unless I'm not using it correctly).

Here's what we got, from a number of very smart guys. If you think of anything else, don't be shy.

Keith Craig

Try %Network_Address alternatively. Use an environment variable set on the machine that you can then reference from the login script. Something like "Set Net = Net1" then "if %Net = Net1 then..."

If you have any questions you may contact Keith at keithc@fs1.dilworth.school.nz

Ryan Flud

My first thought to distributing Netscape with the correct proxy settings for the given subnet would be to make two different application objects to install Netscape. One install for the first subnet and the second for the second subnet.

You could use the Netscape administration kit to create a answer file with all of the proxy info in it (and much more) or you could continue to use the snapshot utility and just change/add the appropriate proxy registry keys for the given subnet. I like the answer file from the admin kit because you can easily lock down the install of Netscape, especially useful in a school environment.

Now the tough part is how to associate this to the correct machines. I would imagine if you created a workstation group, one for each subnet and assigned the workstations to the correct group. Then assign the correct Netscape application to the correct workstation group. The only problem I see with this is that it would cause tree walking and in some environments that could spell trouble. I guess the question is what else differentiates the workstations from each other, besides the subnet they're on?

If you have any questions you may contact Ryan at Rflud@netsworkinc.com

Bruce Richardson

This webpage has details on how to create an automatic proxy configuration script for Netscape.

For this solution you would have to be running a web server somewhere on your network. But as long as it can be configured to support the javascript MIME type it could be any type of HTTP server.

The script language is javascript and it should allow you to set a proxy address depending on your subnet.

Example 3 on the webpage shows how to make subnet-based decisions.

Once you have a single script that works for all subnets, then all you need to do is to push the URL of the autoconfig script using ZEN.

If you have any questions you may contact Bruce at Bruce_M_Richardson@biscuits.com

Kenneth Franklin

My suggestion would be to import the AOT twice. Configure one of the apps for each subnet. Then you can can set a registry requirement for each one. The requirement would be the default gateway's address. I am assuming if he has two subnets there is a router between them which each subnet would see BUT they would each see a different address. This will allow you to seperate who is on what subnet. I know this information is stored in the registry. You can just search for your default gateway's address to find the key. That should work perfectly.

SUBNET 1 GATEWAY - 10.1.1.254

SUBENT 2 GATEWAY - 10.9.1.254

IF "hRegKey" = 10.1.1.254

The app will push with 10.1 address proxy server, etc.

I also considered using the subnet mask but that will only work if they are different which they don't necessarily have to be.

If you have any questions you may contact Kenneth at FranklinK@grandcasinos.com

Sean Hare

Ed, Netscape uses a binary file called netscape.cfg In this file, you can set different proxy addresses for your users. Use ZEN to always distribute that particular file to the appropriate subnets. There you go. Much the same with IE, except that those settings are stored in registry. We use both to direct our students and teachers to different homepages and proxy settings. If you need more info, just e-mail.

If you have any questions you may contact Sean at shareec@mail.olathe.k12.ks.us

Chris Davis NEW

I think Ed M. should have a look at Netscape (and IE's) auto-proxy configuration via web URL. Here's my situation.

We have 2 campuses and multiple subnets. The subnets are grouped in a logical manner, so I can easily determine which campus someone is on by the subnet. We currently have a proxy server on each campus. My problem was that we didn't want to hand set everyone's proxy info (this was prior to zen - plus we don't push apps to residential student computers). That is when we turned to auto-config. It has worked well for us, and has the added bonus of being pushable in the Zen app, easy to tell students to configure on their residential computers (a simple web URL) and allows for MUCH easier change.

Now, on to how Ed M.'s problem can be solved. Recently I discovered there was one flaw in our system (well, two actually). The first was that we had folks using laptops, and they travelled between campuses. So when they were offsite, they used their home campus's proxy. Not a horrible problem, but it caused another. One of my campuses is pre-k to 12th grade. The other is a college. We heavily use CyberPatrol on the former, and don't on the latter. I am sure some students on the restricted campus will/have figured out that they can bounce their computers off the unrestricted proxy. To combat that problem, I was going to install an access list on the cisco router between campuses to disallow traffic on port 8080 from travelling between campuses (the web traffic would be on port 80 from the unrestricted campus's proxy). However, this would kill the laptop users.

My solution was to re-write the javascript applet so that it could detect the subnet it was on, and set the proxy settings appropriately. With some student programming help, we have done so, and the new proxy script is in testing as we speak. I can share with Ed M. what our script looks like and other issues using the auto-config. Of course, what we did was highly customized to our IP address space, and it may not work for Ed, but I think it could be applied to many situations.

Another chap that answered EdM's problem pointed to the Netscape Web site and the excellent section on Auto-Proxy Configuration. However, what we are currently doing is different enough that I would like to get a good example to you. I took the time to modify it. It appears below. Our site is a class B address, with Campus 1 allotted 1-99 in the third octet, and Campus 2 alloted 100-199 in the 3rd octet. All workstations and other devices consider themselves on a class C subnet, and routing is done at the core of the campus networks.

function FindProxyForURL(url, host)

{
var ipaddress, ipsubnet, switcher;
var first = /.{8,8}\d\d\d/;
var second = /.{8,8}\d\d/;
var third = /.{8,8}.\d/;

ipaddress = myIpAddress();

if(first.test(ipaddress))

{

ipsubnet = ipaddress.substr(8, 11);

}

else if(second.test(ipaddress))

{

ipsubnet = ipaddress.substr(8, 10);

}

else if(third.test(ipaddress))

{

ipsubnet = ipaddress.substr(8, 9);

}

if (ipsubnet > 0)

{

if (ipsubnet < 100)

{

if (url.substring(0,5) == "http:")

{

return "PROXY 172.16.15.223:8080";

}

else if (url.substring(0,4) == "ftp:")

{

return "PROXY 172.16.15.223:8080";

}

else if (url.substring(0,7) == "gopher:")

{

return "PROXY 172.16.15.223:8080";

}

else if (url.substring(0,6) == "https:" ||

url.substring(0,6) == "snews:")

{

return "PROXY 172.16.15.223:8080";

}

else

{

return "DIRECT";

}

}

}

if (ipsubnet > 99)

{

if (url.substring(0,5) == "http:")

{

return "PROXY 172.16.150.223:8080";

}

else if (url.substring(0,4) == "ftp:")

{

return "PROXY 172.16.150.223:8080";

}

else if (url.substring(0,7) == "gopher:")

{

return "PROXY 172.16.150.223:8080";

}

else if (url.substring(0,6) == "https:" ||

url.substring(0,6) == "snews:")

{

return "PROXY 172.16.150.223:8080";

}

else

{

return "DIRECT";

}

}

}

If you have any questions you may contact Chris at cld@prin.edu

Marcus Breiden NEW

Here are some quick ideas.

  1. IMHO the %Network% variable will return the IP Subnet in Binary Format, so you can use this in the login script if needed.
  2. Better would be to put one subnet in a dns zone like sub1.school.org and the other subnet in sub2.school.org. The workstation would have than the dnsname wks1.sub1.school.org. If the workstation would request via dns the ip address for PROXY the workstation will add automatically .sub1.school.org at the end of the request and the dns server can distribute the correct proxy address.
  3. Similar to the second idea would be to add a proxy entry in the hosts file on the workstation.

If you have any questions you may contact Marcus at MBreiden@novell.com

Ren? Russchen NEW

Re-Distributing Proxy settings on one or more subnets

Proxy settings and some other settings concerning stations connected to various LAN segments and or subnets can be distributed by using variables in the registry and/or ini options through NWADMIN and distributed using Nal and WIN95/98. Maybe it works on ME/NT and 2000 as well; we just didn't test this.

Because we are using Netscape in combination with a user-defined setup, the proxy configuration is solved right where (we think) it best, right on the network disk in the user homedir. But maybe this information can give a hand in solving the subnet and stationnumber problems. Our goal was install a new machine; give it a name (connected to NIC node-id); give it a number, and never get to this problem again on this station whatsoever! Here is the story, and we succeeded 99%.

We designed it in in 5 basic steps:

  1. Get to know the segment and station-id
  2. Make identification variables within the included script files
  3. Use these variables in regsettings trough NWADMIN
  4. Complete registry setting responsible for (in our case) IP address and gateway
  5. Pump the setup in your stations and reboot. Done!

Step 1: get to know the segment and station id

We use a simple "trick" in the loginscript. Include sys:system\public\%NETWORK.DAT. and include sys:public\%PPSTAT. The %NETWORK loginscript variable in the loginscript could have the value 00000E22 (it can have any value you like, this is generated through the bind command at serverboot time at the networkserver). The .DAT extension is our free choice (all .DAT we use are scriptfiles).

So actually we include a script file, in this example, sys:public\00000E22.DAT. All the stations connected to this LAN segment will include this 00000E22.dat. Stations connected to another LAN segment will include another file, because the %NETWORK variable will generate different results for each LAN segment your station is connected to. Even when stations are moved from one segment to another the right file will be included.

For station numbering the %PPSTAT variable generates the physical station node address. For example, my station gives 188C9FEB. This will include sys:public\188C9FEB.DAT. And for each station (just like the LAN segments) we have different include files.

Step 2: make identification variables within the script files

Inside these files we store one (or more) variables (we only need segment & station number).

00000E22.DAT has got one line: local set net=?22?

188C9FEB.DAT has got one line: local set station=?1?

When login is initiated on my station we have %<<STATION> and %<<NET> giving 1 and 22 as a result. Other stations could have 2 and 22 , or 2 and 23 and so on.

Another way to do this is by generating lots of if-then-else statements for each station in the loginscript.

We actually use an extra home-made option so we can name the workstations JOHN or BEN or ADMIN-1 to avoid all the if-then-else stuff and to get rid of the unhandy node numbers. But even without this extra option you should be able to make a nice working system giving any station its own IP address or extra settings you like.

Step 3 use variables in regsettings trough NWADMIN

Create a new application using NWADMIN as usual. Then go to the macro button to create a new macro. We first tried to use the given variables NET/STATION directly but this doesn't seem to work so we used an extra step through the macro option in NWADMIN.

Three macros called IPMASK, IPADRESS and GATEWAY are doing the job. IPADRESS giving the value 192.121.%NET%.%STATION% and GATEWAY giving the value 192.168.%NET%.254. IPMASK is just 255.255.255.0. Number 192.121 gives my basic IP subnet, %NET% gives 22 or 23 depending the segment the station is connected to and %STATION% gives 1 to 255 whathever is defined in the include file using the %PPSTAT variable. In this way it does not matter which segment the station is connected to: we always get the right addresses for each station.

Step 4: complete registry setting responsible for (in our case) IP address and gateway

All prefab can be completed using the registry option within NWADMIN. We want to change the regkey

HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Services\ Class\N etTrans\0000]

"DefaultGateway"="%GATEWAY%"

"IPAddress"="%IPADDRESS%"

"IPMask"="%IPMASK%"

Note that sometimes the NetTrans\0000 could be NetTrans\0001 -- one of our machines did not work. After a complete network reinstall on this machine the problem was solved as well. Maybe you can just copy all the settings for the 0000 and 0001 options just to make sure we got the right one.

Step 5: Pump the setup to your stations and reboot

This is the easy part. Make the application we've been creating active to stations/users. Make a single run plus a reboot without asking (button distribution) and ready to go. Of course you should test your new app in a harmless situation before using it on 100 or more machines.

Because we're just using tools available at this moment and we're not the technical staff, any questions and/or suggestions are welcome at skycomputers@hetnet.nl

Ruud Hanegraaf NEW

Hi Ed. I don't think you're getting the MAC address when using %NETWORK. If you're in a pure IP environment the %NETWORK variable doesn't contain the IPX address but a hexadecimal representation of the workstation IP address! So a workstation with IP address 135.1.10.152 would result in a %NETWORK of 87010A98... (135=87, 1=01, 10=0A, 152=98).

This means you can find out the subnet from within your login script by putting in something like this:

IF NETWORK_ADDRESS >= "87010000" AND NETWORK_ADDRESS <= "8701FFFF" THEN

xxxxxxxx

END

IF NETWORK_ADDRESS >= etc.

The above statement would check for all addresses beginning with "135.1." in a 255.255.0.0 network.

It ain't pretty, but it'll work.

If you have any qeustions you may contact Ruud at r.hanegraaf@laurus.nl

Fr? de Vries NEW

This is how we do it, but it only works if the DHCP-server is there where the proxy-server is. I think this is a very common situation, a Novell NetWare server with a DHCP-server and a Proxy-server on it. We have lots of them. Every group of classrooms has a Novell5 server with a network with plm 80 pc's behind it. Every server serves a different ip-subnet, but every pc on all of these networks use the same IE.

As the user logs in, the ip-address of the dhcp-server (as seen in winipcfg) is read from the registry, and then written in the registry as the proxy for IE (don't know if this works for Netscape). We wrote a little program for this (reading and writing the registry), but I think it should be possible for ZEN to do the job.

If you have any questions you may contact Fré at f.de.vries@fcroc.nl

Rick Smith NEW

I would think the solution to the problem is actually quite simple. Look beyond the client proxy settings themselves. In a K-12 environment, what I do is setup either BorderManager v3.5 for NAT/transparent proxy or Novell ICS for either NAT/transparent proxy or link to the router by WCCP protocol. In both cases use the default ports such as 80 for http. Then set the DHCP server(s) on the local subnets to distribute these BorderManagers or Novell ICS IP address as their clients' default gateways if not using routers running WCCP. Even if using Cyberpatrol or another filter, workstations must still go through the "routers" and must be linked to cache, to the filter, and cannot disengage, and there are NO settings to perform at the workstation level, which still saves you work. This should accommodate all workstation OS's from NT to Linux to whatever.

If you have any questions you may contact Rick at rick@microtechnology.net


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell