Thursday, June 17, 2010

Juniper Firewall MIP-Definition, configuration of MIP

MIP – Definition: MIP (Mapped IP) is a 1 to 1 mapping of a public IP address to an IP address on the Internal side of the Juniper firewall.

Configuring a MIP to access a single device on the private network:

Consider the following setup:
Internal host IP is
Public interface (e0/0) IP is
Another public IP - is available for use.

Here is how you can configure a MIP to a single IP, and how to configure a policy to permit ANY host from the Untrust zone to access the internal host:
set interface "ethernet0/0" zone "Untrust"
set interface "bgroup0" zone "Trust"
set interface ethernet0/0 ip
set interface bgroup0 ip
set interface "ethernet0/0" mip host netmask vr "trust-vr"
set policy from "Untrust" to "Trust"  "Any" "MIP(" "ANY" permit

  1. Click on Interfaces
  2. Select the e0/0 Interface
  3. Click on MIP
    You will be at the Network > Interfaces > Edit > MIP > Configuration for interface e0/0
    Enter the following:
    Mapped IP:
    Host IP:
    Host Virtual Router Name: trust-vr 
  4. Create an incoming policy by going to
    Policy > Policies (From Untrust To Trust)
    Source: Any
    Destination: MIP(
    Service: ANY 
    Action: Permit
You can limit access to networks and services of your choosing.  It is a good idea to start with permitting any service at first to confirm that the MIP is working.

Configuring a MIP to a subnet or multiple internal hosts:
The netmask determines how the mapping is done.   If you use a netmask of, the mapping is done on a one-to-one basis. If you use a different netmask, then it maps a range of addresses.
To map the addresses public addresses to the internal addresses
set interface "ethernet0/1" mip host netmask vr "trust-vr" 
set policy from "Untrust" to "Trust"  "Any" "MIP(" "ANY" permit

This will result in: maps to maps to
       ... maps to

Change a MIP

If you have a MIP created and want to change the addresses used in the MIP, it may report that the MIP is 'in use'.  Therefore, perform the following steps to free up the MIP from being 'in use', and make the changes:
  1. Either remove the policy that has the MIP or remove the MIP from the policy (by temporarily changing the MIP address book entry in the policy to another address).
  2. Configure the MIP and make the changes.
  3. Re-add the policy or change the policy back to the MIP.

Key Points:  

Here are some important configuration pointers regarding creating a MIP.  If a MIP overlaps with other IP addresses on your network, it could cause the inability to access those other hosts.
  •  If only one address is needed for a MIP, use Netmask of   Example:  Defining as a MIP will map one address to a host address. Do not set the Netmask equal to the subnet mask for Untrust Interface IP address.  The Juniper firewall will answer ARP requests for all addresses in the subnet defined in the MIP.  If the Untrust IP address is and the Gateway is in the above example, these addresses are included in the netmask, and the MIP will break normal traffic.
  • Make sure the combination of the MIP address and Netmask does not include the Untrust Interface IP address or the Default Gateway address or any other device's address that are on that subnet. Example: If the Untrust IP address is and the Gateway is, then the MIP configured as NETMASK is an acceptable configuration because it does not include/overlap with the untrust IP or the gateway IP address.
  • In ScreenOS 6.0 and below, a MIP supports a public address in a different network than that of the ingress interface only if the ingress interface is in the Untrust zone.  On all other zones, MIPs must must be in the same network with the IP address of the interface on which they live.   However, in ScreenOS 6.1 and above, a MIP supports a public address in a different network than that of the ingress interface in any zone.

Troubleshooting TIPS - Unable to pass traffic to a MIP:

When configuring a MIP, the Virtual Router that the MIP host resides in plays an important role. If the wrong Virtual Router (VR) is specified, traffic may not pass correctly. For example, if the MIP private host resides in the DMZ zone which is in the untrust-vr, be sure to specify the untrust-VR in the configuration of the MIP.
  • If a MIP is unreachable from the Internet, the next-hop Gateway router from the Juniper firewall may not have an ARP entry for the MIP address OR the MIP IP address may be associated with a different MAC. Two methods can be employed to correct this:
    1. If you have management access to the next-hop router from the Juniper firewall, clear the ARP cache on the router. Then attempt to ping the MIP address again to get the ARP table entry updated on the router.

    2. Swap the MIP and Untrust interface IP address temporarily, and ping the Gateway address from the Juniper Untrust interface until the router answers back.  This is simply a creative way to update the ARP table on the next-hop gateway router, without logging into the next-hop gateway router.

      Save the current configuration and then do the follow steps to swap the MIP and Untrust IP temporarily:
      • Remove the Incoming MIP policy
      • Delete the MIP
      • Change the Untrust IP address to the MIP address
      • Ping the Untrust Interface's Default Gateway IP address from any device on the Trust Lan until the pings are answered.  Again, steps a) - d) is a work-around to getting the next-hop gateway router's ARP table updated.
      • When the next-hop gateway router can ping the MIP address, switch the configuration back to the original configuration (before step a).
  • If you do not explicitly permit ping on the private host, you will not be able to ping the MIP. The Juniper firewall does not answer pings to the MIP address.  They are passed on to the server, and the replies are passed back.

Wednesday, June 16, 2010

PEMU - Free Cisco PIX Firewall Emulator / Simulator

This is a guide on how to install a Free pix emulator / simulator onto a linux platform. You can also obtain the windows version, which you can find (along with other tutorials and forum)
This software was written by mmm123, and is called PEMU, which is based on the QEMU emulator.
What do I need ? 
You will need to the following in order to install PEMU, 
  1. Install Guide (How-to) - Linux Platform - click here
  2. PEMU Software - Linux Platform - download
  3. IOS Image - Obtained via the Cisco website
Please bear in mind you will need to unzip the PEMU software, in order to obtain your pemu_2008-03-03_bin.tar.bz2 which you can then use when going through the install guide above. You will also find in here a README file which also has some good information to help with the install.
What do I need to do ? 
The best option with this version of PEMU is to use pcap, this means that you do not have to configure the ifup.ini file and the traffic should run much quicker then if just using tap.
You then configure your host (linux) interfaces to with a subnet of the same (or set them to promisc mode). And then run the PEMU command with the relevant switches (please see below).
Below is the command with the require switches. This presumes you are in the pemu directory, 
./pemu -net nic,vlan=1,macaddr=00:aa:00:00:02:01 -net pcap,vlan=1,ifname=eth0 -net nic,vlan=2,macaddr=00:aa:00:00:02:02 -net pcap,vlan=2,ifname=eth1 -serial stdio -m 128 FLASH
With all the information and tutorials above you should be able to configure this software without to many problems. If you do encounter any issues, visit the forum at and they should be able to help.

Renewing Self Signed Certificate in Exchange 2007

Exchange Server 2007:
Renewing the self-signed certificate posted by Abdul Samad (Riyadh)

Exchange Server 2007 issues itself a self-signed certificate for use with services like SMTP, IMAP, POP, IIS and UM. The certificate is issued for a period of one year.

The self-signed certificate meets an important need - securing communication for Exchange services by default. Nevertheless, one should treat these self-signed certificates as temporary. It's not recommended to use these for any client communication on an ongoing basis. For most deployments, you will end up procuring a certificate from a trusted 3rd-party CA (or perhaps an internal CA in organizations with PKI deployed).

However, should you decide to leave the self-signed certificate(s) on some servers and continue to use them, these need to be renewed - just as you would renew certificates from 3rd-party or in-house CAs.

To renew the certificate for server, a server with CAS and HT roles installed:
Get-ExchangeCertificate -domain "" fl

Note the services the certificate is enabled for (by default: POP, IMAP, IIS, SMTP on CAS + HT servers). Copy the thumbprint of the certificate.

Get a new certificate with a new expiration date:
Get-ExchangeCertificate -thumbprint "C5DD5B60949267AD624618D8492C4C5281FDD10F" New-ExchangeCertificate

If the existing certificate is being used for SMTP, you will get the following prompt:
Overwrite existing default SMTP certificate,
'C5DD5B60949267AD624618D8492C4C5281FDD10F' (expires 8/22/2008 7:20:34 AM), with certificate '3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E' (expires 1/28/2009 7:37:31 AM)?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "Y"):

