Wednesday, October 1, 2014

prevent vlan's of communicating with eachother


Setup: Cisco router with multiple VLAN's configured on it.
How can you prevent 2 VLAN's communicating with eachother? Normally I would do this with ACL's like this:
access-list 102 deny ip 1.1.1.0 0.0.0.255 2.2.2.0 0.0.0.255
access-list 102 deny ip 2.2.2.0 0.0.0.255 1.1.1.0 0.0.0.255

int vlan 1
ip address 1.1.1.1 255.255.255.0
access-group 102 in

int vlan 2
ip address 2.2.2.2 255.255.255.0
access-group 102 in
 
This however is not handy when dealing with lot's of VLAN's configured on a router. Any suggestions of tweaking this or using an alternative to improve scalability?

Tuesday, September 30, 2014

CONFIGURING NAT OVERLOAD ON A CISCO ROUTER

CONFIGURING NAT OVERLOAD ON A CISCO ROUTER

WRITTEN BY ADMINISTRATOR. POSTED IN CISCO ROUTERS - CONFIGURING CISCO ROUTERS
4.6153846153811111 Rating 4.62 (13 Votes)
NAT (Network Address Translation) is a method that allows the translation (modification) of IP addresses while packets/datagrams are traversing the network. NAT Overload, also known as PAT (Port Address Translation) is essentially NAT with the added feature of TCP/UDP ports translation.
The main purpose of NAT is to hide the IP address (usually private) of a client in order to reserve the public address space. For example a complete network with 100 hosts can have 100 private IP addresses and still be visible to the outside world (internet) as a single IP address. Other benefits of NAT include security and economical usage of the IP address ranges at hand.
The following steps explain basic Cisco router NAT Overload configuration. NAT overload is the most common operation in most businesses around the world, as it enables the whole network to access the Internet using one single real IP address. If you would like to know more about the NAT theory, be sure to read our popular NAT articles, which explain in great depth the NAT functions and applications in today's networks.

 

EXAMPLE SCENARIO

The diagram below represents our example network which consists of a number of internal clients and a router connected to our ISP via its serial interface. The company has been assigned the following Class C subnet: 200.2.2.0/30 (255.255.255.252).
This translates to one usable real IP address - 200.2.2.1 - configured on our router's serial interface. IP address 200.2.2.2 will be used on the other end, that is, the ISP's router. Our ISP has also provided us with the necessary default gateway IP address (configured on our router - not shown) in order to route all traffic to the Internet.
Our goal in this example is to configure NAT Overload (PAT) and provide all internal workstations with Internet access using one public IP address (200.2.2.1).


CONFIGURE NAT OVERLOAD - PAT (PORT ADDRESS TRANSLATION)

'Overloading' means that the single public IP assigned to your router can be used by multiple internal hosts concurrently. This is done by translating source UDP/TCP ports in the packets and keeping track of them within the translation table kept in the router (R1 in our case). This is a typical NAT configuration for almost all of today's networks.
In addition, NAT Overload (PAT) is covered in great depth on Firewall.cx. Those interested can visit our NAT Overload (PAT) article.
tk-cisco-routers-nat-ovld-1
The first step in any NAT configuration is to define the inside and outside interfaces. It is imperative that we define the these interfaces for NAT overload to function.
Set the fast ethernet 0/0 interface as the inside interface:
R1# configure terminal
R1(config)# interface fastethernet0/0
R1(config-if)# ip nat inside

Next step is to set the serial interface S0/0 as the outside interface:
R1(config-if)# interface serial0/0R1(config-if)# ip nat outside 
R1(config-if)# exit

We now need to create an Access Control List (ACL) that will include local (private) hosts or network(s). This ACL will later on be applied to the NAT service command, effectively controlling the hosts that will be able to access the Internet. You can use standard or extended access lists depending on your requirements:
R1(config)# access-list 100 remark == [Control NAT Service]==
R1(config)# access-list 100 permit ip 192.168.0.0 0.0.0.255 any
The above command instructs the router to allow the 192.168.0.0/24 network to reach any destination. Note that Cisco router standard and extended ACLs always use wildcards (0.0.0.255).
All that's left now is to enable NAT overload and bind it to the outside interface previously selected:
R1(config)# ip nat inside source list 100 interface serial 0/0 overload
From this point onward, the router will happily create all the necessary translations to allow the 192.168.0.0/24 network access to the Internet.

