Tips, Tricks, and Tales from the Techs

At my office and home I have setup Cisco routers, using SDM 2.5 which sets up Zone Based Firewalls.  For those of you familiar with the old ACL style (IOS Classic they call it) of firewalls, Zone Based Firewalls look pretty foreign.  Its the way ASDM works (in a way) and many other firewalls out there, although they all call it something else.  Cisco’s implementation is easy enough to manage using SDM, but nearly impossible to manage using CLI (in my opinion).  For more information on how to configure ZBF or what they do, check out Cisco’s page here.

What you’ll find out pretty quickly is that if you have any MS style PPTP VPN’s, they will cease to function.  There is also very little information out on the web on how to configure the router to allow PPTP passthrough to function.  Well after reading a bunch of posts, and even one that said to remove zone based firewalls and go back to an IOS Classic setup, I found a Cisco doc on how to setup the router itself as a PPTP server.  You can find the documentation here.  I was able to make it work taking a few of the commands out of that example and using it in my own router.  There is not an example of how to do it through SDM which I’ll show you below.  I’ll also show you how to do it through the CLI if you prefer that method.

First you want to set yourself up an ACL for the GRE (Generic Routing Encapsulation) protocol (protocol number 47).  GRE is neither TCP nor UDP and it has to be specifically allowed through the firewall.  There is also, to my knowledge, no way to ‘inspect’ this traffic as the Cisco mechanism only inspects TCP/UDP traffic.

SDM Method

In SDM, go to ‘Configure’, then ‘Additional Tasks’, and expand out the ‘ACL Editor’.  Once you have the list, go into the ‘Access Rules’ and hit Add.  Make sure you have the type set as ‘Extended Rule’ and put in a name such as PPTP-PASS-THROUGH.

Put a description if you like, then click ADD under ‘Rule Entry’.  On the ‘Add an Extended Rule Entry’ box, leave everything default, except under the Protocol and Service area, type in 47 for protocol, or select it from the selection box.

Once you hit okay, you should see the following:

Now that the rule is created we can setup the class maps and apply the class map to the proper zone pairs.  Back in the additional tasks page, expand out C3PL, and then expand out ‘Class Map’.  Once you have that opened up, you’ll want to click on ‘Inspection’, and click ‘Add’ at the top of the page.  That will open up the ‘Add Inspect Class Map’ dialogue box.  In the box ‘Class Map’, give the map a name such as ‘PPTP-Pass-Through-Traffic’.  Give a description if you’d like, and then we need to add the match traffic.  Under the Match side of the box, you’ll expand out ‘Access Group’ section and find the PPTP-PASS-THROUGH rule we made earlier, and click OK.

Okay, now that we have the proper match group, and the proper class map, we need to apply it to the zone pairs.  With the default SDM setup, you will have a zone pairs like sdm-zp-in-out, and sdm-zp-NATOutsideToInside.  These are the two we’re interested in.  The policy that the sdm-zp-in-out uses, is called ’sdm-inspect’, and the sdm-zp-NATOutsideToInside zone pair uses the sdm-pol-NATOutsideToInside-1 policy.  Now that we know which policy we need to modify, we can go back to the C3PL area and expand out the Policy Map folder.  Once you have that opened up, click on ‘Protocol Inspection’.  On the right hand side, you’ll see all of the various policies that are in effect.  All we’re concerned with is the two mentioned above.  So highlight the sdm-pol-NATOutsideToInside-1 and click Edit at the top right.

Click add and under Class Name, type in the name of the class you created a few steps ago, make sure that under Action it says Pass and hit okay.  You should be back to the Edit Protocol Inspection Policy Map, and if you scroll to the bottom, you should see the PPTP-Pass-Through-Traffic Class Map listed just above ‘class-default’. Click OK.

Perform the same steps with the sdm-inspect Policy Map.  Thats it!  You have enabled PPTP Passthrough using the SDM interface.  Be sure to save your running config before you exit SDM.

CLI Method

Open up a session into your routers CLI.  Once you are in, go into configure mode, and insert the following commands:

This will setup the Class Map:

class-map type inspect match-all PPTP-Pass-Through-Traffic
 match access-group name PPTP-PASS-THROUGH

These commands build the Access Group

ip access-list extended PPTP-PASS-THROUGH
 permit gre any any

Finally you need to add in the Class-Map to your inspection policies.  So depending on what your policy maps are, the command might be different, but I’m sure you get the idea:

For your in-out zone pair policy:

policy-map type inspect In-Out-Policy
 class type inspect PPTP-Pass-Through-Traffic
  pass