Type y to continue. A new certificate is generated.

Thumbprint Services Subject
---------- -------- -------
3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E ..... CN=E12Postcard

The new certificate is generated and enabled. Examine the new certificate:
Get-ExchangeCertificate -thumbprint "3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E" fl

The old certificate is enabled for IIS, POP, IMAP and SMTP. The new certificate generated using the above command is enabled only for POP, IMAP and SMTP - IIS is missing.

To enable the certificate for IIS:
Enable-ExchangeCertificate -thumbprint "3DA55740509DBA19D1A43A9C7161ED2D0B3B9E3E" -services IIS

This enables the certificate for IIS (in addition to any other services it may already be enabled for - it adds to existing values of the services property).

Test services are working with the new certificate. If it works as expected, the old certificate can be removed:
Remove-ExchangeCertificate -thumbprint "C5DD5B60949267AD624618D8492C4C5281FDD10F"

Phonetic Alphabet Tables

Phonetic Alphabet Tables
Useful for spelling words and names over the phone. I printed this page, cut out the table containing the NATO phonetic alphabet (below), and taped it to the side of my computer monitor when I was a telephone help desk technician.
An alternate version, Western Union's phonetic alphabet, is presented in case the NATO version sounds too militaristic to you.
I was inspired to recreate this page and post it online when I overheard a co-worker say "L, as in Log" over the phone.
NATO Phonetic Alphabet
Letter phonetic letter
A Alpha
B Bravo
C Charlie
D Delta
E Echo
F Foxtrot
G Golf
H Hotel
I India
J Juliet
K Kilo
L Lima
M Mike
N November
O Oscar
P Papa
Q Quebec
R Romeo
S Sierra
T Tango
U Uniform
V Victor
W Whiskey
X X-ray
Y Yankee
Z Zulu
Western Union Phonetic Alphabet
Letter phonetic letter
A Adams
B Boston
C Chicago
D Denver
E Easy
F Frank
G George
H Henry
I Ida
J John
K King
L Lincoln
M Mary
N New York
O Ocean
P Peter
Q Queen
R Roger
S Sugar
T Thomas
U Union
V Victor
W William
X X-ray
Y Young
Z Zero