VERIFYING NAT OVERLOAD OPERATION

Viewing the NAT translation table can sometimes reveal a lot of important information on your network's activity. Here you'll be able to identify traffic that's not supposed to be routed to the Internet or traffic that seems suspicious.
As packets start traversing the router it will gradually build up its NAT/PAT translation table as shown below:
R1# show ip nat translations
Pro Inside global           Inside local            Outside local         Outside global
udp 200.2.2.1:53427  192.168.0.6:53427      74.200.84.4:53        74.200.84.4:53
udp 200.2.2.1:53427  192.168.0.6:53427      195.170.0.1:53        195.170.0.1:53
tcp 200.2.2.1:53638   192.168.0.6:53638      64.233.189.99:80    64.233.189.99:80
tcp 200.2.2.1:57585   192.168.0.7:57585      69.65.106.48:110    69.65.106.48:110
tcp 200.2.2.1:57586   192.168.0.7:57586      69.65.106.48:110    69.65.106.48:110

As shown, the first 2 translations directed to 74.200.84.4 & 195.170.0.1 are DNS requests from internal host 192.168.0.6. The third entry seems to be an http request to a web server with IP address 64.233.189.99.
Looking at the fourth and fifth translation entry, you should identify them as pop3 requests to an external server, possibly generated by an email client.
Because these entries are all dynamically created, they are temporary and will be removed from the translation table after some time.
Another point you might want to keep in mind is that when we use programs that create a lot of connections e.g Utorrent, Limewire, etc., you might see sluggish performance from the router as it tries to keep up with all connections. Having thousands of connections running through the router can put some serious stress on the CPU.
In these cases, we might need to clear the IP NAT table completely to free up resources.
This is easily done using the following command:
R1# clear ip nat translation * 
Assuming no request has been sent right after the command was entered, the NAT translation table should be empty:
R1# show ip nat translations
Pro Inside global ...........Inside local .....Outside local .......Outside global
Lastly, you can obtain statistics on the overload NAT service. This will show you the amount of current translations tracked by our NAT table, plus a lot more:
R1# show ip nat statistics
Total active translations: 200 (0 static, 200 dynamic; 200 extended)
Outside interfaces:
Serial 0/0
Inside interfaces:
FastEthernet0/0
Hits: 163134904 Misses: 0
CEF Translated packets: 161396861, CEF Punted packets: 3465356
Expired translations: 2453616
Dynamic mappings:
-- Inside Source
[Id: 2] access-list 100 interface serial 0/0 refcount 195
Appl doors: 0
Normal doors: 0
Queued Packets: 0

ARTICLE SUMMARY

In this article we've covered configuration of NAT Overload on Cisco routers. We also saw how you can control the NAT Overload service using ACLs and obtain detailed statistics on the NAT service. The configuration and commands presented here is compatible with all Cisco router models and IOS's.
If you have found the article useful, we would really appreciate you sharing it with others by using the provided services on the top left corner of this article. Sharing our articles takes only a minute of your time and helps Firewall.cx reach more people through such services.

ABOUT THE WRITERS

Ammar Muqaddas is a CCNA certified Engineer, CCNA Instructor and member of the Firewall.cx Team.
Chris Partsenidis is a CCNA certified Engineer, MCP, LCP, Founder & Senior Editor of Firewall.cx

Saturday, August 30, 2014

Managing Limits in Exchange Server 2010

Managing Organization Limits

The best practice is to terminate a message that is not delivered in a reasonable time from the transport pipeline, and using Organization Limits you can achieve that easily. Let’s say that we configure our organization to 5MB for send and receive, even if we have a Send Connector set to 10MB the mailboxes won’t be able to send any message larger than 5MB internally or externally. As a thumb rule the Organization Limits should be the largest value in your environment, although you can work with exceptions at user level but it’s not recommended. Eventually, it will become a pain to manage those special users.
In order to configure the organization limits we can open Exchange Management Console, expand Organization Configuration, Hub Transport, click on Global Settings tab and then double click on Transport Settings, as shown in figure 01.

