Guest Will Posted March 23, 2008 Posted March 23, 2008 I'm having some problems with firewall authorizations for Windows Update access in a DMZ. In general, I have had good luck getting access to Windows Update when you authorize passage of HTTP, HTTPS, and FTP to these networks: 131.107.0.0 / 16 207.46.0.0 / 16 64.4.0.0 / 18 65.52.0.0 / 14 In addition, I normally authorize these URLs for both http: and https: .microsoft.com windowsupdate.microsoft.com .windowsupdate.microsoft.com download.windowsupdate.com The problem I am having is that occasionally the DNS name "download.windowsupdate.com" resolves to some IPs on a huge network from the Limelight load balancing farm. When the client behind the firewall resolves that DNS to an IP, it then connects to the IP and the IP does NOT reverse back to the DNS name download.windowsupdate.com. Instead it resolves to some arbitrary name at the Limelight Network. So the firewall has no way of knowing that the connection is authorized. Further complicating all of this, download.windowsupdate.com does not always resolve to the Limelight load balancers. Microsoft appears to have these IPs pointing to load balancers all over the world. Some of the IPs I saw the download.windowsupdate.com domain name resolve to: 208.111.148.50 8.12.217.124 192.78.223.126 209.84.2.124 etc Microsoft provides a set of DNS names to use with the ISA firewall, and naturally that doesn't work for the IPs above because they don't reverse to Microsoft domain names. No way do I want to authorize the entire Limelight load balancing network into my DMZ. There are a huge number of IPs, and those are probably associated with many hundreds of different organizations. When I do a whois on the IPs Microsoft is using, nothing in the huge range of IPs returned suggests which subset of the range is reserved for Microsoft use. It would be really really nice for those of us who actually think about security if Microsoft would publish openly the range of IPs it is using for Windows Update. Failing that, I am open to ideas here about how can one set up a reasonable set of firewall rules to securely connect to this wideranging set of IPs. -- Will Quote
Guest S. Pidgorny Posted March 24, 2008 Posted March 24, 2008 I don't agree with the IP-based approach. There is no guarrantee that the IP ranges won't change. Which is why Microsoft is using DNS names. If your firewall isn't smart enough to deal with DNS names and initiating processes - configure the Windows Update client as a bastion host and allow connectivity to any IP address from it. -- Svyatoslav Pidgorny, MS MVP - Security, MCSE -= F1 is the key =- http://sl.mvps.org http://msmvps.com/blogs/sp "Will" <westes-usc@noemail.nospam> wrote in message news:bY2dnRgRl4YmmnvanZ2dnUVZ_qainZ2d@giganews.com...<span style="color:blue"> > I'm having some problems with firewall authorizations for Windows Update > access in a DMZ. In general, I have had good luck getting access to > Windows Update when you authorize passage of HTTP, HTTPS, and FTP to these > networks: > > 131.107.0.0 / 16 > 207.46.0.0 / 16 > 64.4.0.0 / 18 > 65.52.0.0 / 14 > > In addition, I normally authorize these URLs for both http: and https: > > .microsoft.com > windowsupdate.microsoft.com > .windowsupdate.microsoft.com > download.windowsupdate.com > > The problem I am having is that occasionally the DNS name > "download.windowsupdate.com" resolves to some IPs on a huge network from > the Limelight load balancing farm. When the client behind the firewall > resolves that DNS to an IP, it then connects to the IP and the IP does NOT > reverse back to the DNS name download.windowsupdate.com. Instead it > resolves to some arbitrary name at the Limelight Network. So the > firewall has no way of knowing that the connection is authorized. > Further complicating all of this, download.windowsupdate.com does not > always resolve to the Limelight load balancers. Microsoft appears to > have these IPs pointing to load balancers all over the world. Some of > the IPs I saw the download.windowsupdate.com domain name resolve to: > > 208.111.148.50 > 8.12.217.124 > 192.78.223.126 > 209.84.2.124 > etc > > Microsoft provides a set of DNS names to use with the ISA firewall, and > naturally that doesn't work for the IPs above because they don't reverse > to Microsoft domain names. > > No way do I want to authorize the entire Limelight load balancing network > into my DMZ. There are a huge number of IPs, and those are probably > associated with many hundreds of different organizations. When I do a > whois on the IPs Microsoft is using, nothing in the huge range of IPs > returned suggests which subset of the range is reserved for Microsoft use. > > It would be really really nice for those of us who actually think about > security if Microsoft would publish openly the range of IPs it is using > for Windows Update. Failing that, I am open to ideas here about how can > one set up a reasonable set of firewall rules to securely connect to this > wideranging set of IPs. > > -- > Will > </span> Quote
Guest Will Posted March 24, 2008 Posted March 24, 2008 "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message news:%23nApKMXjIHA.4740@TK2MSFTNGP05.phx.gbl...<span style="color:blue"> > I don't agree with the IP-based approach. There is no guarrantee that the</span> IP<span style="color:blue"> > ranges won't change. Which is why Microsoft is using DNS names. If your > firewall isn't smart enough to deal with DNS names and initiating > processes - configure the Windows Update client as a bastion host and</span> allow<span style="color:blue"> > connectivity to any IP address from it.</span> I agree to use DNS names, but this does not help me for many reasons: 1) Microsoft's own firewall - ISA 2006 - doesn't use DNS names. style_emoticons/ 2) The point I am trying to make here is that Microsoft handed the download.windowsupdate.com "host" to a bunch of different ISPs. When you do the reverse DNS lookup on those IP addresses, they do NOT identify themselves as being Microsoft related hosts. The better solution might be to filter on the URL being passed by the browser looking for download.windowsupdate.com. Some of our computers that do not have firewall clients installed are passing the URL intact and others are passing just the IP. -- Will <span style="color:blue"> > "Will" <westes-usc@noemail.nospam> wrote in message > news:bY2dnRgRl4YmmnvanZ2dnUVZ_qainZ2d@giganews.com...<span style="color:green"> > > I'm having some problems with firewall authorizations for Windows Update > > access in a DMZ. In general, I have had good luck getting access to > > Windows Update when you authorize passage of HTTP, HTTPS, and FTP to</span></span> these<span style="color:blue"><span style="color:green"> > > networks: > > > > 131.107.0.0 / 16 > > 207.46.0.0 / 16 > > 64.4.0.0 / 18 > > 65.52.0.0 / 14 > > > > In addition, I normally authorize these URLs for both http: and https: > > > > .microsoft.com > > windowsupdate.microsoft.com > > .windowsupdate.microsoft.com > > download.windowsupdate.com > > > > The problem I am having is that occasionally the DNS name > > "download.windowsupdate.com" resolves to some IPs on a huge network from > > the Limelight load balancing farm. When the client behind the firewall > > resolves that DNS to an IP, it then connects to the IP and the IP does</span></span> NOT<span style="color:blue"><span style="color:green"> > > reverse back to the DNS name download.windowsupdate.com. Instead it > > resolves to some arbitrary name at the Limelight Network. So the > > firewall has no way of knowing that the connection is authorized. > > Further complicating all of this, download.windowsupdate.com does not > > always resolve to the Limelight load balancers. Microsoft appears to > > have these IPs pointing to load balancers all over the world. Some of > > the IPs I saw the download.windowsupdate.com domain name resolve to: > > > > 208.111.148.50 > > 8.12.217.124 > > 192.78.223.126 > > 209.84.2.124 > > etc > > > > Microsoft provides a set of DNS names to use with the ISA firewall, and > > naturally that doesn't work for the IPs above because they don't reverse > > to Microsoft domain names. > > > > No way do I want to authorize the entire Limelight load balancing</span></span> network<span style="color:blue"><span style="color:green"> > > into my DMZ. There are a huge number of IPs, and those are probably > > associated with many hundreds of different organizations. When I do a > > whois on the IPs Microsoft is using, nothing in the huge range of IPs > > returned suggests which subset of the range is reserved for Microsoft</span></span> use.<span style="color:blue"><span style="color:green"> > > > > It would be really really nice for those of us who actually think about > > security if Microsoft would publish openly the range of IPs it is using > > for Windows Update. Failing that, I am open to ideas here about how</span></span> can<span style="color:blue"><span style="color:green"> > > one set up a reasonable set of firewall rules to securely connect to</span></span> this<span style="color:blue"><span style="color:green"> > > wideranging set of IPs. > > > > -- > > Will > ></span> > ></span> Quote
Guest S. Pidgorny Posted March 25, 2008 Posted March 25, 2008 G'day, One more reason to implement an internal update server: http://technet.microsoft.com/en-us/wsus/ And the Windows Update hosts shouldn't identify themselves as Microsoft hosts in rDNS, because they are not. The SSL cert is the ultimate identifier. -- Svyatoslav Pidgorny, MS MVP - Security, MCSE -= F1 is the key =- http://sl.mvps.org http://msmvps.com/blogs/sp "Will" <westes-usc@noemail.nospam> wrote in message news:ypCdnXLSG54rlHXanZ2dnUVZ_oqhnZ2d@giganews.com...<span style="color:blue"> > "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message > news:%23nApKMXjIHA.4740@TK2MSFTNGP05.phx.gbl...<span style="color:green"> >> I don't agree with the IP-based approach. There is no guarrantee that the</span> > IP<span style="color:green"> >> ranges won't change. Which is why Microsoft is using DNS names. If your >> firewall isn't smart enough to deal with DNS names and initiating >> processes - configure the Windows Update client as a bastion host and</span> > allow<span style="color:green"> >> connectivity to any IP address from it.</span> > > I agree to use DNS names, but this does not help me for many reasons: > > 1) Microsoft's own firewall - ISA 2006 - doesn't use DNS names. style_emoticons/ > > 2) The point I am trying to make here is that Microsoft handed the > download.windowsupdate.com "host" to a bunch of different ISPs. When you > do the reverse DNS lookup on those IP addresses, they do NOT identify > themselves as being Microsoft related hosts. > > The better solution might be to filter on the URL being passed by the > browser looking for download.windowsupdate.com. Some of our computers > that do not have firewall clients installed are passing the URL intact and > others are passing just the IP. > > -- > Will > </span> Quote
Guest Phillip Windell Posted March 25, 2008 Posted March 25, 2008 "Will" <westes-usc@noemail.nospam> wrote in message news:ypCdnXLSG54rlHXanZ2dnUVZ_oqhnZ2d@giganews.com...<span style="color:blue"> > "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message > news:%23nApKMXjIHA.4740@TK2MSFTNGP05.phx.gbl...<span style="color:green"> >> I don't agree with the IP-based approach. There is no guarrantee that the</span> > IP<span style="color:green"> >> ranges won't change. Which is why Microsoft is using DNS names. If your >> firewall isn't smart enough to deal with DNS names and initiating >> processes - configure the Windows Update client as a bastion host and</span> > allow<span style="color:green"> >> connectivity to any IP address from it.</span> > > I agree to use DNS names, but this does not help me for many reasons: > > 1) Microsoft's own firewall - ISA 2006 - doesn't use DNS names. style_emoticons/</span> Is use ISA2006. I use DNS Names. I do not use IP#s. I run Windows Updates and Microsoft Updates all the time to "catch up" machines before I turn them over to WSUS. <span style="color:blue"> > > 2) The point I am trying to make here is that Microsoft handed the > download.windowsupdate.com "host" to a bunch of different ISPs. When you > do the reverse DNS lookup on those IP addresses, they do NOT identify > themselves as being Microsoft related hosts.</span> Nothing does reverse lookups appearantly, so it wouldn't matter. I use it all the time,...my Access Rule uses a Domain Name Set. The following Domain will cover it all: .microsoft.com .windowsupdate.com . windows.com There is a longer more detailed list if you want to be more picky and use higher-level domain names (like "windowsupdate.microsoft.com"). I don't have a link to the list. -- Phillip Windell www.wandtv.com The views expressed, are my own and not those of my employer, or Microsoft, or anyone else associated with me, including my cats. ----------------------------------------------------- Understanding the ISA 2004 Access Rule Processing http://www.isaserver.org/articles/ISA2004_AccessRules.html Troubleshooting Client Authentication on Access Rules in ISA Server 2004 http://download.microsoft.com/download/9/1...07/ts_rules.doc Microsoft Internet Security & Acceleration Server: Partners http://www.microsoft.com/isaserver/partners/default.mspx Microsoft ISA Server Partners: Partner Hardware Solutions http://www.microsoft.com/forefront/edgesec...repartners.mspx ----------------------------------------------------- Quote
Guest Will Posted March 25, 2008 Posted March 25, 2008 "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message news:uQMMF$kjIHA.1744@TK2MSFTNGP05.phx.gbl...<span style="color:blue"> > One more reason to implement an internal update server: > > http://technet.microsoft.com/en-us/wsus/ > > And the Windows Update hosts shouldn't identify themselves as Microsoft > hosts in rDNS, because they are not. The SSL cert is the ultimate > identifier.</span> How do you implement a rule based on SSL in ISA 2006? -- Will <span style="color:blue"> > "Will" <westes-usc@noemail.nospam> wrote in message > news:ypCdnXLSG54rlHXanZ2dnUVZ_oqhnZ2d@giganews.com...<span style="color:green"> > > "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message > > news:%23nApKMXjIHA.4740@TK2MSFTNGP05.phx.gbl...<span style="color:darkred"> > >> I don't agree with the IP-based approach. There is no guarrantee that</span></span></span> the<span style="color:blue"><span style="color:green"> > > IP<span style="color:darkred"> > >> ranges won't change. Which is why Microsoft is using DNS names. If your > >> firewall isn't smart enough to deal with DNS names and initiating > >> processes - configure the Windows Update client as a bastion host and</span> > > allow<span style="color:darkred"> > >> connectivity to any IP address from it.</span> > > > > I agree to use DNS names, but this does not help me for many reasons: > > > > 1) Microsoft's own firewall - ISA 2006 - doesn't use DNS names. style_emoticons/ > > > > 2) The point I am trying to make here is that Microsoft handed the > > download.windowsupdate.com "host" to a bunch of different ISPs. When</span></span> you<span style="color:blue"><span style="color:green"> > > do the reverse DNS lookup on those IP addresses, they do NOT identify > > themselves as being Microsoft related hosts. > > > > The better solution might be to filter on the URL being passed by the > > browser looking for download.windowsupdate.com. Some of our</span></span> computers<span style="color:blue"><span style="color:green"> > > that do not have firewall clients installed are passing the URL intact</span></span> and<span style="color:blue"><span style="color:green"> > > others are passing just the IP. > > > > -- > > Will</span></span> Quote
Guest Will Posted March 25, 2008 Posted March 25, 2008 "Phillip Windell" <philwindell@hotmail.com> wrote in message news:e%232w01ojIHA.4356@TK2MSFTNGP02.phx.gbl...<span style="color:blue"> > "Will" <westes-usc@noemail.nospam> wrote in message > news:ypCdnXLSG54rlHXanZ2dnUVZ_oqhnZ2d@giganews.com...<span style="color:green"> > > "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message > > news:%23nApKMXjIHA.4740@TK2MSFTNGP05.phx.gbl...<span style="color:darkred"> > >> I don't agree with the IP-based approach. There is no guarrantee that</span></span></span> the<span style="color:blue"><span style="color:green"> > > IP<span style="color:darkred"> > >> ranges won't change. Which is why Microsoft is using DNS names. If your > >> firewall isn't smart enough to deal with DNS names and initiating > >> processes - configure the Windows Update client as a bastion host and</span> > > allow<span style="color:darkred"> > >> connectivity to any IP address from it.</span> > > > > I agree to use DNS names, but this does not help me for many reasons: > > > > 1) Microsoft's own firewall - ISA 2006 - doesn't use DNS names. style_emoticons/</span> > > Is use ISA2006. > I use DNS Names. > I do not use IP#s. ><span style="color:green"> > > 2) The point I am trying to make here is that Microsoft handed the > > download.windowsupdate.com "host" to a bunch of different ISPs. When</span></span> you<span style="color:blue"><span style="color:green"> > > do the reverse DNS lookup on those IP addresses, they do NOT identify > > themselves as being Microsoft related hosts.</span> > > Nothing does reverse lookups appearantly, so it wouldn't matter. I use it > all the time,...my Access Rule uses a Domain Name Set. The following</span> Domain<span style="color:blue"> > will cover it all: > .microsoft.com > .windowsupdate.com > . windows.com</span> I have that as well. For the affected firewall, the URLs are coming across without domain names and only as IPs. So there is no DNS to compare against. A reverse lookup on the IP won't get back to a Microsoft domain for download.windowsupdate.com. I guess I will have to force updates through web proxy in order to get it to work. -- Will Quote
Guest Phillip Windell Posted March 25, 2008 Posted March 25, 2008 > I guess I will have to force updates through web proxy in order to get it <span style="color:blue"> > to > work.</span> I always use Web Proxy and Firewall [winsock] Service together. My LAN is configured for auto-detection via WPAD and always has the Firewall Client installed (except for some servers that are only Web Proxy/SecureNAT). Once machines are caught up, it is all handled by WSUS. With the number of machines on the LAN I don't want the same patches/SPs downloading over and over and over again for every client. It would kill our bandwidth. -- Phillip Windell www.wandtv.com The views expressed, are my own and not those of my employer, or Microsoft, or anyone else associated with me, including my cats. ----------------------------------------------------- Understanding the ISA 2004 Access Rule Processing http://www.isaserver.org/articles/ISA2004_AccessRules.html Troubleshooting Client Authentication on Access Rules in ISA Server 2004 http://download.microsoft.com/download/9/1...07/ts_rules.doc Microsoft Internet Security & Acceleration Server: Partners http://www.microsoft.com/isaserver/partners/default.mspx Microsoft ISA Server Partners: Partner Hardware Solutions http://www.microsoft.com/forefront/edgesec...repartners.mspx ----------------------------------------------------- Quote
Guest Will Posted March 25, 2008 Posted March 25, 2008 "Phillip Windell" <philwindell@hotmail.com> wrote in message news:eQIYMTqjIHA.3780@TK2MSFTNGP06.phx.gbl...<span style="color:blue"><span style="color:green"> > > I guess I will have to force updates through web proxy in order to get</span></span> it<span style="color:blue"><span style="color:green"> > > to > > work.</span> > > I always use Web Proxy and Firewall [winsock] Service together. My LAN is > configured for auto-detection via WPAD and always has the Firewall Client > installed (except for some servers that are only Web Proxy/SecureNAT).</span> I have never been able to get WPAD to work. I point our DNS with an A DNS host record for WPAD to the ISA Server IP on the Internal network. But the browsers on clients never seem to autoconfigure. Is there a firewall rule required on ISA in order to have autoconfigure functionality work? -- Will <span style="color:blue"> > The views expressed, are my own and not those of my employer, or</span> Microsoft,<span style="color:blue"> > or anyone else associated with me, including my cats. > ----------------------------------------------------- > Understanding the ISA 2004 Access Rule Processing > http://www.isaserver.org/articles/ISA2004_AccessRules.html > > Troubleshooting Client Authentication on Access Rules in ISA Server 2004 ></span> http://download.microsoft.com/download/9/1...07/ts_rules.doc<span style="color:blue"> > > Microsoft Internet Security & Acceleration Server: Partners > http://www.microsoft.com/isaserver/partners/default.mspx > > Microsoft ISA Server Partners: Partner Hardware Solutions ></span> http://www.microsoft.com/forefront/edgesec...repartners.mspx<span style="color:blue"> > ----------------------------------------------------- > ></span> Quote
Guest S. Pidgorny Posted March 26, 2008 Posted March 26, 2008 I really don't know. I have become a firewall sceptic a while ago. -- Svyatoslav Pidgorny, MS MVP - Security, MCSE -= F1 is the key =- http://sl.mvps.org http://msmvps.com/blogs/sp "Will" <westes-usc@noemail.nospam> wrote in message news:pbadnWhiFJQGp3TanZ2dnUVZ_ternZ2d@giganews.com...<span style="color:blue"> > "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message > news:uQMMF$kjIHA.1744@TK2MSFTNGP05.phx.gbl...<span style="color:green"> >> One more reason to implement an internal update server: >> >> http://technet.microsoft.com/en-us/wsus/ >> >> And the Windows Update hosts shouldn't identify themselves as Microsoft >> hosts in rDNS, because they are not. The SSL cert is the ultimate >> identifier.</span> > > How do you implement a rule based on SSL in ISA 2006? > > -- > Will > ><span style="color:green"> >> "Will" <westes-usc@noemail.nospam> wrote in message >> news:ypCdnXLSG54rlHXanZ2dnUVZ_oqhnZ2d@giganews.com...<span style="color:darkred"> >> > "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message >> > news:%23nApKMXjIHA.4740@TK2MSFTNGP05.phx.gbl... >> >> I don't agree with the IP-based approach. There is no guarrantee that</span></span> > the<span style="color:green"><span style="color:darkred"> >> > IP >> >> ranges won't change. Which is why Microsoft is using DNS names. If >> >> your >> >> firewall isn't smart enough to deal with DNS names and initiating >> >> processes - configure the Windows Update client as a bastion host and >> > allow >> >> connectivity to any IP address from it. >> > >> > I agree to use DNS names, but this does not help me for many reasons: >> > >> > 1) Microsoft's own firewall - ISA 2006 - doesn't use DNS names. style_emoticons/ >> > >> > 2) The point I am trying to make here is that Microsoft handed the >> > download.windowsupdate.com "host" to a bunch of different ISPs. When</span></span> > you<span style="color:green"><span style="color:darkred"> >> > do the reverse DNS lookup on those IP addresses, they do NOT identify >> > themselves as being Microsoft related hosts. >> > >> > The better solution might be to filter on the URL being passed by the >> > browser looking for download.windowsupdate.com. Some of our</span></span> > computers<span style="color:green"><span style="color:darkred"> >> > that do not have firewall clients installed are passing the URL intact</span></span> > and<span style="color:green"><span style="color:darkred"> >> > others are passing just the IP. >> > >> > -- >> > Will</span></span> > > </span> Quote
Guest Phillip Windell Posted March 26, 2008 Posted March 26, 2008 You'll want to do it in both DNS and DHCP. Some client will receive it better with DHCP others will receive it better with DNS,...so you want both. Start with DNS, remove the A Record from your earlier attempt and create a CNAME entry for "wpad" that points to the "A" Record of the ISA that would already exist. Maybe not all documents will tell you to do it with the CNAME like that,...but I am. One reason for that is that you can easily move uses from one proxy to another by simply changing what A Record the CNAME points to and you will litterally have no other configuration to change. It is also the "clean" way to work with DNS because it eliminates having more than one record pointing to the same IP#. Then in DHCP create the "Option 252 wpad". When you create the URL value you will use the earlier CNAME from the DNS to build it (http://wpad.ad-domain.local/wpad.dat) On the ISA go to the Properties of the Internal Network Definition 1. Then to the Auto Discovery Tab,... check the box,...leave the port at 80 2. Firewall Client Tab,...Check all boxes except last one,..enter ISA Netbios Name in upper box, choose "use default url". Leave last checkbox and the last "servername" box empty. Verify the ISA is properly "publishing" the auto-configuration by going to the URL I mentioned above. (http://wpad.ad-domain.local/wpad.dat) You should get a prompt to "Open" or to "Save". If you choose Open you will see the contents of the configuration script. In the user's browsers which do not use the Firewall Client, go to the proxy settings and enable to top two checkboxes. Add the URL http://<proxy netbios name>:8080/array.dll?Get.Routing.Script On the machines that use the Firewall Client install the Firewall Client using the Defaults which is to autodetect the proxy. The Firewall Client software should automatically configure the browser and will continue to do so every 30 minutes if I'm not mistaken. Using autodiscovery will also help eliminate the problems that can arise with browser requests for internal sites being incorrectly sent to the proxy when they are supposed to go direct to the site. Here are links to verify my details above. Configuring WPAD Support for ISA Firewall Web Proxy and Firewall Clients http://www.isaserver.org/tutorials/Configu...ll-Clients.html ISA Server: Troubleshooting Automatic Detection http://www.microsoft.com/technet/isa/2004/ts_wpad.mspx Automatic Discovery for Firewall and Web Proxy Clients http://www.microsoft.com/technet/isa/2004/...cdiscovery.mspx -- Phillip Windell www.wandtv.com The views expressed, are my own and not those of my employer, or Microsoft, or anyone else associated with me, including my cats. ----------------------------------------------------- Understanding the ISA 2004 Access Rule Processing http://www.isaserver.org/articles/ISA2004_AccessRules.html Troubleshooting Client Authentication on Access Rules in ISA Server 2004 http://download.microsoft.com/download/9/1...07/ts_rules.doc Microsoft Internet Security & Acceleration Server: Partners http://www.microsoft.com/isaserver/partners/default.mspx Microsoft ISA Server Partners: Partner Hardware Solutions http://www.microsoft.com/forefront/edgesec...repartners.mspx ----------------------------------------------------- "Will" <westes-usc@noemail.nospam> wrote in message news:54WdneDdRt2L7HTanZ2dnUVZ_tKinZ2d@giganews.com...<span style="color:blue"> > "Phillip Windell" <philwindell@hotmail.com> wrote in message > news:eQIYMTqjIHA.3780@TK2MSFTNGP06.phx.gbl...<span style="color:green"><span style="color:darkred"> >> > I guess I will have to force updates through web proxy in order to get</span></span> > it<span style="color:green"><span style="color:darkred"> >> > to >> > work.</span> >> >> I always use Web Proxy and Firewall [winsock] Service together. My LAN >> is >> configured for auto-detection via WPAD and always has the Firewall Client >> installed (except for some servers that are only Web Proxy/SecureNAT).</span> > > I have never been able to get WPAD to work. I point our DNS with an A > DNS > host record for WPAD to the ISA Server IP on the Internal network. But > the browsers on clients never seem to autoconfigure. > > Is there a firewall rule required on ISA in order to have autoconfigure > functionality work? > > -- > Will ><span style="color:green"> >> The views expressed, are my own and not those of my employer, or</span> > Microsoft,<span style="color:green"> >> or anyone else associated with me, including my cats. >> ----------------------------------------------------- >> Understanding the ISA 2004 Access Rule Processing >> http://www.isaserver.org/articles/ISA2004_AccessRules.html >> >> Troubleshooting Client Authentication on Access Rules in ISA Server 2004 >></span> > http://download.microsoft.com/download/9/1...07/ts_rules.doc<span style="color:green"> >> >> Microsoft Internet Security & Acceleration Server: Partners >> http://www.microsoft.com/isaserver/partners/default.mspx >> >> Microsoft ISA Server Partners: Partner Hardware Solutions >></span> > http://www.microsoft.com/forefront/edgesec...repartners.mspx<span style="color:green"> >> ----------------------------------------------------- >> >></span> > > </span> Quote
Guest Will Posted March 27, 2008 Posted March 27, 2008 This was all helpful and thanks. It turns out I had already set up the CNAME for WPAD earlier and had reasoned similarly to you for maintenance. For now I'm trying to use just web proxy and am avoiding Firewall client. We tried Firewall client once and I really hated it because of the noise it created in the monitor. It made it much more difficult to follow the browsing patterns from the computer in ISA Monitor Something I really don't get: When I do an explicit attempt to access http://wpad.mydomain.com/wpad.dat I get the file and I can see that access in the firewall Monitor. But during normal activity, I never see any attempts to get this file by the browsers in autoconfigure mode. Is there some way that behavior might be kept silent by ISA? We configured the selection of autoconfigure in the browsers through group policy, and the only really tricky part was how to get the services that run in SYSTEM context to use the proxy. We came up with a hack that if you login as administrator, configure the browser with not only autoconfigure but also explicitly set the proxy values, then from command line run proxycfg -u, then reverse out the changes in the user's browser, that will force use of the proxy by automatic updates. -- Will "Phillip Windell" <philwindell@hotmail.com> wrote in message news:e$RkU50jIHA.536@TK2MSFTNGP06.phx.gbl...<span style="color:blue"> > You'll want to do it in both DNS and DHCP. Some client will receive it > better with DHCP others will receive it better with DNS,...so you want > both. > > Start with DNS, remove the A Record from your earlier attempt and create a > CNAME entry for "wpad" that points to the "A" Record of the ISA that would > already exist. Maybe not all documents will tell you to do it with the > CNAME like that,...but I am. One reason for that is that you can easily > move uses from one proxy to another by simply changing what A Record the > CNAME points to and you will litterally have no other configuration to > change. It is also the "clean" way to work with DNS because it eliminates > having more than one record pointing to the same IP#. > > Then in DHCP create the "Option 252 wpad". > When you create the URL value you will use the earlier CNAME from the DNS > to build it > (http://wpad.ad-domain.local/wpad.dat) > > On the ISA go to the Properties of the Internal Network Definition > 1. Then to the Auto Discovery Tab,... check the box,...leave the port at > 80 > 2. Firewall Client Tab,...Check all boxes except last one,..enter ISA > Netbios Name in upper box, choose "use default url". Leave last checkbox > and the last "servername" box empty. > > Verify the ISA is properly "publishing" the auto-configuration by going to > the URL I mentioned above. (http://wpad.ad-domain.local/wpad.dat) You > should get a prompt to "Open" or to "Save". If you choose Open you will > see the contents of the configuration script. > > In the user's browsers which do not use the Firewall Client, go to the > proxy settings and enable to top two checkboxes. Add the URL http://<proxy > netbios name>:8080/array.dll?Get.Routing.Script > > On the machines that use the Firewall Client install the Firewall Client > using the Defaults which is to autodetect the proxy. The Firewall Client > software should automatically configure the browser and will continue to > do so every 30 minutes if I'm not mistaken. > > Using autodiscovery will also help eliminate the problems that can arise > with browser requests for internal sites being incorrectly sent to the > proxy when they are supposed to go direct to the site. > > Here are links to verify my details above. > > Configuring WPAD Support for ISA Firewall Web Proxy and Firewall Clients > http://www.isaserver.org/tutorials/Configu...ll-Clients.html > > ISA Server: Troubleshooting Automatic Detection > http://www.microsoft.com/technet/isa/2004/ts_wpad.mspx > > Automatic Discovery for Firewall and Web Proxy Clients > http://www.microsoft.com/technet/isa/2004/...cdiscovery.mspx > > > -- > Phillip Windell > www.wandtv.com > > The views expressed, are my own and not those of my employer, or > Microsoft, > or anyone else associated with me, including my cats. > ----------------------------------------------------- > Understanding the ISA 2004 Access Rule Processing > http://www.isaserver.org/articles/ISA2004_AccessRules.html > > Troubleshooting Client Authentication on Access Rules in ISA Server 2004 > http://download.microsoft.com/download/9/1...07/ts_rules.doc > > Microsoft Internet Security & Acceleration Server: Partners > http://www.microsoft.com/isaserver/partners/default.mspx > > Microsoft ISA Server Partners: Partner Hardware Solutions > http://www.microsoft.com/forefront/edgesec...repartners.mspx > ----------------------------------------------------- > > > "Will" <westes-usc@noemail.nospam> wrote in message > news:54WdneDdRt2L7HTanZ2dnUVZ_tKinZ2d@giganews.com...<span style="color:green"> >> "Phillip Windell" <philwindell@hotmail.com> wrote in message >> news:eQIYMTqjIHA.3780@TK2MSFTNGP06.phx.gbl...<span style="color:darkred"> >>> > I guess I will have to force updates through web proxy in order to get</span> >> it<span style="color:darkred"> >>> > to >>> > work. >>> >>> I always use Web Proxy and Firewall [winsock] Service together. My LAN >>> is >>> configured for auto-detection via WPAD and always has the Firewall >>> Client >>> installed (except for some servers that are only Web Proxy/SecureNAT).</span> >> >> I have never been able to get WPAD to work. I point our DNS with an A >> DNS >> host record for WPAD to the ISA Server IP on the Internal network. But >> the browsers on clients never seem to autoconfigure. >> >> Is there a firewall rule required on ISA in order to have autoconfigure >> functionality work? >> >> -- >> Will >><span style="color:darkred"> >>> The views expressed, are my own and not those of my employer, or</span> >> Microsoft,<span style="color:darkred"> >>> or anyone else associated with me, including my cats. >>> ----------------------------------------------------- >>> Understanding the ISA 2004 Access Rule Processing >>> http://www.isaserver.org/articles/ISA2004_AccessRules.html >>> >>> Troubleshooting Client Authentication on Access Rules in ISA Server 2004 >>></span> >> http://download.microsoft.com/download/9/1...07/ts_rules.doc<span style="color:darkred"> >>> >>> Microsoft Internet Security & Acceleration Server: Partners >>> http://www.microsoft.com/isaserver/partners/default.mspx >>> >>> Microsoft ISA Server Partners: Partner Hardware Solutions >>></span> >> http://www.microsoft.com/forefront/edgesec...repartners.mspx<span style="color:darkred"> >>> ----------------------------------------------------- >>> >>></span> >> >></span> > > </span> Quote
Guest Phillip Windell Posted March 27, 2008 Posted March 27, 2008 "Will" <westes-usc@noemail.nospam> wrote in message news:uaKdna7MzMGxu3banZ2dnUVZ_tWtnZ2d@giganews.com...<span style="color:blue"> > Something I really don't get: When I do an explicit attempt to access > http://wpad.mydomain.com/wpad.dat I get the file and I can see that access > in the firewall Monitor. But during normal activity, I never see any > attempts to get this file by the browsers in autoconfigure mode. Is > there some way that behavior might be kept silent by ISA?</span> I don't know. <span style="color:blue"> > We configured the selection of autoconfigure in the browsers through group > policy, and the only really tricky part was how to get the services that > run in SYSTEM context to use the proxy.</span> That will never happen. Those things cannot use the Web Proxy Service. That can only be used by CERN Compliant Applications (like web browsers). Running services must either operated as SecureNAT or Firewall Clients. The Firewall Client is the best choice. In either case the Rules for the process must be set to anonymous (All Users). I don't know what "noise" the Firewall Client was alleged to create in the monitoring log,...but when using the monitoring log you should always use the Filtering to weed out the noise in any situation. -- Phillip Windell www.wandtv.com The views expressed, are my own and not those of my employer, or Microsoft, or anyone else associated with me, including my cats. ----------------------------------------------------- Understanding the ISA 2004 Access Rule Processing http://www.isaserver.org/articles/ISA2004_AccessRules.html Troubleshooting Client Authentication on Access Rules in ISA Server 2004 http://download.microsoft.com/download/9/1...07/ts_rules.doc Microsoft Internet Security & Acceleration Server: Partners http://www.microsoft.com/isaserver/partners/default.mspx Microsoft ISA Server Partners: Partner Hardware Solutions http://www.microsoft.com/forefront/edgesec...repartners.mspx ----------------------------------------------------- Quote
Guest Will Posted March 28, 2008 Posted March 28, 2008 "Phillip Windell" <philwindell@hotmail.com> wrote in message news:O3HBhFBkIHA.5724@TK2MSFTNGP03.phx.gbl...<span style="color:blue"> > "Will" <westes-usc@noemail.nospam> wrote in message > news:uaKdna7MzMGxu3banZ2dnUVZ_tWtnZ2d@giganews.com...<span style="color:green"> >> Something I really don't get: When I do an explicit attempt to access >> http://wpad.mydomain.com/wpad.dat I get the file and I can see that >> access in the firewall Monitor. But during normal activity, I never see >> any attempts to get this file by the browsers in autoconfigure mode. Is >> there some way that behavior might be kept silent by ISA?</span> > > I don't know. ><span style="color:green"> >> We configured the selection of autoconfigure in the browsers through >> group policy, and the only really tricky part was how to get the services >> that run in SYSTEM context to use the proxy.</span> > > That will never happen. Those things cannot use the Web Proxy Service. > That can only be used by CERN Compliant Applications (like web browsers). > > Running services must either operated as SecureNAT or Firewall Clients. > The Firewall Client is the best choice. In either case the Rules for the</span> I am with you on this, but I would request that you please try the following sequence under Windows 2003 and see if you don't get the same result: 1) Logon as administrator. 2) Open MSIE 7 and set the web proxy server value by selecting "Use a proxy server" checkbox, then providing correct values for Address and Port. 3) Verify that browser is able to get to Internet and that the URL field in ISA monitor is showing DNS names. 4) Go to command line on the server and issue command: proxycfg -u This grabs the currently logged in user's settings and uses them to establish a proxy default. Default for what I do not fully understand. 5) Go back to MSIE and change back proxy settings to your preferred default setting for the user. From this point on, Windows Updates running in the background through Automatic Updates on that computer will show DNS names in the ISA Monitor URL field. I don't claim to understand why. I agree with you that a background service shouldn't be using a browser connected setting. I'm just reporting what I see in the monitor log. Try it and you might like it, without necessarily understanding why it happens. <span style="color:blue"> > process must be set to anonymous (All Users). I don't know what "noise" > the Firewall Client was alleged to create in the monitoring log,...but > when using the monitoring log you should always use the Filtering to weed > out the noise in any situation.</span> It has been a while, but what we were seeing were what looked like encrypted sessions between the client and the proxy, with no distinct details about what each client was actually doing . Reading the monitor I was losing all sense about what actions were happening on the client computers. -- Will Quote
Guest Phillip Windell Posted March 28, 2008 Posted March 28, 2008 "Will" <westes-usc@noemail.nospam> wrote in message news:LcSdnSFrg_Zj33HanZ2dnUVZ_uyinZ2d@giganews.com... <span style="color:blue"> > I am with you on this, but I would request that you please try the > following sequence under Windows 2003 and see if you don't get the same > result:</span> I really don't see the point. Windows Updates runs in a browser so it can use the Web Proxy Service. Automatic Updates, although it works together with Windows Updates and/or Microsoft Update, is not the same thing. Maybe AU is cable of "borrowing" the browsers proxy settings and running with the Web Proxy Service,...I don't know. My point about things running as "services" needing the Winsock or Securenat services was more "general" and "generic",...if Windows Updates or Microsoft Updates or Automatic Updates does something a little different that doesn't change the main principles. <span style="color:blue"><span style="color:green"> >> process must be set to anonymous (All Users). I don't know what "noise" >> the Firewall Client was alleged to create in the monitoring log,...but >> when using the monitoring log you should always use the Filtering to weed >> out the noise in any situation.</span> > > It has been a while, but what we were seeing were what looked like > encrypted sessions between the client and the proxy, with no distinct > details about what each client was actually doing . Reading the monitor > I was losing all sense about what actions were happening on the client > computers.</span> Communication between the Firewall Client and the ISA is encrypted and takes place over some type of "secure channel". Sorry, I don't have all the specific details, but it is not supposed to be human readable and not supposed to give you details that you can read in the logs. You can't expect all the Domain Authentication details and such between the Client and the ISA to be "readable" in the firewall logs. This has nothing to do with the fact that the logging will still show the details of the "resulting" internet traffic generated by user. Sounds like it was just doing what it was supposed to be doing to me. You'd have to ask someone like Jim harrison for the specifics on that,...but there is no way that it is doing anything "wrong" or anything "bad",...after 6 years of producing ISA, I am sure MS has the communication between ISA and the Winsock Clients over the Layered Service Provider (Firewall Client) figured out. The old MS Proxy2 used the same thing and the Firewall Client and the Winsock Proxy Client are even cross-compatible up to a point,...so MS has been doing it since about 1995. -- Phillip Windell www.wandtv.com The views expressed, are my own and not those of my employer, or Microsoft, or anyone else associated with me, including my cats. ----------------------------------------------------- Understanding the ISA 2004 Access Rule Processing http://www.isaserver.org/articles/ISA2004_AccessRules.html Troubleshooting Client Authentication on Access Rules in ISA Server 2004 http://download.microsoft.com/download/9/1...07/ts_rules.doc Microsoft Internet Security & Acceleration Server: Partners http://www.microsoft.com/isaserver/partners/default.mspx Microsoft ISA Server Partners: Partner Hardware Solutions http://www.microsoft.com/forefront/edgesec...repartners.mspx ----------------------------------------------------- Quote
Guest Will Posted March 28, 2008 Posted March 28, 2008 "Phillip Windell" <philwindell@hotmail.com> wrote in message news:OPkDMmNkIHA.5396@TK2MSFTNGP06.phx.gbl...<span style="color:blue"> > "Will" <westes-usc@noemail.nospam> wrote in message > news:LcSdnSFrg_Zj33HanZ2dnUVZ_uyinZ2d@giganews.com... ><span style="color:green"> > > I am with you on this, but I would request that you please try the > > following sequence under Windows 2003 and see if you don't get the same > > result:</span> > > I really don't see the point. Windows Updates runs in a browser so it can > use the Web Proxy Service. Automatic Updates, although it works together > with Windows Updates and/or Microsoft Update, is not the same thing.</span> Maybe<span style="color:blue"> > AU is cable of "borrowing" the browsers proxy settings and running with</span> the Exactly. And since seeing automatic updates using DNS names is all I wanted in the first place, that solves my problem. <span style="color:blue"> > Web Proxy Service,...I don't know. My point about things running as > "services" needing the Winsock or Securenat services was more "general"</span> and<span style="color:blue"> > "generic",...if Windows Updates or Microsoft Updates or Automatic Updates > does something a little different that doesn't change the main principles.</span> Understood, but as the subject of the thread implies, I was focused on Automatic Updates . <span style="color:blue"><span style="color:green"><span style="color:darkred"> > >> process must be set to anonymous (All Users). I don't know what "noise" > >> the Firewall Client was alleged to create in the monitoring log,...but > >> when using the monitoring log you should always use the Filtering to</span></span></span> weed<span style="color:blue"><span style="color:green"><span style="color:darkred"> > >> out the noise in any situation.</span> > > > > It has been a while, but what we were seeing were what looked like > > encrypted sessions between the client and the proxy, with no distinct > > details about what each client was actually doing . Reading the</span></span> monitor<span style="color:blue"><span style="color:green"> > > I was losing all sense about what actions were happening on the client > > computers.</span> > > Communication between the Firewall Client and the ISA is encrypted and</span> takes<span style="color:blue"> > place over some type of "secure channel". Sorry, I don't have all the > specific details, but it is not supposed to be human readable and not > supposed to give you details that you can read in the logs. You can't</span> expect<span style="color:blue"> > all the Domain Authentication details and such between the Client and the > ISA to be "readable" in the firewall logs. This has nothing to do with the > fact that the logging will still show the details of the "resulting" > internet traffic generated by user. Sounds like it was just doing what it > was supposed to be doing to me. You'd have to ask someone like Jim</span> harrison<span style="color:blue"> > for the specifics on that,...but there is no way that it is doing anything > "wrong" or anything "bad",...after 6 years of producing ISA, I am sure MS > has the communication between ISA and the Winsock Clients over the Layered > Service Provider (Firewall Client) figured out. The old MS Proxy2 used</span> the<span style="color:blue"> > same thing and the Firewall Client and the Winsock Proxy Client are even > cross-compatible up to a point,...so MS has been doing it since about</span> 1995. To me this reads like an overly defensive response that is too protectionist of status quo without a reason. There might be very good technical reasons why using Firewall Client requires the output of information about connections in the ISA Monitor log to be so obscure. That doesn't mean it is a good usability design. And it is not inherently good just because it is was the technically easiest design to implement. As a user of the product, what I would like to see in the Monitor log is a clear sense of the endpoints in the connection. If you want to attribute a given connection to indicate it is going through web proxy or firewall client, that is great and useful. But ultimately those are lower level details and not the core data of interest to most users. -- Will Quote
Guest Phillip Windell Posted March 28, 2008 Posted March 28, 2008 "Will" <westes-usc@noemail.nospam> wrote in message news:-J6dnYAaV_FdpnDanZ2dnUVZ_jKdnZ2d@giganews.com...<span style="color:blue"><span style="color:green"> >> for the specifics on that,...but there is no way that it is doing >> anything >> "wrong" or anything "bad",...after 6 years of producing ISA, I am sure MS >> has the communication between ISA and the Winsock Clients over the >> Layered >> Service Provider (Firewall Client) figured out. The old MS Proxy2 used >> the >> same thing and the Firewall Client and the Winsock Proxy Client are even >> cross-compatible up to a point,...so MS has been doing it since about</span> > 1995. > > To me this reads like an overly defensive response that is too > protectionist > of status quo without a reason.</span> ....or it just reads like me just getting tired and impatient yesterday. I deal with this group every day pretty much all day. I see people complain about this, that , and the other thing about ISA. If it is about something "big" then fine, but if it is some little thing about some function not giving the admin all the little details they think they might need for whaterver they think they need it for I'm not that interested. We've had a few "hardware firewalls" around here along with ISA and it was most certainly much more difficult to get meaningful troubleshooting information out of them than it is with ISA. I'd rather focus my effort on giving someone guidance on accomplishing what they want to do with ISA. I don't really feel like getting into little nitty gritty details deep down in the gory guts of ISA and why it does some particualry obscure thing in a particular way. I don't work for MS and I don't have the "inside track" on that kind of information. The Firewall Client (aka Winsock Proxy Client) does pretty much the same thing, in the same why, since the 1990's with the old MS Proxy2 product. There have been some improvements in it, but over all it has not changed much. So whatever it is doing, it has been doing it since back when many of todays younger "upstart" Admins were in pre-school. -- Phillip Windell www.wandtv.com The views expressed, are my own and not those of my employer, or Microsoft, or anyone else associated with me, including my cats. ----------------------------------------------------- Understanding the ISA 2004 Access Rule Processing http://www.isaserver.org/articles/ISA2004_AccessRules.html Troubleshooting Client Authentication on Access Rules in ISA Server 2004 http://download.microsoft.com/download/9/1...07/ts_rules.doc Microsoft Internet Security & Acceleration Server: Partners http://www.microsoft.com/isaserver/partners/default.mspx Microsoft ISA Server Partners: Partner Hardware Solutions http://www.microsoft.com/forefront/edgesec...repartners.mspx ----------------------------------------------------- Quote
Guest Phillip Windell Posted March 28, 2008 Posted March 28, 2008 Here isa link to an articl listing the various free diagnostic tools for ISA. The ISAInfo Tool, DNSCache Tool, and the Firewall Engine Monitor seemed liek something you might be interested in. If you have questions about them,....don't ask me,... I won't know :-) ISA Server Tools http://www.isaserver.org/tutorials/ISA-Server-Tools.html -- Phillip Windell www.wandtv.com The views expressed, are my own and not those of my employer, or Microsoft, or anyone else associated with me, including my cats. ----------------------------------------------------- "Phillip Windell" <philwindell@hotmail.com> wrote in message news:%23JMq3jQkIHA.536@TK2MSFTNGP06.phx.gbl...<span style="color:blue"> > "Will" <westes-usc@noemail.nospam> wrote in message > news:-J6dnYAaV_FdpnDanZ2dnUVZ_jKdnZ2d@giganews.com...<span style="color:green"><span style="color:darkred"> >>> for the specifics on that,...but there is no way that it is doing >>> anything >>> "wrong" or anything "bad",...after 6 years of producing ISA, I am sure >>> MS >>> has the communication between ISA and the Winsock Clients over the >>> Layered >>> Service Provider (Firewall Client) figured out. The old MS Proxy2 used >>> the >>> same thing and the Firewall Client and the Winsock Proxy Client are even >>> cross-compatible up to a point,...so MS has been doing it since about</span> >> 1995. >> >> To me this reads like an overly defensive response that is too >> protectionist >> of status quo without a reason.</span> > > ...or it just reads like me just getting tired and impatient yesterday. I > deal with this group every day pretty much all day. I see people complain > about this, that , and the other thing about ISA. If it is about > something "big" then fine, but if it is some little thing about some > function not giving the admin all the little details they think they might > need for whaterver they think they need it for I'm not that interested. > We've had a few "hardware firewalls" around here along with ISA and it was > most certainly much more difficult to get meaningful troubleshooting > information out of them than it is with ISA. > > I'd rather focus my effort on giving someone guidance on accomplishing > what they want to do with ISA. I don't really feel like getting into > little nitty gritty details deep down in the gory guts of ISA and why it > does some particualry obscure thing in a particular way. I don't work for > MS and I don't have the "inside track" on that kind of information. > > The Firewall Client (aka Winsock Proxy Client) does pretty much the same > thing, in the same why, since the 1990's with the old MS Proxy2 product. > There have been some improvements in it, but over all it has not changed > much. So whatever it is doing, it has been doing it since back when many > of todays younger "upstart" Admins were in pre-school. > > -- > Phillip Windell > www.wandtv.com > > The views expressed, are my own and not those of my employer, or > Microsoft, > or anyone else associated with me, including my cats. > ----------------------------------------------------- > Understanding the ISA 2004 Access Rule Processing > http://www.isaserver.org/articles/ISA2004_AccessRules.html > > Troubleshooting Client Authentication on Access Rules in ISA Server 2004 > http://download.microsoft.com/download/9/1...07/ts_rules.doc > > Microsoft Internet Security & Acceleration Server: Partners > http://www.microsoft.com/isaserver/partners/default.mspx > > Microsoft ISA Server Partners: Partner Hardware Solutions > http://www.microsoft.com/forefront/edgesec...repartners.mspx > ----------------------------------------------------- > </span> Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.