My WordPress Blog

Creating automated replies on mailboxes

Microsoft Exchange Manager -> Toolbox -> Public Folder Management Console

Default public folders -> Find the mailbox you wish to change -> Right click, click “manage settings”.

Add yourself as a user, give highest permission “Owner”. Once done click next.

Once done above step, head over to outlook, find the public folder you wish to change and have permissions for -> Right click properties -> Click “Folder Assistant”

In our scenario we want to automate a templated response to all incoming emailees. So we highlight “all messages” -> Edit Rule -> Template. Here we add our automated response -> SAVE.

4G -> 887 working around L2 Interfaces (vlan connectivity)

For context:

887 router is connected to a 4G modem through a L2 physical interface (switchport access vlan 3) – It has 4 L2 ports only.

Vlan 3 SVI ip address =

4G public IP has been used to create a tunnel directly to one of our corporate sites, configuration for the VPN has been done on both sides, this includes matching crypto keys (isakmp), ospf networking statements and source/destination IPs. Our source, on the 4G side, for the tunnel is (int vlan 3) which is within the same subnet as the 4G box interface – VLAN 3 is an SVI created to provide L3 connectivity to clients, as L2 interfaces cannot be assigned IP addresses


DHCP has been configured on the 887 to hand out ip addresses in the network. with a default-router statment for which is the IP address for int VLAN 1.

So clients connected to the 887 are within the subnet. What I failed to understand is, is how we get clients in OUT of vlan 1 and into vlan 3 to then be routed to the corporate network over the tunnel.

I think this confusion was because the ports are L2 so I was thinking more in sense of L2 switching, where you cannot hop vlans – as that requires routing (L3). But in this case we are using an 887 which is fully capable of ROUTING and is able to route vlans between eachother.