Figure 01
Let’s start our exercises changing the value of Maximum receive size (KB) to 5MB (5120KB) to understand the implication of this change.
Now, our organization is restricting users to receive a maximum of 5MB messages, however the send limit is still 10MB and we may face the first issue, where a user can send a 10MB message but all other internal recipients won’t receive it. Even if the user tries to send himself a message larger than 5MB he would be able to send but he would also receive an error message explaining that it couldn’t be delivered due the limit restrictions.
Let’s try to send a message with one or more attachments where the total size of the message is larger than 5MB. The result will be a system message to the sender as shown in Figure 02. The diagnostic logging informs the administrator that the problem is on the receiving portion and we know that by the Resolver.RST.RecipSizeLimit string at the end of the NDR code.

Thursday, July 10, 2014

Configuring Site to Site IPSec VPN Tunnel Between Cisco Routers

Site-to-Site IPSec VPN Tunnels are used to allow the secure transmission of data, voice and video between two sites (e.g offices or branches). The VPN tunnel is created over the Internet public network and encrypted using a number of advanced encryption algorithms to provide confidentiality of the data transmitted between the two sites.
This article will show how to setup and configure two Cisco routers to create a permanent secure site-to-site VPN tunnel over the Internet, using the IP Security (IPSec) protocol. In this article we assume both Cisco routers have a static public IP address.  Readers interested in configuring support for dynamic public IP address endpoint routers can refer to our Configuring Site to Site IPSec VPN with Dynamic IP Endpoint Cisco Routers article.
IPSec VPN tunnels can also be configured using GRE (Generic Routing Encapsulation) Tunnels with IPsec. GRE tunnels greatly simply the configuration and administration of VPN tunnels and are covered in our Configuring Point-to-Point GRE VPN Tunnels article.  Lastly, DMVPNs – a new VPN trend that provide major flexibility and almost no administration overhead can also be examined by reading our Understanding Cisco Dynamic Multipoint VPN (DMVPN),  Dynamic Multipoint VPN (DMVPN) Deployment Models & Architectures and Configuring Cisco Dynamic Multipoint VPN (DMVPN) - Hub, Spokes , mGRE Protection and Routing - DMVPN Configuration articles.
ISAKMP (Internet Security Association and Key Management Protocol) and IPSec are essential to building and encrypting the VPN tunnel. ISAKMP, also called IKE (Internet Key Exchange), is the negotiation protocol that allows two hosts to agree on how to build an IPsec security association. ISAKMP negotiation consists of two phases: Phase 1 and Phase 2.  
Phase 1 creates the first tunnel, which protects later ISAKMP negotiation messages. Phase 2 creates the tunnel that protects data.  IPSec then comes into play to encrypt the data using encryption algorithms and provides authentication, encryption and anti-replay services.

IPSec VPN Requirements

To help make this an easy-to-follow exercise, we have split it into two steps that are required to get the Site-to-Site IPSec VPN Tunnel to work.
These steps are:
(1)  Configure ISAKMP (ISAKMP Phase 1)
(2)  Configure IPSec  (ISAKMP Phase 2, ACLs, Crypto MAP)
Our example setup is between two branches of a small company, these are Site 1 and Site 2. Both the branch routers connect to the Internet and have a static IP Address assigned by their ISP as shown on the diagram:
 cisco-routers-s2s-ipsec-vpn-1
Site 1 is configured with an internal network of 10.10.10.0/24, while Site 2 is configured with network 20.20.20.0/24. The goal is to securely connect both LAN networks and allow full communication between them, without any restrictions.

Configure ISAKMP (IKE) - (ISAKMP Phase 1)

IKE exists only to establish SAs (Security Association) for IPsec. Before it can do this, IKE must negotiate an SA (an ISAKMP SA) relationship with the peer.
To begin, we’ll start working on the Site 1 router (R1).
First step is to configure an ISAKMP Phase 1 policy:
R1(config)#  crypto isakmp policy 1
R1(config-isakmp)# encr 3des
R1(config-isakmp)# hash md5
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 2
R1(config-isakmp)# lifetime 86400