Monday, June 14, 2010

Installing with Login Script Setup

Use Login Script Setup to automate the installation of the OfficeScan client on unprotected computers when they log on to the network. Login Script Setup adds a program calledAutoPcc.exe to the server login script. The AutoPcc.exe file performs the following functions:

·         Determines the operating system of the unprotected computer and installs the appropriate version of the OfficeScan client
·         Updates the engine, virus pattern file, Damage Cleanup Services components, Spyware/Grayware scan and cleanup pattern file, and program files
To add AutoPcc.exe to the login script using Login Script Setup:
1.     On the computer you used to run the server installation, click Programs > Trend Micro OfficeScan server- {Server Name} > Login Script Setup from the Windows Startmenu.
The Login Script Setup utility loads. The screen displays a tree showing all domains on your network.
2.             Browse for the Windows NT/2000/Server 2003 computer whose login script you want to modify, select it, and then click Select. The server must be a primary domain controller and you must have administrator access. Login Script Setup prompts you for a user name and password.
3.             Type your user name and password. Click OK to continue.
The User Selection screen appears. The Users list shows the profiles of users that log on to the server. The Selected users list shows the user profiles whose login script you want to modify.
·         To modify the login script of a single or multiple user profiles, select them from the Users list, and then click Add
·         To modify the login script of all users, click Add All
·         To exclude a user profile that you have previously selected, click the name from the Selected users list, and click Delete
·         To reset your choices, click Remove All
4.             Click Apply when all target user profiles are in the Selected users list.
A message appears informing you that you have modified the server login script successfully.
5.             Click OK. Login Script Setup returns to its initial screen.
·         To modify the login script of other servers, repeat steps 2 to 4.
·         To close Login Script Setup, click Exit.
When an unprotected computer logs on to the servers whose
login scripts you modified, AutoPcc.exe will automatically
install the client to it.