So traffic comes in on vlan 1 destined for the corporate network over the tunnel (say, it hits its default gateway (VLAN 1 SVI). 887 looks in its routing table looking for entries for

The route above was advertised via OSPF over the tunnel. Its next hop is (the tunnel interface). Traffic then gets sent out that tunnel interface and hits the other end ( Then the corporate firewall on the other end routes traffic to its destination through its own routing table.

Bare in mind – Config has to be done on both sides particularly with the VPN configuration and access control – the firewall natively blocks traffic, so it requires permit statements for both the tunnel and the network.

Access control on the 4G side (887 config):

Show ip route:

Remote Site R.Config with explanations

no service pad The packet assembler/disassembler (PAD) service supports X.25 links. This service is on by default, but it is not needed unless your router is using X.25.
  • Service timestamps debug/log uptime. // Log refers to syslog and debug is for debug output. The chosen option here was the syntax “uptime” which configures the debug and syslog output to also show the time since the device was booted. The other option would be ” service timestamps debug/log datetime“. Datetime configures the chosen option either log/debug to show output including the real local time / year / msecs this option isn’t chosen here though. Below is an example of the output:
“service timestamps log uptime”

Service password-encryption – Allows you to encrypt all passwords on your router so they cannot be easily guessed from your running-config. This command uses a very weak encryption because the router has to very quickly decode the passwords for its operation.

Boot-start/end-marker – The boot-start-marker and boot-end-marker flags, which can be seen in Cisco IOS software configuration files, are not CLI commands. These markers are written to configuration files automatically to flag the beginning and end of the boot commands (boot statements). By flagging boot statements, these markers allow the router to more reliably load Cisco IOS images during bootup

Logging buffered – See below for Cisco documentation.

Enable secret 5 – Sets an encrypted password for enable mode.

Enable password 7 – Enable secret takes precedence as it’s more secure:


aaa new-model – To enable AAA, you need to configure the aaa new-model command in global configuration.

aaa group server radius rad_eap + server – Look below for cisco documentation and explanation.

aaa authentication login userlist local

Login Authentication

You can use the aaa authentication login command to authenticate users who want exec access into the access server (tty, vty, console and aux).

Example 1: Exec Access with Radius then Local

Router(config)#aaa authentication login default group radius local

In the previous command:
  • The named list is the default one (default).
  • There are two authentication methods (group radius and local).

All users are authenticated with the Radius server (the first method). If the Radius server does not respond, then the router local database is used (the second method). For local authentication, define the username name and password:

Router(config)#username xxx password yyy

Because the list default in the aaa authentication login command is used, login authentication is automatically applied for all login connections (such as tty, vty, console and aux).




Corporate network is on

Public network is on (I think /16 could be /20)

Task was to configure Meraki MR76 to advertise both the corporate network (on native vlan of 20) and the public network on vlan 45. Meraki requires full cloud connectivity to pull its config, which requires external connectivity i.e., Internet access. Below is a brief outline of things I tried:

  • Configuring the port, the Meraki connected to as a trunk, allowing all vlans and setting the native trunk as 20 (corporate vlan) This allowed the Meraki to receive a DHCP address within the 172.31/16 range HOWEVER it did not have connectivity to the cloud. It did however have full corporate connectivity, tested by pinging edge routers ingress interfaces. HTTP traffic leaving the corp. network requires the use of a proxy, as there are no NAT rules for a scope of addresses in 172.31/16 (Meraki included) only a single static NAT rule for traffic sourced from the proxy server (this is key to finding the solution).
  • Similar to above, I had also tried configuring the trunk’s native vlan to 45 (public/visitor vlan) which isn’t governed by the proxy NOR the firewall, it traverses through a “BT Managed Hub” before entering the WAN. I had full internet connectivity and access to the Meraki dashboard, which was great, until I realised the Meraki was placed in the network which is not the network I need it to advertise. I would imagine there is PAT or dynamic NAT configured on this hub to translate addresses in the network.
  • Configuring the port as an access-port in both vlan 20 and 45 (corp. and public). This essentially had the same outcome as configuring trunk ports.
  • Adding to an existing firewall zone-based policy to permit cloud traffic from the Meraki to the Meraki public cloud. I still believe this was required although I haven’t had the ability to check if this was required or not, as I had configured the additional class map BEFORE I had found the final solution. Within the Wiki is where you’ll find the zone-fw config.

Class-map applied to overall policy-map “INSIDE-TO-OUTSIDE-POLICY”

  • I decided to look, once again, at the running config of the Cisco 4351 (our edge router/firewall) which is where WAN traffic traverses. Because my issue was essentially Internet connectivity on vlan 20 (corporate) I homed in on the NAT config. This is what I saw:
Show ip nat translations – shows the current binding between static LAN addresses and their corresponding public address.

Now, as you can see that’s not a lot of static routes for a company that hosts 1000s of network devices and PAT or dynamic NAT was not configured. Then it hit me, THE PROXY SERVER!! two of these addresses you see above are actually statically assigned to translate the source address of our proxy servers which account for 100s of devices. The Meraki will not hit the proxy server, and therefore NOT have its source address changed, for cloud communication it requires TCP, UDP and ICMP NOT HTTP(s).

Because the Meraki requires cloud connectivity to pull its config, I was tasked with finding out the address it was handed out by DHCP – look below:

DHCP administrator tools

It is named “meraki ap” because I recently changed it. I then created a static route from the ap to a public address:

Confirmed meraki was receiving a static nat entry

Added an extra SSID on the meraki for public wifi using vlan 45 within the network for unfiltered guest traffic also showcasing (on the left) the native config using vlan 20:

See the top right for “android-5” (my phone) using the public wifi.

More still to be done, TBC….

Configuring and Applying Crypto Maps

Last Updated on Mon, 22 Aug 2022 | IPSEC

After configuring crypto access lists and transform sets, you can add them to a crypto map.

Consider the network in Figure 7-12 with two routers that peer over an untrustcd network. Assume that IKJi, crypto access lists, and transform sets are configured and a crypto map is now needed.

Figure 7-12 A Network with a Basic Crypto Map Configuration

San Francisco

San Francisco

Figure 7-12 A Network with a Basic Crypto Map Configuration

Crypto Maap

New York s1:

MAP-TO-NY (crypto map)

MAP-TO-SF (crypto map)

New York s1:

MAP-TO-NY (crypto map)

MAP-TO-SF (crypto map)

In the preceding diagram, Router A’s serial interface to the untrusted network is

A crypto map named MAP-TO-NY is applied to this interface (the configuration commands follow). Likewise, Router B’s serial interface is and has a crypto map called MAP-TO-SF.

The following commands create a crypto map on Router A (for clarity, the context of the IOS prompt is included):

RTA#conf t

Enter configuration commands, one per line. End with CNTL/Z. RTA(config)#crypto map MAP-TO-NY 20 ipsec-isakmp RTA(config-crypto-map)#match address 101

RTA(config-crypto-map)#set transform-set TRANS-ESP TRANS-AH-ESP

RTA(config-crypto-map)#set peer

RTA(config crypto-map)#exit

RTA(config)#int si

RTA(config-if)#crypto map MAP-TO-NY

The command crypto map MAP-TO-NY 20 ipsec-isakmp creates a crypto map entry with a sequence of 20 for a crypto map called MAP-TO-NY (the crypto map is created when its first entry is created ). Although this example contains just one entry, crypto maps may contain multiple entries to designate multiple peers, transform sets, and access lists. The sequence number prioritizes the crypto map entries. As the router compares packets to the crypto map, it examines entries in the order of their sequence number (lower sequence numbers are examined first). For this example, a sequence of 20 was chosen so that future entries may be placed before or after this entry. The keyword ipsec-isakmp indicates that IKE is used to manage the SAs for this entry.

IOTE In addition to IKE, which is specified by the ipsec-isakmp keyword, ciypto maps support two other options: ipsec-manual (IPsec without IKE) and cisco (Cisco’s pre-IPsec encryption feature called Cisco Encryption Technology, or CET). Consult the IOS documentation for configuring ipsec-manual or cisco.

The command match address 101 assigns crypto access lisl 101 to this entry. Outbound packets that match this list are protected with IPsec. Inbound packets that match the reverse logic of the list are expected to be protected.

The command set transform-set TRANS-ESP TRANS-AH-ESP defines the transform sets that are acceptable for protecting the traffic covered by the crypto access list. When negotiating IPsec SAs with the remote peer (Router B), the router proposes transform sets in the order listed by this command (this router’s first choice is the transform set TRANS-ESP). Router A and Router B must agree to use a common transform set (a common set of protocols and algorithms) before an SA can be established. TRANS-ESP and TRANS-AH-ESP are the names of transform sets previously created by the crypto ipsec transform-set command. The transform set names (TRANS-ESP, TRANS-AH-ESP) are locally significant and do not have to be the same on both routers.

The command set peer defines the remote peer, Router B, with which this router builds the IPsec S A and to which it subsequently sends the protected traffic. Multiple peers can be configured by repeating the set peer command. This provides a level of redundancy for when SAs are established: If the first peer is not reachable, the router attempts to establish the SA with the next peer in the entry.

The interface configuration command crypto map MAP-TO-NY applies the crypto map to the router’s Serial 1 interface (selected by the command int si). Like access lists, crypto maps do not do anything until you apply them to an interface. The proper place to apply the crypto map is the interface where the protected traffic exits the router: the interface that points in the direction of the remote peer. In this example. Router A’s Serial 1 interface is the exit point (refer to Figure 7-12).

The following is the corresponding configuration on Router B (only the relevant crypto map lines are shown):

RTB#sh run

Current configuration: hostname RTB

<lines deleted for brevity> I

crypto map MAP-TO-SF 20 ipsec-isakmp match address 102

set transform-set B-TRANS1 B-TRANS2 set peer

interface Seriall ip address crypto map MAP-TO-SF

The crypto access list 102 must be a mirror image of list 101 on Router A, and at least one of the transform sets (B-TRANS1 or B-TRANS2) must match one of Router A’s transform sets (TRANS-ESP and TRANS-AH-ESP). A match means the transform sets share the same protocols (AH, ESP) and algorithms (DES or MD5, for example).

NOTE Crypto access lists arc crypto map elements and interoperate with regular packet-filtering access lists that might exist on an interface. Packets blocked by regular access lists are not processed by IPsec.

Continue reading here: Configuring IPsec SA Lifetimes

Cisco 4451 Capture Monitor

To configure a monitor capture specifying an access list or a class map as the core filter for the packet capture, use the monitor capture command in privileged EXEC mode. To disable the monitor capture with the specified access list or class map as the core filter, use the no form of this command.

monitor capture capture-name {access-list access-list-name | class-map class-map-name}

no monitor capture capture-name {access-list access-list-name | class-map class-map-name}


The following example shows how to define a core system filter using an existing access control list:

Device> enable
Device# configure terminal
Device(config)# ip access-list standard acl1
Device(config-std-nacl)# permit any
Device(config-std-nacl)# exit
Device(config)# exit
Device# monitor capture mycap access-list acl1
Device# end

The following example shows how to define a core system filter using an existing class map:

Device> enable
Device# configure terminal
Device(config)# ip access-list standard acl1
Device(config-std-nacl)# permit any
Device(config-std-nacl)# exit
Device(config)# class-map match-all cmap
Device(config-cmap)# match access-group name acl
Device(config-cmap)# exit
Device(config)# exit
Device# monitor capture mycap class-map classmap1
Device# end

Monitor Capture (interface/control plane)

To configure monitor capture specifying an attachment point and the packet flow direction, use the monitor capture command in privileged EXEC mode. To disable the monitor capture with the specified attachment point and the packet flow direction, use the no form of this command.

monitor capture capture-name { interface type number | control-plane } { in | out | both }

no monitor capture capture-name { interface type number | control-plane } { in | out | both }


The following example shows how to add an attachment point to an interface:

Device> enable
Device# monitor capture mycap interface GigabitEthernet 0/0/1 in
Device# end

The following example shows how to add an attachment point to a control plane:

Device> enable
Device# monitor capture mycap control-plane out 
Device# end

monitor capture clear
To clear the contents of a packet capture buffer, use the monitor capture clear command in privileged EXEC mode.

monitor capture capture-name clear

The following example shows how to set a filter for IPv4 traffic:

Device> enable
Device# monitor capture match mycap ipv4
Device# end

monitor capture start

To start the capture of packet data at a traffic trace point into a buffer, use the monitor capture start command in privileged EXEC mode.

monitor capture capture-name start

monitor capture stop

To stop the capture of packet data at a traffic trace point, use the monitor capture stop command in privileged EXEC mode.

monitor capture capture-name stop

show monitor captureDisplays packet capture details.

Cisco Zone-Based Firewall Policy for Meraki Wireless AP

Zone-based firewall Zone-based firewall is an advanced method of stateful firewall. In stateful firewall, an entry containing source IP address, destination IP address, source Port number and destination Port number, is maintained for the traffic generated by the trusted (private) network in the stateful database. This will only the traffic including the replies for the private (trusted) network using the stateful database. 

Zone-based Firewall procedure:

  1. Create zones and assign an interface to it – In Zone-based firewall, logical zones are created. A zone is assigned to an interface. By default, traffic from one zone to another is not allowed.
  2. Create class-map – After creating a zone, a class-map policy is made which will identify the type of traffic, like ICMP, on which the policies will be applied.
  3. Create policy-map and assign class-map to the policy-map – After identifying the type of traffic in class-map, we have to define what action must be taken on the traffic. The action can be:
    • Inspect: It is same as inspection of CBAC i.e only that traffic will be allowed from the outside network which will be inspected (return traffic of inside (trusted) network.
    • Drop: This is the default action for all traffic. The class-map configured in a policy map can be configured to drop unwanted traffic.
    • Pass: This will allow the traffic from one zone to another. Unlike inspect action, it will not create a session state for a traffic. If we want to allow traffic from the opposite direction, corresponding policy should be created.

The below are the configuration tasks that you need to follow:

  1. Configure Zones.
  2. Assign Router Interfaces to zones.
  3. Create Zone Pairs.
  4. Configure Interzone Access Policy (Class Maps & Policy Maps)
  5. Apply Policy Maps to Zone Pairs.

Task 1 : Configure Zones

zone security INSIDE

Task 2 : Assign Router Interfaces to Zones

interface GigabitEthernet0/0/1

zone-member security INSIDE

Task 3 : Create Zone Pairs

Zone pairs are created to connect the zones. If you want to make two zones to communicate you have to create Zone pairs. In our scenario the traffic flows between :


Task 4 : Configure Interzone Access Policy

Class map sort the traffic based on the following criteria :

1.) Access-group

2.) Protocol

3.) A subordinate class map.