The above commands define the following (in listed order):
3DES - The encryption method to be used for Phase 1.
MD5 - The hashing algorithm
Pre-share - Use Pre-shared key as the authentication method
Group 2 - Diffie-Hellman group to be used
86400 – Session key lifetime. Expressed in either kilobytes (after x-amount of traffic, change the key) or seconds. Value set is the default value.
We should note that ISAKMP Phase 1 policy is defined globally. This means that if we have five different remote sites and configured five different ISAKMP Phase 1 policies (one for each remote router), when our router tries to negotiate a VPN tunnel with each site it will send all five policies and use the first match that is accepted by both ends.
Next we are going to define a pre shared key for authentication with our peer (R2 router) by using the following command:
R1(config)# crypto isakmp key firewallcx address 1.1.1.2
The peer’s pre shared key is set to firewallcx and its public IP Address is 1.1.1.2. Every time R1 tries to establish a VPN tunnel with R2 (1.1.1.2), this pre shared key will be used.

 

Configure IPSec

To configure IPSec we need to setup the following in order:
- Create extended ACL
- Create IPSec Transform
- Create Crypto Map
- Apply crypto map to the public interface
Let us examine each of the above steps.

 

Creating Extended ACL

Next step is to create an access-list and define the traffic we would like the router to pass through the VPN tunnel.  In this example, it would be traffic from one network to the other, 10.10.10.0/24 to 20.20.20.0/24.  Access-lists that define VPN traffic are sometimes called crypto access-list or interesting traffic access-list.
R1(config)# ip access-list extended VPN-TRAFFIC
R1(config-ext-nacl)# permit ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255

 

Create IPSec Transform (ISAKMP Phase 2 policy)

Next step is to create the transform set used to protect our data. We’ve named this TS:
R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
The above command defines the following:  
- ESP-3DES - Encryption method
- MD5 - Hashing algorithm

Create Crypto Map

The Crypto map is the last step of our setup and connects the previously defined ISAKMP and IPSec configuration together:
R1(config)# crypto map CMAP 10 ipsec-isakmp
R1(config-crypto-map)# set peer 1.1.1.2
R1(config-crypto-map)# set transform-set TS
R1(config-crypto-map)# match address VPN-TRAFFIC
We’ve named our crypto map CMAP. The ipsec-isakmp tag tells the router that this crypto map is an IPsec crypto map. Although there is only one peer declared in this crypto map (1.1.1.2), it is possible to have multiple peers within a given crypto map.

Apply Crypto Map to the Public Interface

The final step is to apply the crypto map to the outgoing interface of the router. Here, the outgoing interface is FastEthernet 0/1.
R1(config)# interface FastEthernet0/1
R1(config- if)# crypto map CMAP
Note that you can assign only one crypto map to an interface.
As soon as we apply crypto map on the interface, we receive a message from the router  that confirms isakmp is on: “ISAKMP is ON”.
At this point, we have completed the IPSec VPN configuration on the Site 1 router.
We now move to the Site 2 router to complete the VPN configuration. The settings for Router 2 are identical, with the only difference being the peer IP Addresses and access lists:
R2(config)# crypto isakmp policy 1
R2(config-isakmp)# encr 3des
R2(config-isakmp)# hash md5
R2(config-isakmp)# authentication pre-share
R2(config-isakmp)# group 2
R2(config-isakmp)# lifetime 86400
R2(config)# crypto isakmp key firewallcx address 1.1.1.1
R2(config)# ip access-list extended VPN-TRAFFIC
R2(config-ext-nacl)# permit ip 20.20.20.0 0.0.0.255 10.10.10.0 0.0.0.255
 
R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
R2(config)# crypto map CMAP 10 ipsec-isakmp
R2(config-crypto-map)# set peer 1.1.1.1
R2(config-crypto-map)# set transform-set TS
R2(config-crypto-map)# match address VPN-TRAFFIC
R2(config)# interface FastEthernet0/1
R2(config- if)# crypto map CMAP

 

Network Address Translation (NAT) and IPSec VPN Tunnels

