Win2K3 NLB works on the LAN but not from outside the Pix

Greg,
We load balance and push traffic through a pix without problem. Internally we use a content swtich for that though and it seems to work okay. No special arp rules are needed.

Some things I would do to troubleshoot:

1) Allow port 80 as well and throw a default page in. Can you pull it up from outside? Could this be an SSL problem that is disguising as a firewall problem by accident? On our LB's we have to sticky the connections for SSL to get them to work properly. Sticky refers to tracking the incoming IP's to a single destination.

2) Allow the ports to the individual IP's on a different NAT, or since this one isn't working, with the same NAT. Does it allow the traffic? Again this could show a problem with SSL for the VIP or could also mean the PIX can't contact the VIP.

3) If it's not related to one or two, either post your PIX config here, or open a TAC case or both. You probably need an answer pronto and there's no sense waiting when you can use both methods.

-skpruett

Hi Greg,

From your PIX, can you ping the cluster IP address (10.1.1.12)  ?

If you can, could you post the static mapping CLI from the PIX?

Also check within the IIS permission, have you set a proper permission for accessing 10.1.1.12 web server?

OK, thanks for the replies.

skpruett, your 1) had a decent effect.  Now I'm getting the "Page under Construction" on http, instead of the page not found.  I didn't initially go here because http and https both work internally.  I'm going to need to read up on the "sticky" thing.  Any further clarification or direction would be appreciated.  I'd like to avoid 2) for now, because 1) seems to be a good path to go down and 2) though a decent troubleshooting technique would likely prove unacceptable in production (well, as is the 80 being open...but we're trying here ;-).)

alex:  I can successfully ping the cluster IP on the internal interface from the PIX.  The configs pertaining are:
static (inside,outside)   67.xxx.yyy.12   10.1.1.12   netmask   255.255.255.255   100   100
conduit permit tcp host 67.xxx.yyy.12 eq 443 any
conduit permit tcp host 67.xxx.yyy.12 eq www any  (Due to the temp recommendation from skpruett)
arp inside 10.1.1.12 02bf.xxxx.yyyy.0a22 alias (where 02bf.xxxx.yyyy.0a22 represents the VMAC)

As for permissions, and this is a broad enough topic for many follow-up questions, everything works fine internally, and it seems that I have Anonymous Access properly configured.  I would welcome and turn-around any specific permission questions.  Really, I don't mind if we make zero assumptions...I'll be glad to check.

Thanks,
Greg

To partially follow-up on stickiness, I did accept the default Affinity: Single setting when setting up the farm.

--Greg

OK, I'm definitely able to hit the site through 80, now.  That has to remove ARP, MAC, VIP, VMAC from the equation right?  Probably takes the Switches/PIX/Routers out too, I think.  Anything else on the SSL sticky biz?  Sounds like my prob is squarely on SSL config.

--Greg

OK, I take it back.  There was an intermittent success story on 80, but that's now gone.  I'm still getting my "Page Under Construction" on 80, default.  It's just the folders that I can't bring up with consistent success.  Of course the overall problem is that I can't get "Page under Construction" or any of the content to come up through 443.

--Greg

Hi Greg,

Test A.
=====
I know that you can point to 10.1.1.12 and get the correct page and I am assuming you can still browse to 10.1.1.10 or 10.1.1.11 from internal network.

Have you tried just pointing to just either web1 or web2 for the static on the firewall?

static (inside,outside)   67.xxx.yyy.12   10.1.1.10   netmask   255.255.255.255   100   100
   - OR -
static (inside,outside)   67.xxx.yyy.12   10.1.1.11   netmask   255.255.255.255   100   100

Test B.
=====
But if I were you, I would try to lock it down further on the PIX Firewall

static (inside,outside) tcp 67.xxx.yyy.12 www 10.1.1.12 www netmask 255.255.255.255 100 100
static (inside,outside) tcp 67.xxx.yyy.12 https 10.1.1.12 https netmask 255.255.255.255 100 100
- MAYBE THIS ONE AS WELL static (inside,outside) tcp 67.xxx.yyy.zzz smtp 10.1.1.x smtp netmask 255.255.255.255 100 100

access-list 200 permit tcp any any eq www
access-list 200 permit tcp any any eq https
- MAYBE THIS ONE AS WELL access-list 200 permit tcp any any eq smtp
access-group 200 in interface outside


On the IIS side of things:
- I just want to confirm that 10.1.1.12 does not have a restriction to only allow internal subnet to view the page. (This is when I meant permission apart from Anonymous access). IP address and domain name restriction?
- Also you might want to turn on the logging and check if there's any error?

Good Luck.

Since this is (was) a time sensitive thing, yesterday afternoon I configured the pix to point at the first web1's ip instead of the VIP, and I dropped the arp alias to the VMAC.

Now I'm in from the outside, but only to one machine.  The clustering is still, and always has worked from the inside.

So I think we (you and I) both arrived at your TEST A being a good idea.  And this is limping me through, but not for long.  As for B, I'd like to just get it working being further restricting anything.

As for permissions, given the TEST A is getting the job done externally, I have to thing the permissions are OK.  What else does this one-machine success tell us?

--Greg

Hi Greg,

I think the issue is on the cluster server routing table.
What do you use to NLB web1 and web2?
Another IIS server? ISA? some other web server?

- Alex.

Sorry Alex, not sure I understand the Q.  I use win2K3 built-in Network Load Balancing.  They are both running IIS, and both participate in the cluster created through Network Load Balancing Manager.  I provide the VIP, it provides the VMAC, and they both respond independenetly and on the cluster name/ip, at least internally.

You were right about arp.
You've got to create the static ARP entry, but only if you're connected to a layer 2 switch

http://support.microsoft.com/kb/193602/en-us

I think the issue lies on the routing table of the cluster server.
It does not know where to route out to the Internet.