Cisco Multilayer Switch+EtherChannel
!
!
!
!
!
!
!
HQ SW1-Cisco-2960-EtherChannel :
!
HQ SW2-Cisco-2960-EtherChannel :
!
The IOS SSL VPN features are definitely lagging behind the ASA SSL VPN, but the basic functionality
is available within IOS SSL VPN. The IOS SSL VPN supports clientless, thin client, and full client modes.
The clientless mode uses a web portal. Thin client augments the web portal with port forwarding
capability. The full client uses the AnyConnect SSL client.
The IOS SSL VPN does not have RDP, telnet, ssh, etc plugin capability that exists in the ASA SSL VPN.
It also does not support the dynamic access policy(DAP) also available in the ASA SSL VPN.
For this example, the router needs to provide a users network secure access to
R1 through an SSL web portal. HTTP acccess, to R1, is provided through a URL link.
HTTPS and SSH access, to R1, is provided by port forwarding.
In a real world example, this type of access could allow emergency access for a network
administrator from any computer.
********************
The first step is to set up the authentication method for the user. The IOS SSL VPN uses the
default AAA method by default.
For this example, we will use local authentication with the commands below :
aaa new-model
aaa authentication login default local
username cisco password cisco
********************
!
!
The next step is to setup the IP and port information for connectivity to the SSL VPN.
The IOS SSL VPN allows the IP to be based on the interface IP of the router or a virtual IP address.
Additionally, the port can be the standard 443/tcp or it can be another manually assigned port.
For this example, we will use the fa1/0 interface of the router and port 8000/tcp.
This is shown below :
webvpn gateway SSL1
hostname SSL1
ip address 192.168.137.100 port 8000
ssl trustpoint TP-self-signed-4294967295
inservice
This is all within the “webvpn context” container.
An example is shown below :
webvpn context SSL
url-list “R1”
heading “R1”
url-text “R1-http” url-value “http://192.168.1.2”
policy group default
url-list “R1”
default-group-policy default
This shows the URL list, R1, being defined and then applied to the policy group, default.
The policy group, default, is then applied to the context with the “default-group-policy” command.
********************
!
!
In a similar manner, the IOS SSL VPN can support port forwarding.
This is shown below :
webvpn context SSL
port-forward “R1”
local-port 5000 remote-server “192.168.1.2” remote-port 443 description “R1 HTTPS”
local-port 5001 remote-server “192.168.1.2” remote-port 22 description “R1 SSH”
policy group default
port-forward “R1” auto-download
default-group-policy default
This portion shows how to forward ports.
When a user uses a web browser to access https://127.0.0.1:5000,
they are redirected to https://192.168.1.2 through the SSL connection.
Similarly, when a users uses an
SSH client to access 127.0.0.1 on port 5001, they are redirected to 192.168.1.2 on port 22.
********************
In the “port-forward” command, notice the “auto-download” parameter.
This causes the port forward connectivity to launch automatically,
instead of requiring the user to click on the “thin client” start button shown below :
The screenshots below show the GUI experience based on the configuration above.
1. The user accesses the web portal at https://192.168.137.100:8000
2. The user logs in and is presented with the web portal
3. At the same time as step 2, the port forwarding window appears with the setting for port forwarding
Below is the full relevant config for the example above :
aaa new-model
!
!
aaa authentication login default local
username cisco password 0 cisco
no ip http server
no ip http secure-server
webvpn gateway SSL1
hostname SSL1
ip address 192.168.137.100 port 8000
ssl trustpoint TP-self-signed-4294967295
inservice
!
webvpn context SSL
ssl authenticate verify all
!
url-list “R1”
heading “R1”
url-text “R1-http” url-value “http://192.168.1.2”
!
!
port-forward “R1”
local-port 5000 remote-server “192.168.1.2” remote-port 443 description “R1 HTTPS”
local-port 5001 remote-server “192.168.1.2” remote-port 22 description “R1 SSH”
!
policy group default
url-list “R1”
port-forward “R1” auto-download
banner “Welcome to the IOS SSL Lab”
default-group-policy default
gateway SSL1
inservice
IBM® WebSphere® Portal V5 provides an environment to build and deploy sophisticated
Web-based applications, called portals. A portal is a Web site that provides users with a single point
of access to Web resources. As e-businesses grow, they roll out more advanced Web applications to a
wider audience. The e-business portal becomes another “face” of the company that serves its customers;
therefore, it is important for the portal to be available and to provide reasonable response times.
The CSS 11000 is designed for HTTP traffic optimization. The switch software adds a Web-based layer to
the switching mechanism. Requests are parsed so that intelligent decisions can be made using information
in IP frames, URLs, and cookies.