Network Address Translation (NAT) is most likely to be configured to provide Internet access to internal hosts. When configuring a Site-to-Site VPN tunnel, it is imperative to instruct the router not to perform NAT (deny NAT) on packets destined to the remote VPN network(s).
This is easily done by inserting a deny statement at the beginning of the NAT access lists as shown below:
For Site 1’s router:
R1(config)# ip nat inside source list 100 interface fastethernet0/1 overload
R1(config)# access-list 100 remark -=[Define NAT Service]=-
R1(config)# access-list 100 deny ip 10.10.10.0 0.0.0.255 20.20.20.0 0.0.0.255
R1(config)# access-list 100 permit ip 10.10.10.0 0.0.0.255 any
R1(config)# access-list 100 remark

And Site 2’s router:
R2(config)# ip nat inside source list 100 interface fastethernet0/1 overload
R2(config)# access-list 100 remark -=[Define NAT Service]=-
R2(config)# access-list 100 deny ip 20.20.20.0 0.0.0.255 10.10.10.0  0.0.0.255
R2(config)# access-list 100 permit ip 20.20.20.0 0.0.0.255 any
R2(config)# access-list 100 remark

 

Bringing Up and Verifying the VPN Tunnel

At this point, we’ve completed our configuration and the VPN Tunnel is ready to be brought up.  To initiate the VPN Tunnel, we need to force one packet to traverse the VPN and this can be achieved by pinging from one router to another:
R1# ping 20.20.20.1 source fastethernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 20.20.20.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 44/47/48 ms


The first ping received a timeout, but the rest received a reply, as expected. The time required to bring up the VPN Tunnel is sometimes slightly more than 2 seconds, causing the first ping to timeout.
To verify the VPN Tunnel, use the show crypto session command:
R1# show crypto session
Crypto session current status
Interface: FastEthernet0/1
Session status: UP-ACTIVE    
Peer: 1.1.1.2 port 500
  IKE SA: local 1.1.1.1/500 remote 1.1.1.2/500 Active
  IPSEC FLOW: permit ip 10.10.10.0/255.255.255.0 20.20.20.0/255.255.255.0
        Active SAs: 2, origin: crypto map


About the Writer

