We are having a problem ever since we upgraded from Exchange 5.5 to Excahgne 2003 where new accounts can't authetnicate in Outlook, if they are in a subdomain behind a Pix. (old accounts work fine)
The System Admins had someone tell them to rule out the Pix, I can create a vlan through the Pix and allow that vlan to have no security. Then place a machine on that vlan, in the subdomain, and see if the problem goes away. I realize I need v6.3 or later of the IOS. What I can't find anywhere is an example, of how to do this. Does anyone know if it is actually possible to create a vlan on a pix and then have it completely bypass all the security on the pix, essentially, making it a wide open tunnel I guess?
Any help is quite appreciate.
Bruce D. Meyer Network Analyst City of Columbia, SC
No, it isn't in PIX 6. You can "permit ip any any" out from the vlan, and for incoming you can permit "ip any" to the translated IPs that the vlan will show up as on the lower security interfaces. You cannot, however, selectively turn off protocol inspection in PIX 6 (there is more flexibility for that in PIX 7, but I don't know if there is enough for your purposes). Also, you cannot turn off the Adaptive Security Algorithm (ASA) that checks matters such as whether you have received a proper TCP handshake and checks whether sequence numbers are in range. Furthermore, you cannot turn off NAT translation except by using nat 0 access-list and that requires using public IPs.
I don't know how much closer you could get with PIX 7; I would think it likely that you still would not be able to tell it to bypass basic TCP flow consistancy checking.
The PIX isn't going to know whether the account is new or old. The only way the PIX could -possibly- differentiate between them is if different data is being sent for new accounts vs old accounts -- and if different data *is* being sent, then the issue is on the Exchange server.
Let me throw in a random hypothesis: that "old" accounts authenticate with old mechanisms, but that "new" accounts are marked to try to authenticate with LDAP or something like that. If so, then Yes, you might need to make some adjustments to the flows you allow through the PIX, but you should be able to determine this by looking at the PIX logs (you might need to up the logging level to 6.)
Thank you for the idea's. I had offered a while back the idea that new accounts might be doing something different. One thing we have seen is, if we take a new account, and when it continually prompts for username password, we enter ANY username password that has previously been authenticated to Excahgne 2003, the account will continue to work for the new user. A couple items are changed on the account at the time of the first authentication. I'll up the debug level and see what I see. My expertise with the debug'ing isn't great. Though cisco.com is full of manuals on what commands exist, it seems to be a bit shy on useful examples for when to use them. I believe I have been using: debug fixup udp to view the errors. I have seen what is kind of odd: when someone attempts to use the username password, the pix will show that the dc is trying to authnticate to a different DC outside of the firewall. (we have a secure dc - to - dc filter with shared key on the tcp settings of the dc's nic) < if I allow the dc to access that other dc, everything works for a while. Then a few weeks down the road it fails, and debug on the pix shows the dc is not trying to authenticate to a different dc.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.