Installing with Windows 2000/NT/2003 scripts

If you already have an existing login script, OfficeScan appends a command that executes AutoPcc.exe. Otherwise, OfficeScan creates a batch file called ofcscan.bat (which contains the command to run AutoPcc.exe).
OfficeScan appends the following at the end of the login script:
·         {Server_name} is the name of the computer where the OfficeScan server is installed
·         ofcscan is the OfficeScan directory on the server
·         installation_path is the directory where you installed the server files (by default, the PCCSRV folder)
The Windows 2000 login script is on the Windows 2000 server (through a net logon shared directory), under:
\\Windows 2000 server\system drive\WINNT\SYSVOL\domain\scripts\ofcscan.bat
The Windows NT login script is on the Windows NT server (through a net logon shared directory), under:
\\Windows NT server\system drive\windir\system32\repl\export\scripts\ofcscan.bat
\\Windows NT server\system drive\windir\system32\repl\import\scripts\ofcscan.bat
The Windows Server 2003 login script is on the Windows Server 2003 server (through a net logon shared directory), under:\\Windows 2003 server\system drive\windir\sysvol\domain\scripts\ofcscan.bat

Sunday, June 13, 2010

How to create multiple instances of OWA

Creating multiple Outlook Web Access instances is a great way to assign users different sets of OWA features and/or give file share access to users who need it -- without giving everyone in your organization the same access. This tip explains a method that can be used in any version of Windows, although some steps are platform-specific.

Assign an additional IP address to your client access server.
You don't have to install additional network interface controllers (NICs) onto the server, but you can. Windows allows you to bind multiple IP addresses to a single NIC.

Create a new website.
OWA is a Web application that depends on Internet Information Services (IIS). When you install the Client Access Server role, Exchange creates multiple IIS virtual directories within the server's default website.

You can manually add more virtual directories to the default website, but limitations within Exchange Server prevent you from creating additional Exchange-related virtual directories. Therefore, you'll need to create a dedicated website for each additional OWA instance that you plan to create.

As a part of the site-creation process, you must bind an IP address to the site; each site should have a unique IP address. After you assign an IP address to the server, create a DNS record that allows users to access the new website using a new domain name.

When you create a website through IIS, its virtual directory maps to a physical folder on the server's hard drive. Note which folder is being used as the site's home directory.

Create a new virtual directory.
Now that you've created a site to host a new OWA instance, you're going to need to create the necessary Exchange virtual directories within that site. At the very least, you need to create the OWA virtual directory. You may also want to create other directories depending on which Exchange Server versions your organization uses.

There is an Exchange Management Shell cmdlet you can use to create the virtual directories. There are various switches that can be used with this cmdlet, but let's create a virtual directory using the following command:

New-OWAVirtualDirectory –Name "owa" –Website ""

This command creates a new OWA virtual directory and names it OWA. It also binds that virtual directory to the IIS website

Note: In your organization, replace with the name of your new website.

Microsoft has a series of TechNet articles that explains the procedures for creating various types of Exchange-related virtual directories.

Assign users to specific websites.
Once you've created the new virtual directory, now you can assign users to individual instances of OWA. Unfortunately, neither Exchange Server nor IIS allow you to grant or deny access to specific virtual directories. However, IIS virtual directories map to physical folders on the server's hard drive, making it possible to manage security at the NTFS level.

Use segmentation to disable OWA features.
Open the Exchange Management Console and navigate to Server Configuration -> Client Access, then select the Outlook Web Access tab. You'll see a separate listing for each OWA instance that you created. This makes it possible to manage each OWA instance separately.

If you double-click on a specific OWA instance, the console will display a properties sheet for that instance. Go to the properties sheet's Segmentation tab to enable or disable features within that instance of OWA without affecting other instances. Other property sheet settings are also OWA instance specific.

This technique can be used to make other changes within OWA. For example, you can use these steps to create personalized versions of OWA for individual departments within your company. You would just need to modify the HTML code or image files within an OWA instance. You could also use these steps to regenerate Exchange Server's virtual directories if they became corrupted.

About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional (MVP) award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at