So first we need to create an ACL and associate it with the class map.

ip access-list extended OUTBOUND-INSIDE-MERAKI-MGMT

 remark Next 24 lines – Meraki-Mgmt

permit udp host eq 7351

permit udp host eq 9350

permit udp eq 7351

permit udp eq 9350

permit udp eq 7351

permit udp eq 9350

permit udp eq 7351

permit udp eq 9350

permit tcp host eq 80

permit tcp host eq 443

permit tcp host eq 7734

permit tcp host eq 7752

permit tcp eq 80

permit tcp eq 443

permit tcp eq 7734

permit tcp eq 7752

permit tcp eq 80

permit tcp 443

permit tcp eq 7734

permit tcp eq 7752

permit udp any eq 123

permit udp host eq 53

permit icmp host

permit icmp

class-map type inspect match-any OUTBOUND-INSIDE-MERAKI-MGMT

match access-group name OUTBOUND-INSIDE-MERAKI-MGMT

match protocol tcp

match protocol udp

match protocol icmp

Task 5: Policy-Map Configuration

policy-map type inspect INSIDE-TO-OUTSIDE-POLICY



Task 6 : Apply policy maps to zone pairs

zone-pair security ZP-INSIDE-TO-OUTSIDE source INSIDE destination OUTSIDE

 service-policy type inspect INSIDE-TO-OUTSIDE-POLICY

There we finish the basic configuration of a zone based firewall.


You can use the below commands to perform some basic troubleshooting and verification.

a.) Show commands

show class-map type inspect

show policy-map type inspect

show zone-pair security

b.) Debug Commands

debug policy-firewall detail

debug policy-firewall events

debug policy-firewall protocol tcp

debug policy-firewall protocol udp