Rahul Singh is a Cisco CCIE Security certified Engineer (#29110) and an active member of the Firewall.cx commuity.

Basics to configure a CISCO router to connect to internet.

Basics to configure a CISCO router to connect to internet.

Any Cisco router you have around you say Cisco 1000, 1600, 2500, 2600, And 3600 Series Routers. Any cisco router you have the below configurations will be able to workout. These configurations will help you connect your LAN onto internet, Provide basic security to your Local Area Network (LAN) so that no other network connects if not defined in the configs. 
I will go straight to what I have around me to have this configuration done successfully.


1. Router: Cisco 1600 series.
2. ISP Addresses: [IP Address: 192.168.23.11 SubMask: 255.255.255.0 Gateway: 192.168.23.1].
3. LAN Addresses: [IP Address: 10.100.10.1 SubnetMask: 255.255.255.0]
4. Console Cable.
Step 1:
-    Connect your router into power and connect your console cable (will need an RJ-45 to DB-25 adapter). Power up that router without wasting a lot of time.
-    Open up your HyperTerminal: Start -> All Programs -> Accessories -> Communications -> HyperTerminal.
-    You can name anything your “Connection Description” mine is “ictmagazine” and choose 2nd icon.
hyperterminal
-    Press OK , Then on the next interface choose a “COM” port your console is connecting to from the router. Mine was COM3 then press OK.
-    On the next screen restore to defaults “Restore Defaults” and you should be having something similar to that below.Restore Defaults
Then press OK. You should be in your router now.
Well I will avoid you all the boring talk and just dive straight into the really thing “configuring a router to internet”, so let us go straight to step 2.
Please note that the names and password have used those are as per on my router. You can use anything you prefer to make sure your configurations are secure and matching to your standards.
..............Step 2:  Configure Basics
Router>en
Router# config t
Router(config)# hostname ICT
ICT(config)# enable password joinict
ICT(config)# enable secret m@g@z1n3
ICT(config)# ip name-server 208.67.222.222

...............Step 3: Configuring the Line console and vty 0 4
ICT(config)# line console 0
ICT(config-line)# password g3t1n
ICT(config-line)# login
ICT(config-line)# exit

ICT(config)# line vty 0 4
ICT(config-line)# password b0b0ut
ICT(config-line)# login
ICT(config-line)# exit

................Step 4: setting up the LAN interface
ICT(config)# interface Ethernet1/0
ICT(config-if)# Description ICTMAGAZINE LAN
ICT(config-if)# ip address 10.100.10.1 255.255.255.0
ICT(config-if)# ip nat inside
ICT(config-if)# no shutdown
ICT(config-if)# exit

....................Step 5: setting up the INTERNET interface (this interface has IP Addresses provided by Internet provider –ISP)
ICT(config)# interface FastEthernet0/0
ICT(config-if)# Description Broadband Internet
ICT(config-if)# ip address 192.168.23.11 255.255.255.0
ICT(config-if)# ip nat outside
ICT(config-if)# no shutdown
ICT(config-if)# exit


....................Step 6: Configuring NAT and Routing statements.
ICT(config)# ip nat inside source list 1 interface FastEthernet0/0 overload
ICT(config)# ip route 0.0.0.0 0.0.0.0 192.168.23.1

...................Step 7: Configuring the Access-list 1 (This allows the LAN to get connection to the internet).
ICT(config)# access-list 1 permit 10.100.10.0 0.0.0.255

..................Step 8: Run show commands to confirm your configurations
ICT(config)# show interface ethernet1/0 (verify the LAN IP configuration)
ICT(config)# show interface fastethernet 0/0 (verify External/ISP IP configuration and status)
ICT(config)# Show ip route (show your routing statement if its correct)
ICT(config)# show ip nat translations (This is to confirm if your nat statements are right)
ICT(config)# show access-lists (configured access lists)

.................Step 9: Save your router configurations
ICT(config)#wr

Pheeeeeeeewwwwwwwwwww………….atlast we are done! At this point you should be in position to access internet using your cisco router.
There is a lot you can do with your cisco router. Let me know what you want to do on your cisco router. We shall be glad to help you out. All the best guys am out of here to my next issue.

Tuesday, July 1, 2014

This installation of PGP has not been initialized...

Issue

When attempting to open PGP Desktop in a PGP Universal Server managed environment, you receive the following error message and PGP Desktop fails to open:

This installation of PGP has not been initialized or the initialization settings have been deleted or damaged.

Solution


This error can occur when the PGP preference files on the computer have become corrupted on PGP Desktop clients. To resolve this issue, stop the PGP Services and delete the PGP preference files. When PGP Desktop is restarted, the preference files will be automatically re-created.

Use the following steps to delete the PGP preference files:

  1. Stop the PGP services by clicking the PGP Tray icon in the Windows system tray and then click Exit PGP Services.
  2. Browse to the following folder for your operating system:

    Windows XP - C:\Documents and Settings\%user name%\Application Data\PGP Corporation\PGP

    Windows Vista - C:\Users\%user name%\AppData\Roaming\PGP Corporation\PGP

    Windows 7 - C:\Users\%user name%\AppData\Roaming\PGP Corporation\PGP

    Note: If the Application Data/AppData folders are hidden, you must change the folder options for Windows Explorer to show hidden files and folders. In Windows Explorer, click Tools > Folder Options then click the View tab. In the Advanced Settings window, click Show hidden files, folders, and drives then click OK.
  3. Delete the PGPprefs and PGPpolicy files.
  4. Click Start > All Programs > Startup and then select PGPtray.exe
  5. If prompted, enter your license information and authorize the PGP Desktop software.

Sunday, June 29, 2014

530 Relaying not allowed - sender domain not local (530) Exchanger Server



This report is generated by the email server at:

       VBLCHODCSVR01.vattanacbank.local

The message with subject:

       "TESTING"

was not delivered to the following recipients:

Reason:  530 Relaying not allowed - sender domain not local (530)
--------------
Reason:  530 Relaying not allowed - sender domain not local (530)
--------------

E-mail Not deliver, Cos of ISP Relay, or ISP Relay Authenthication