Requests coming into the CSS 11000 are distributed across a group of portal servers.
As demand grows, you might decide to add more servers. Because a single portal page is constructed from
many HTTP requests, each portal server can assume part of the load, reducing the page response time.
Also, if one of the portal servers fails, requests can be routed to another server in the group.
When creating a load balancing configuration, you must configure services and content rules.
Services identify the actual individual server, and content rules define the CSS load balancing features.
Configuring services
Create a service for each WebSEAL host and set the keepalive type to http.
With http keepalive, CSS generates an HTTP request and checks the response to see if the service is
still active. If CSS determines that a service is no longer functioning, it removes the service from the
load balancing algorithm.
************************** SERVICE **************************
service WPST01
ip address 192.168.120.61
keepalive type HTTP
active
service WPST02
ip address 192.168.120.63
keepalive type HTTP
active
service WPST03
ip address 192.168.120.65
keepalive type HTTP
activeservice WPST03
Sepcifying content rules
All content rules must exist under an owner. To specify the content rule to match all TCP traffic
on port 80, as shown in listing 2:
1. Set the protocol to be TCP.
2. Set the TCP port to be 80.
3. Add services to content rule to create pool of servers CSS uses for load balancing request for content.
4. Create a virtual IP address for the content rule. Customers use this address to access portal resources.
*************************** OWNER ***************************
owner IBM
content PORTAL
protocol tcp
port 80
add service WPST01
add service WPST02
add service WPST03
vip address 192.168.120.50
active
If your portal application requires that all requests be handled by the same server, you must enable
advanced load balancing for the content rule. The arrowpoint-cookie method enables the content rule to
associate the client to a server based on the unique service identifier of the selected server.
Use the string command to add a service identifier for each service.
Then add the advance-balance command with the arrowpoint-cookie option to the content rule definition.
In Listing 3, the bold text enables advanced load balancing.
Listing 3. Content rule with advanced balancing
************************** SERVICE **************************
service WPST01
ip address 192.168.120.61
keepalive type HTTP
string WPST01
active
service WPST02
ip address 192.168.120.63
keepalive type HTTP
string WPST02
active
service WPST03
ip address 192.168.120.65
keepalive type HTTP
string WPST03
active
*************************** OWNER ***************************
owner IBM
content PORTAL
protocol tcp
port 80
add service WPST01
add service WPST02
add service WPST03
vip address 192.168.120.50
advanced-balance arrowpoint-cookie
active
To have an effective On Demand business, you must be able to adjust quickly to changing conditions.
The combination of the Cisco CSS 11000 and the WebSphere Portal cluster gives portal administrators the
flexibility to easily add additional servers as customer demand increases.