Be sure to add it in the proper order (as in you may need to pull it out and re-insert it in the right order, like ACL’s.  Be sure to do the same to your Out-In-Policy as well.

Conclusion

PPTP passthrough requires that there be 2 way TCP 1723 and Protocol 47 (GRE) enabled to work.  You’ll also need to make sure that you have some rules in there to handle that TCP 1723 traffic.  For a default SDM firewall installation, there is a default ‘inspect tcp’ rule so that all outbound tcp traffic has a return route.  If you don’t have something like that, you’ll also need to setup something for TCP 1723 out and back in.

Good luck!

Sean Uncategorized

I just spent several hours working on a buggy OWA problem that presented itself as a “440 login timeout” issue.  If you’ve ever spent time trying to repair the 440 login timout issue, you’ll know that it is pretty straight forward.  You simply re-sync the IUSR_Machinename and IWAM_machine account passwords, run a couple scripts and your good to go.  But what if that doesn’t work?

I found a million articles that all said the same thing – iusr/iwam passwords out of sync.  That wasn’t it.  I started to poke around more, and noticed that there were several rights that were never assigned correctly.  I thought that was pretty odd, so matched up the rights with my own SBS 2003 server, and …..  it didn’t work!!!  Frustration is now setting in.  This actually was over several days of working on it a few hours each day.

So today, I’m poking around, digging inside of IIS and running Process Monitor from Sysinternals/Microsoft.  And darn if there it is in plain site – the user I’m trying to login with doesn’t have read rights to the folder.  I check, the DOMAIN\USERS group certainly has the proper rights.  I try again, same result.  I make a couple other changes, same result.  Finally it starts to sink in…is the Users group setup right?  The Users group is a default ‘Builtin’ group to Windows.  Its setup at the time of install and youre really not supposed to monkey with it.  So why would it be wrong?  Well, that in itself is a long story.

So I finally take a peek at the contents of the DOMAIN\Users group on the clients server as compared to my own server.  HOLY COW!!!!  The Users group was made up of about 6 standard users.  It was completely devoid of the default groups.  A healthy Users group should look something like this:

<!– /* Font Definitions */ @font-face {font-family:”Cambria Math”; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:roman; mso-font-pitch:variable; mso-font-signature:-1610611985 1107304683 0 0 159 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4; mso-font-charset:0; mso-generic-font-family:swiss; mso-font-pitch:variable; mso-font-signature:-1610611985 1073750139 0 0 159 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:”"; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:”Arial”,”sans-serif”; mso-fareast-font-family:Calibri; mso-fareast-theme-font:minor-latin;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.Section1 {page:Section1;} –>

Their Users group didn’t have any of those three objects in there, but instead had 7 individual users inside.  So deleted the users that were present, and matched my own server and what do you know – OWA, OMA, and RWW all work like a charm now.

So the moral of the story is, don’t change the default Builtin groups unless you have a really good reason – and then don’t do it.  Its easy enough to build the groups that you need around the builtin groups and get the desired result.  Its not advisable to modify the default groups in any way.  They are there for a reason, and there are services, and applications that depend on them being setup in the proper way.  I took it for granted that the Users group would be the correct group from the gate.  Thats a mistake I won’t make again.  From now on, when debuggin any rights type problem, I’m going to be checking to make sure that the groups listed have the proper objects in them.  This is the result of non-admins doing admin work on a server.  So be sure to check that what you think is right – really is right.  Might save you some time – it would have saved me some time.

Sean Uncategorized

Recently I was dealing with an error with a windows mobile device that was trying to connect to an Exchange server on SBS 2003.  The error is pretty misleading with Support Code:0×85010014.  If you search the web you’ll find out about problems with Exchange activesync if you have forms based authentication and SSL required for your OWA page.  Well, running SBS this is the default configuration.  What I also found out, is the changes that are mentioned in Microsoft Knowledgebase 817379 are already done as part of a standard SBS installation.  So if you are working in SBS, you already have the changes that you would need to do to get this to work.  But I still have the error, so what do I do.  Well here is part of the actual error from the event log:

The remote server returned an error: (403) Forbidden.
Source: Microsoft.Exchange.OMA.ExchangeDataProvider

Searching the web for that string will turn up a nice blog by Mark Wilson regarding that specific error.  He mentions problems encountered if you performed a swing migration to new hardware.  Well on this particular server we had done exactly that.  But none of the fixes he mentions were needed as our HomeMTA settings were correct.  What could it be?  I was pulling my hair out.

One of the ways to test problems with SBS/OWA/Exchange is to try to access the directories and such through Internet Explorer, directly.  We were getting a 403 forbidden error.  Thats pretty important.  So, armed with my new knowledge from the above KB articles, I tried to log directly into the ‘exchange-oma’ virtual directory from the actual server itself.  I mean after all, that is what it does when you connect to OMA.  Well, what do you know.  I received a “You are not authorized to view this page”.  And deeper in the page you get to see the actual full error:

HTTP Error 403.6 – Forbidden: IP address of the client has been rejected.
Internet Information Services (IIS)

AH HA!!!!  Now I actually have a better idea of what is going on.  So the server has been denied by IP access to the virtual directory.  Now we’re getting somewhere.  So I open up the properties on the ‘exchange-oma’ virtual directory, and go into directory security, and in the middle of the page you have the option to ‘Grant or Deny access to this resource using IP addresses or Internet domain names’.  I entered that and low and behold, the IP address was wrong.  It was the address that we used on the server during migration.  We ended up putting the new server at the address of the old server when we were done.  So made that small adjustment and viola it was all up and running and the mobile phone was syncing.

So I took the opportunity to checkother virtual directories, and there are several that had the wrong info.  So I then re-ran the ‘connect to the internet’ wizard, which repaired the IP address on all the other virtual directories.  So the moral of the story is, if you change the IP address of your server, be sure to run the connect to internet wizard so that everything will be re-setup correctly, or you could be in a world of hurt later.

Sean Uncategorized

If you run a website with a secure portal, then you most likely have a certificate (or are self certified, which is not what this article is covering).  At some point in time that certificate will expire and you will need a new one.  But how do you do that?  You cannot generate a new CSR while the current certificate is loaded.  If you unlead the certificate your users will not be able to access your site.  What to do, what to do.

Setup a separate {fake} website
The first step is to go into IIS and create a new website.  It really doesn’t matter what you call it or what ports or whatever.  We really don’t care.  I call mine, ‘Temp-cert site’ and put it on some unused port that I don’t care about.  I also just make a directory, but don’t give any rights to it (just in case).  So what you should have is:

Create the CSR
The next step is to create the CSR based on this new site.  So you go through the normal motions:
Right click the Temp-cert site
Click properties
Click Directory Security tab
Click Server Certificate

The ‘Welcome to the Web Server Certificate Wizard’ will start – Go through this just like you did for the actual website you wanted to get the cert for.  Notice we haven’t actually touched the ‘real’ site yet.
Once you are done, copy and paste the New Request to your Certificate Provider and get your certificate back

Install the new certificate
Now that you have your new certificate, you will need to install it somewhere (not to the actual site yet).  So back to the temp site we go.  Right click and get into properties, and the Directory Security tab.  Click again on Server Certificate.  This time the wizard will go through the installing of the cert.  YES this will install the cert on our ‘temp’ site, but don’t worry we’ll fix that in a minute.  Make sure the cert installed without an error.

Remove the certificate on ‘Temp’ site
Now that you have a brand new shinny certificate on this site, we are going to remove it.  Removing the certificate takes it off that particular site, but does not remove it from the certificate store.  So go back into properties of the ‘temp’ site, and back into the familiar Directory Security and Server Certificate wizard.  Here we want to remove the certificate.  That wizard completes pretty fast and painless.  Now on to installing on the right site.

Install the certificate on the ‘real’ site
Okay, NOW is the time we are actually going to do something to the real site.  Right click on the proper site, and get into properties.  Then into the Directory Security and click on the Server Certificate wizard.  So you should see something like this:

So now you select the ‘Replace the current certificate’ and click next.  From there you should see a list of all the certs that have been installed on the server.  From there you should see your brand new shinny certificate, with the proper issue and expire dates.  Just simply select it, and close out of the wizard….

Thats IT!!!!

Now you have your new cert, and your actual live website wasn’t down, or without a cert at all.  This way will assure you that you have no down time as Certificates can take a few days to get after you give them your CSR.

Sean Tips and Tricks Add new tag, certificate, IIS, SSL, websites

This one has plagued me for quite a while.  I use Firefox and I always have tons of tabs.  And if you use Cisco SDM to configure routers, which I tend to (to at least get the bigger chunks of configuration done), then you’ve experienced that wonderful feeling that you get when you close SDM and all of your firefox windows (probably 3 or 4 at this point) go away, along with your tabs.  And when you re-open firefox, you notice that you have to recover from a crashed session, and you can only recover the last 3 sessions or whatever.  ARRRRRRGGGGHHHH!!!…  I’ve said many times….

So what is the solution?  You can set your default browser to IE, and then SDM will happily work through IE, and when you close, you won’t loose any of your Firefox sessions.  But if you do that, then everytime you click on a link from any source, they open in IE and not Firefox.  Bummer.  So after much digging, I have figured out a way to have it work the way I want.

My solution is based on the IE View add-on available for Firefox from here.  What this view allows you to do is open up any page that you have in FF in a separate IE window.  And just like IE Tab, you can specify sites that should always open in IE.  Great news!!  Now how to make it work?

So after some poking around, running things manually, I figured out that the SDMlauncher.exe program, merely calls up (using your default browser setting) c:\program files\Cisco Systems\common\common\launcher.html and passes it some arguments.  That will then load (with the arguments) in a browser window, which then opens other browser windows, etc..  So in IE View, if you simply add in ‘file:///C:/Program%20Files/Cisco%20Systems/Cisco%20SDM/common/common/launcher.html’, then your set.  Thats literally all there is to it.

So when you open up SDM Launcher, and put in the IP address, and click launch, you will see a tab get created in FF and within a millisecond (or so) IE will open and reload the page.  That will in-turn, perform all the actions that your used to when running SDM, but in IE.  The tab that you have in FF just has a placeholder message about the page being loaded in IE.  Once your done in SDM, you simply close the program, all of your IE windows (that are part of the SDM chain) will go away, and the tab in FF will even go away.  Very cool indeed!

Good luck with it and I hope this helps you out!

Sean Uncategorized

Over the past 24 hours, I’ve been involved with installing a couple routers at locations where the VPN was an integral part of the overall implementation.  At both locations I wanted to use Active Directory for authentication.  In the past, with PoPToP installations or other routers the RADIUS was very straight forward.  For Cisco, it is for the most part, but there are some gotcha’s that I’ve run into, and am going to post here.  Basically I was never really able to get the group authentication up and running through RADIUS and I’m not even sure that its worth getting working.  Its so easy to setup the group in the Cisco SDM and input all of your pertinent settings there, and then use RADIUS for the actual user authentication.

So your steps are really pretty simple and straight forward.  You will want to:

Install and configure IAS
Setup a RADIUS client in IAS with vendor set as Cisco (remember your shared secret)
Delete the existing Policies, and create a new policy and connect it to your windows group that will have VPN access
Set the policy to Grant Remote Access and go into Edit Profile
On the Authentication tab, make sure that ONLY the top option (MS-CHAP v2) is checked
On the Advanced tab, I set only a single service type of RADIUS Standard and set to Login

On the router, start the EasyVPN setup, choosing ‘local’ for the group authentication.  For the User Authentication, choose RADIUS and input the IP address of your IAS server and put in the secret.  Then setup your group policy normally (which is what you’ll give to your VPN clients).

That’s basically it.  When the remote user sets up their connection they will put in the group info that you specify from the EasyVPN setup, and as soon as they try to connect, they will get a login box with the familiar user name, password, and domain sections.  Works like a charm and only takes few minutes.

Very cool!  Now to see if I can get the same IAS server to work with the wireless AP to do EAS!  That’ll be another post.

Sean Uncategorized

This past week, I attended the Sharepoint Bootcamp at New Horizons in Sacramento.  It was taught by Sharee English who is a Sharepoint consultant and trainer.  You can check out her blog here.  I have to say that I was very impressed by what Sharepoint can do.  Not only is Sharepoint a way to house and store documents, but you can actually run your business off of a properly designed sharepoint installation.  From Sharee’s blog, you can find all kinds of references to sites etc.. that are run from Sharepoint, or you can see a demo site (with great links of all kinds) here. I hope to get our Sharepoint server up and running in the next few weeks, although that will be dependent on us getting our virtual architecture up and running and the servers converted to virtual servers.  But that is another story entirely.

For those of you running Small Business Server as the backend server, you already have a Sharepoint server running.  If you go to http://companyweb from inside the network, you will be taken to your internal sharepoint site.  Now that site is based off WSS (windows sharepoint services) which is the free version of the product, unlike the pay-for product that is call Micrsosoft Office Sharepoint Services, or MOSS, but you get the idea.

Basically with a MOSS or WSS install, you can replace that old network drive as the document storage location and get a more robust, more accessible file storage repository, that does versioning, etc..  I’ll be covering more of what you can do in a future blog.   If you have Exchange 2007, and outlook 2007, you can get rid of public folders and use a Sharepoint backend to house that data.  That way your data will be available to everyone you specify wether they have Outlook or not.  And its all searchable.  Very cool indeed.

Stay tuned for updates to our setup as I get it going.

Sean Tips and Tricks