Many Internet Cafe businesses want to offer WiFi access for customers with laptops.
Here the client-server software is not suitable as it is impractical to install the client software on each
customers laptop. In these circumstances the solution is to use “captive portal” software.
This software runs on a PC or WiFi router and can intercept the traffic from the laptop and redirect it to
a “landing page” where the customer is asked for payment or authentication.
Typically the software works as follows:
1. Customer connects to the WiFi network of the Internet Cafe.
2. Customer launches web browser and enters desired site (for example www.indiatimes.com).
3. Customer is redirected to the “landing page” instead of the desired site.
4. Customer is prompted for and enters access code.
5. Customer’s laptop is authenticated for the session time.
6. Customer’s web browser is redirect to desired site (for example www.indiatimes.com).
Inter LAN connectivity is disabled. Host on the Lan will not be allowed to connect to another
host on the Lan. Is is the security measure in place since these devices using UseMyNet software
are more likely to be used in public places. Data Protection is enforced here.
In order to allow internal Lan Connectivity :
Traffic to local networks are blocked by default as most customers require this.
You can edit the file /etc/init.d/umn and remove any or all of the following 3 lines
iptables -A FORWARD -i $LAN -d 10.0.0.0/8 -J REJECT –reject-with icmp-host-prohibited
iptables -A FORWARD -i $LAN -d 172.16.0.0/12 -J REJECT –reject-with icmp-host-prohibited
iptables -A FORWARD -i $LAN -d 192.168.0.0/16 -J REJECT –reject-with icmp-host-prohibited
IPSec involves many component technologies and encryption methods.
Yet IPSec’s operation can be broken down into five main steps:
This five-step process :
The five steps of IPSec for dummies like Mufty:
What type of traffic is deemed interesting is determined as part of formulating a security
policy for use of a VPN. The policy is then implemented in the configuration interface for
each particular IPSec peer.
For example, in Cisco routers and PIX Firewalls, access lists are used to determine the
traffic to encrypt. The access lists are assigned to a cryptography policy;
the policy’s permit statements indicate that the selected traffic must be encrypted, and deny statements
indicate that the selected traffic must be sent unencrypted. With the Cisco Secure VPN Client, you
use menu windows to select connections to be secured by IPSec. When interesting traffic is generated
or transits the IPSec client, the client initiates the next step in the process,
negotiating an IKE phase 1 exchange.
Defining “interesting traffic.”
The basic purpose of IKE phase 1 is to authenticate the IPSec peers and to set up a secure channel
between the peers to enable IKE exchanges. IKE phase 1 performs the following functions:
IKE phase 1 occurs in two modes: main mode and aggressive mode.
These modes are described in the following sections.
Main mode has three two-way exchanges between the initiator and the receiver.
In aggressive mode, fewer exchanges are made, and with fewer packets. On the first exchange,
almost everything is squeezed into the proposed IKE SA values: the Diffie-Hellman public key;
a nonce that the other party signs; and an identity packet, which can be used to verify identity
via a third party.
The receiver sends everything back that is needed to complete the exchange. The only thing left is
for the initiator to confirm the exchange. The weakness of using the aggressive mode is that both sides
have exchanged information before there’s a secure channel. Therefore, it’s possible to “sniff” the wire and
discover who formed the new SA. However, it is faster than main mode.
The purpose of IKE phase 2 is to negotiate IPSec SAs to set up the IPSec tunnel.
IKE phase 2 performs the following functions:
IKE phase 2 has one mode, called quick mode. Quick mode occurs after IKE has established the
secure tunnel in phase 1. It negotiates a shared IPSec policy, derives shared secret keying material
used for the IPSec security algorithms, and establishes IPSec SAs. Quick mode exchanges nonces
that provide replay protection. The nonces are used to generate new shared secret key material and
prevent replay attacks from generating bogus SAs.
Quick mode is also used to renegotiate a new IPSec SA when the IPSec SA lifetime expires.
Base quick mode is used to refresh the keying material used to create the shared secret key based on the
keying material derived from the Diffie-Hellman exchange in phase 1.
If perfect forward secrecy (PFS) is specified in the IPSec policy, a new Diffie-Hellman
exchange is performed with each quick mode, providing keying material that has
greater entropy (key material life) and thereby greater resistance to cryptographic attacks.
Each Diffie-Hellman exchange requires large exponentiations, thereby increasing CPU use
and exacting a performance cost.
After IKE phase 2 is complete and quick mode has established IPSec SAs, information is exchanged via
an IPSec tunnel. Packets are encrypted and decrypted using the encryption specified in the IPSec SA.
IPSec encrypted tunnel.
IPSec SAs terminate through deletion or by timing out. An SA can time out when a
specified number of seconds have elapsed or when a specified number of bytes have passed through
the tunnel. When the SAs terminate, the keys are also discarded. When subsequent IPSec SAs are
needed for a flow, IKE performs a new phase 2 and, if necessary, a new phase 1 negotiation.
A successful negotiation results in new SAs and new keys. New SAs can be established before the
existing SAs expire, so that a given flow can continue uninterrupted.
There are times when you may want to disable password recovery
(for example if someone is working in high secure environment).
Use the following command to disable password recovery
Router(config)#no service password-recovery
WARNING:
Executing this command will disable password recovery mechanism.
Do not execute this command without another plan for
password recovery.
Are you sure you want to continue? [yes/no]: yes
Router(config)#
The above command will disable all access to the ROMMON.
Be careful when using the above command, as there is no way to recover password.
The following message is displayed during boot up when “no service password-recovery”
command is configured.
PASSWORD RECOVERY FUNCTIONALITY IS DISABLED
System Bootstrap, Version 11.1(19)AA, EARLY DEPLOYMENT RELEASE SOFTWARE
(fc1)
…
The IOS Zone-Based Firewall first showed up in 12.4(6)T and the goal was to provide an intuitive
and straightforward policy design approach for multiple interface routers. There was also a desire
to offer a greater level of granularity for the application of such policies. The Zone-Based approach
utilizes CBAC technology and gives you everything you had there, plus more.
In order to configure the Zone-Based Firewall, you define your zones, define your class maps,
define your policy maps, and then define your zone pairs and apply your policy maps to them.
Possible actions for traffic moving between zones is INSPECT, DROP, or PASS. Zone Drop or Pass?
Inspect causes the traffic to be monitored with the IOS stateful packet inspection (think CBAC),
while drop and pass are obvious.
Pass allows the traffic to move between zones with no inspection whatsoever.
Step 1: Define and populate our zones:
configure terminal
!
zone security ZONE_PRIVATE
zone security ZONE_INTERNET
!
interface range fa0/0
description LAN
zone-member security ZONE_PRIVATE
!
interface s0/0
description WAN
zone-member security ZONE_INTERNET
Step 2: Define the class maps that identify traffic that is
permitted between zones:
configure terminal
!
class-map type inspect match-any INTERNET_TRAFFIC
match protocol http
match protocol https
match protocol ftp
match protocol smtp
match protocol pop3
match protocol dns
match protocol ssh
match protocol icmp
match protocol cifs
match protocol echo
match protocol ntp
match protocol bittorrent
match protocol bootpc
match protocol bootps
match protocol rtsp
match protocol vdolive
Step 3: Configure a policy map which specifies the action for the
class map:
configure terminal
!
policy-map type inspect PRIVATE_TO_INTERNET
class type inspect INTERNET_TRAFFIC
inspect
Step 4: Configure the zone pair and apply your policy:
configure terminal
!
zone-pair security ZONE_PRIVATE_INT source ZONE_PRIVATE destination ZONE_INTERNET
service-policy type inspect PRIVATE_TO_INTERNET
Notice how this simple configuration allows for the stateful inspection of our
Internet protocols from the private areas to the Internet.
It also blocks traffic from the Internet heading to the private area unless it is
in response to the inspected traffic
My Configuration in Place :
ip inspect max-incomplete high 900
ip inspect max-incomplete low 800
ip inspect one-minute high 900
ip inspect one-minute low 800
ip inspect udp idle-time 15
ip inspect dns-timeout 10
ip inspect tcp idle-time 900
!
!
zone security inside_zone
zone security outside_zone
zone security dmz_zone
zone security multimedia_zone
zone security voip_zone
zone security peripheral_zone
!
!
class-map type inspect match-any IN_OUT
match protocol http
match protocol https
match protocol ftp
match protocol smtp
match protocol pop3
match protocol bootpc
match protocol bootps
match protocol icmp
match protocol msnmsgr
match protocol ntp
match protocol ssh
match protocol telnet
match protocol cifs
match protocol dns
match protocol tcp
match access-group name WORKSTATION_NAT
match access-group name PC-techAPDMZ_NAT
!
policy-map type inspect IN_OUT
class type inspect IN_OUT
inspect
class class-default
drop
!
zone-pair security IN->OUT source inside_zone destination outside_zone
service-policy type inspect IN_OUT
!
!
class-map type inspect match-any VOIP_OUT
match protocol udp
match access-group name VOIP_NAT
!
policy-map type inspect VOIP_OUT
class type inspect VOIP_OUT
inspect
class class-default
drop
!
zone-pair security VOIP->OUT source voip_zone destination outside_zone
service-policy type inspect VOIP_OUT
!
!
class-map type inspect match-any DMZ_OUT
match protocol http
match protocol https
match protocol ftp
match access-group name DMZ_NAT
!
policy-map type inspect DMZ_OUT
class type inspect DMZ_OUT
inspect
class class-default
drop
!
zone-pair security DMZ->OUT source dmz_zone destination outside_zone
service-policy type inspect DMZ_OUT
!
!
class-map type inspect match-any MULTIMEDIA_OUT
match protocol bittorrent
match protocol http
match protocol https
match protocol ftp
match protocol echo
match protocol smtp
match protocol pop3
match protocol icmp
match protocol pptp
match protocol tcp
match protocol udp
match access-group name MULTIMEDIA_NAT
!
policy-map type inspect MULTIMEDIA_OUT
class type inspect MULTIMEDIA_OUT
inspect
class class-default
drop
!
zone-pair security MULTIMEDIA->OUT source multimedia_zone destination outside_zone
service-policy type inspect MULTIMEDIA_OUT
!
!
class-map type inspect match-any IN_MULTIMEDIA
match protocol cifs
match protocol tcp
match access-group name WORKSTATION_NAT
!
policy-map type inspect IN_MULTIMEDIA
class type inspect IN_MULTIMEDIA
inspect
class class-default
drop
!
zone-pair security IN->MULTIMEDIA source inside_zone destination multimedia_zone
service-policy type inspect IN_MULTIMEDIA
!
!
class-map type inspect match-any IN_PERIPHERAL
match protocol tcp
!
policy-map type inspect IN_PERIPHERAL
class type inspect IN_PERIPHERAL
inspect
class class-default
drop
!
zone-pair security IN->PERIPHERAL source inside_zone destination peripheral_zone
service-policy type inspect IN_PERIPHERAL
!
!
class-map type inspect match-any PERIPHERAL_IN
match protocol tcp
match access-group name PERIPHERAL_INSPECT
!
policy-map type inspect PERIPHERAL_IN
class type inspect PERIPHERAL_IN
inspect
class class-default
drop
!
zone-pair security PERIPHERAL->IN source peripheral_zone destination inside_zone
service-policy type inspect PERIPHERAL_IN
!
!
Interface fa0/1.3
Zone-member security inside_zone
!
Interface fa0/1.4
Zone-member security inside_zone
!
Interface vlan 2
Zone-member security multimedia_zone
!
Interface vlan 10
Zone-member security dmz_zone
!
Interface fa0/0
Zone-member security outside_zone
Troubleshooting :
The point of the qos pre-classify command is to be able to read and manipulate the IP header
of a packet going through a VPN.
The problem is that when a packet enters a VPN it is encrypted, header and all.
After this command is applied, the router makes a copy of the original IP header so that you can
perform QoS manipulation at egress on an interface.
Actually if the ToS byte (DSCP, ECN or IP Precedence) is the only portion of the header that needs
manipulation. You don’t need qos pre-qualify, however, if you need access to source or destination
ip address or port numbers, then you need the qos pre-qualify command.
Packets entering a router interface, not yet in a VPN tunnel, can be processed with
ingress QoS features on that interface just like always.
Packets exiting a router interface, after encapsulation and encryption by that router into a
VPN tunnel, cannot be processed with egress QoS features on that interface just like always.
The Egress QoS features can only examine the post-encapsulation IP header.
That is why qos pre-classify makes a copy of the original IP header.
The command qos pre-classify turns on pre-classification and is restricted to
tunnel interfaces, virtual templates, and crypto maps,
it is not available on any other interface type.
Apply the policy to a physical interface and enable qos-preclassify on a tunnel interface
when you want to classify packets based on the pre-tunnel header.
Cisco recommends Preclassify over simple ToS Preservation anytime you want to match on
the ToS byte only, or the ToS byte and other parameters like Source and Destination ports,
Preclassify is always recommended in Security/QoS environments.
QoS for VPNs feature. This feature is enabled with the qos pre-classify.
Remember that a packet is encrypted in the vpn process, so the pre-clasify will mark the packets
so they can apply the service policy and prioritise voice,video or whatever traffic.
I performed a packet capture, and, as expected, i only see :
ESP packets with the DSCP value set at 0.
Place qos pre-classify command in the crypto map.
crypto map vpn 10 ipsec-isakmp
qos pre-classify
These are the guidelines for implementing QoS :
Control Plane Policing
The control plane of a Cisco router includes the data plane, management plane and service plane.
Control plane policing allows you to build QoS filters to protect the router against DoS attacks.
2 sites Cisco routers terminating vpn on a linux firewall.
See configuration of 2 cisco router as well as linux firewall.
!
!
HQ advertising 2 internal networks :
128.0.0.0/16
10.0.0.0/16
Remote site advertising 1 internal network :
128.0.0.0/16
Cisco HQ IPSEC VPN Config :
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key ahdbpr0t3ct address 80.74.16.223
!
crypto ipsec transform-set secure esp-3des esp-md5-hmac
!
crypto map armadillo 1 ipsec-isakmp
set peer 80.74.16.223
set transform-set secure
match address 101
!
crypto map armadillo 2 ipsec-isakmp
set peer 80.74.16.223
set security-association lifetime seconds 28800
set security-association idle-time 86400
set transform-set secure
match address 102
!
access-list 101 permit ip 128.0.0.0 0.0.255.255 128.0.0.0 0.255.255.255
access-list 102 permit ip 10.0.0.0 0.0.255.255 128.10.0.0 0.0.255.255
!
interface FastEthernet0/0
description WAN-Interface
ip address 213.121.189.250 255.255.255.0
crypto map armadillo
!
interface vlan 1
description MLC vlan
ip address 128.0.15.250 255.255.0.0
!
interface vlan 2
description AHDB vlan
ip address 10.0.15.1 255.255.0.0
!
!
Cisco RemoteSite IPSEC VPN Config :
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key ahdbpr0t3ct address 80.74.16.223
!
!
crypto ipsec transform-set secure esp-3des esp-md5-hmac
!
crypto map securewan 1 ipsec-isakmp
set peer 80.74.16.223
set security-association lifetime seconds 28800
set security-association idle-time 86400
set transform-set secure
match address VPN
!
ip access-list extended VPN
permit ip 128.10.0.0 0.0.255.255 128.0.0.0 0.0.255.255
permit ip 128.10.0.0 0.0.255.255 10.0.0.0 0.0.255.255
!
interface Dialer0
ip address 80.74.22.136 255.255.255.0
crypto map securewan
!
!
Linux Firewall Configuration :
Directory path of ipsec conf file ( /etc/ipsec/site name)
!
HQ Network : 128.0.0.0/16 & 10.0.0.0/16
!
128.0.0.0/16 to HQ 128.0.0.0/16
10.0.0.0/16 to HQ 128.0.0.0/16
conn HQ1
left=80.74.16.223
leftsubnet=128.0.0.0/16
right=213.121.189.250
rightsubnet=128.0.0.0/16
type=tunnel
authby=secret
auth=esp
esp=3des-md5-96
keyexchange=ike
ikelifetime=24h
keylife=28800s
keyingtries=3
pfs=no
rekey=yes
auto=start
dpdaction=restart
dpddelay=15
dpdtimeout=60
!
conn HQ2
left=80.74.16.223
leftsubnet=128.10.0.0/16
right=213.121.189.250
rightsubnet=10.0.0.0/16
type=tunnel
authby=secret
auth=esp
esp=3des-md5-96
keyexchange=ike
ikelifetime=24h
keylife=28800s
keyingtries=3
pfs=no
rekey=yes
auto=start
dpdaction=restart
dpddelay=15
dpdtimeout=60
!
!
RemoteSite Network : Access to HQ Network :
128.0.0.0/16 to HQ 128.0.0.0/16
128.0.0.0/16 to HQ 10.0.0.0/16
conn remotesite1
left=80.74.16.223
leftsubnet=128.0.0.0/16
right=80.74.22.136
rightsubnet=128.10.0.0/16
type=tunnel
authby=secret
auth=esp
esp=3des-md5-96
keyexchange=ike
ikelifetime=24h
keylife=28800s
keyingtries=3
pfs=no
rekey=no
auto=start
dpdaction=restart
dpddelay=15
dpdtimeout=60
!
conn remotesite2
left=80.74.16.223
leftsubnet=10.0.0.0/16
right=80.74.22.136
rightsubnet=128.10.0.0/16
type=tunnel
authby=secret
auth=esp
esp=3des-md5-96
keyexchange=ike
ikelifetime=24h
keylife=28800s
keyingtries=3
pfs=no
rekey=yes
auto=start
dpdaction=restart
dpddelay=15
dpdtimeout=60
Configure Linux Firewall Iptables to forward traffic from RemoteSite over to HQ.
sudo iptables -I FORWARD -s 128.0.0.0/16 -d 128.0.0.0/16 -j ACCEPT
sudo iptables -I FORWARD -s 128.0.0.0/16 -d 10.0.0.0/16 -j ACCEPT
Configure Linux Firewall Iptables to forward traffic from HQ to RemoteSite.
sudo iptables -I FORWARD -s 128.0.0.0/16 -d 128.0.0.0/16 -j ACCEPT
this one is configured in a previous rule as above.
!
sudo iptables -I FORWARD -s 10.0.0.0/16 -d 128.0.0.0/16 -j ACCEPT
This output shows an example of creating a time-based named ACL.
It denies HTTP traffic on Monday through Friday between the hours of 8:00 am and 6:00 pm
and allows UDP traffic on Saturday and Sunday from noon to 8:00 pm.
!
time-range no-http
periodic weekdays 8:00 to 18:00
!
time-range udp-yes
periodic weekend 12:00 to 20:00
!
ip access-list extended strict
permit tcp any any eq http time-range no-http
permit udp any any time-range udp-yes
!
!
Keep in mind there is an explicit deny at the end of the ACL. If you are going to permit ip any any
at the bottom of ACL, keep in mind that there has to be a deny entry for tcp HTTP traffic. This is because
when time-range no http ACL is in inactive state, it looks for a matching rule that will either permit or deny HTTP traffic.
!
Example of using a time-based ACL in QoS Policy:
!
class-map Traffic_Class
match access-group strict
!
policy-map QoS-Policy
class Traffic_Class
priority 500
class class-default
fair-queue