The purpose of this tutorial is to introduce some OpenVPN basics. We will be configuring an OpenVPN server running on Linux, and then one client that has all it’s traffic re-directed through the tunnel. This may be useful to some readers to bypass any restrictions on internet access they may be faced with. This tutorial is based on an Ubuntu server and a Windows Client.

Server setup

The first thing we are going to do is to set-up the server. Install the relevant software -:

server# sudo aptitude install openvpn

Now copy the example configs and more importantly the easy-rsa scripts into /etc -:

server# cp -R /usr/share/doc/openvpn/examples/ /etc/openvpn

Now we want to load the vars file with our own defaults. Open the file in your favorite editor and change KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL to match your information.

cd /etc/openvpn/examples/easy-rsa/
vi ./vars

My vars file looks like this: (key components only)

#this is to ensure secure data
export KEY_SIZE=2048
# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY=UK
export KEY_PROVINCE=Adminville
export KEY_CITY=Adminland
export KEY_ORG=remoteadmin.org.uk
export KEY_EMAIL="nospam@netwizards.co.uk"

Now we to begin the configuration of the server.

. ./vars
./clean-all
./build-ca

The purpose of these command are as follows, the first one will clear any old keys or configuration elements, there should not be any there but it does not hurt to be sure. The last command will setup OpenVPN configuration items, be sure to follow the prompt and make sure you fill in using elements to match your situation. Since we loaded the vars file with your settings prior to these steps the default values should work on almost all elements, but the Common Name will need to be specified.

Now you need to create the server keys, these are private files that you should keep secure.

./build-key-server server

I found that if I did not use the same information that I used in the build-ca step above that the “Sign Certificate” and “commit” did not work. If you experience this problem just repeat this step with the same values, it should work at that point. This should not occur for you as we have loaded the default values into the vars file, but just in case be aware of the cause.

Now you are ready to generate keys for users, first decide if you wish to password protect the keys or not. I recommend building with passwords if you are not going to implement authentication in OpenVPN, if you are then simply generate without. This tutorial will assume that you are going to implement authentication in OpenVPN, since it is the most trusted method. Make sure that you specify the correct Common Name when prompted.

#Generate with password
./build-key-pass username
#Generate without password
./build-key username

Now you need to build the Diffie Hellman parameters, for details on what these are simply check the OpenVPN homepage. The simple answer is that they provide a method to negotiate a secure connection over an insecure channel. This process will take a bit of time so you may want to take a break, just relax we are almost there.

./build-dh
#generate server id key
openvpn --genkey --secret ta.key

As an aside I found a very interesting table on the OpenVPN web-page. It provides some information on what to do with the various files we just generated. For the purposes of this tutorial I have “borrowed” their table and pasted it here, to view the original visit the OpenVPN installation guide on their homepage.

Ok, the last step for the server set-up is the actual server config file. This is the configuration I finally settled on -:

port 1194
proto udp
dev tun
ca keys/ca.crt                          # The CA certificate
cert keys/server.crt                    # The server certificate
key keys/server.key                     # This file should be kept secret
dh keys/dh1024.pem
server 172.16.1.0 255.255.255.0         # Subnet to be used by clients
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"            # We want to redirect the client gateway to us
push "dhcp-option DNS 208.67.222.222"   # Specify a DNS server for the clients
keepalive 10 120                        # Keepalives for the tunnels
;comp-lzo                               # Uncomment this to enable lzo compression
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3
mute 20

Client Set-up

Ok so we now have our working server waiting for clients to connect. So now we want to create the client config. Firstly though, generate the certificates for the first client -:

./build-key client1

You will then need to copy ca.crt, client1.crt, and client1.key onto the client machine.

No for the client OpenVPN config, this is a simple config that I use -:

remote ip.ad.re.ss 1194
proto udp
ca ca.crt
cert client1.crt
key client1.key
;comp-lzo       # Uncomment this to enable lzo compression
verb 3
mute 20
resolv-retry infinite
nobind
client
dev tun
persist-key
persist-tun

References -:

http://www.thebakershome.net/openvpn_tutorial

Initial setup

I am starting from the point where I already have a working T1 connection. So the first thing to do is to configure the actual dial-up connection.

So firstly setup the async interface, in my case it was async2

interface Async2
 ip address negotiated
 encapsulation slip
 dialer in-band
 dialer pool-member 1
 async dynamic routing
 async mode interactive 

Next configure up a dialler interface

interface Dialer0
 ip address negotiated
 ip nat outside
 encapsulation ppp
 dialer pool 1
 dialer idle-timeout 300
 dialer string 12093361010
 dialer-group 11
 no cdp enable 

Configure your LAN interface for NAT

interface FastEthernet0                                       
 ip nat inside

Now configure your chat script

chat-script sillyman "" "atdt 12093361010" TIMEOUT 60 "CONNECT"

And your NAT overload statement, access-list, and dialler-list

dialer-list 11 protocol ip permit
access-list 101 permit ip 192.168.1.0 0.0.0.255 any
ip nat inside source list 101 interface Dialer0 overload 

Configure up the line interfaces

line 2
 modem InOut
 modem autoconfigure discovery
 stopbits 1
 speed 115200
 flowcontrol hardware

Now tell your serial interface about your dial-up backup interface

int serial0
 backup delay 10 10
 backup interface Dialer0 

Setting up the access-lists

I always tend to call my router/firewall access-lists the same thing, one called inside_out, and one called outside_in. These names describe the function of the two lists exactly. The first is concerned with traffic coming from inside the firewall (your LAN) going out. And the second is concerned with traffic coming into your LAN from outside.

inside_out access-list

Ok let’s just create a very open list here, the purpose of this tutorial is how to use reflexive lists, not how to create access-lists in general. So we’ll just have the following -:

ip access-list extended inside_out permit ip any any reflect outbound 

All we are doing here is creating a list that allows any traffic out and creates a reflexive access-list called outbound. This reflexive list is dynamically updated to allow return traffic to connections initiated from inside your LAN.

outside_in access-list

Again this is a very simple access-list with some good defaults in  -:

ip access-list extended outside_in evaluate outbound deny ip 127.0.0.0 0.255.255.255 any deny ip 224.0.0.0 31.255.255.255 any deny ip host 255.255.255.255 any deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any  permit icmp any any echo-reply permit icmp any any unreachable permit icmp any any time-exceeded
deny ip any any log

This list evaluates the reflexive list created by the inside_out access-list, and contains statements to allow return traffic, we can then deny all.

You can check the current reflexive list by typing -:

 sh access-lists

Apply the lists to your outside interface

In my case serial0 is my outside interface, so -:

interface Serial0 ip access-group outside_in in ip access-group inside_out out

Preparing your domain for DNSSEC and signing it is a fairly straightforward task. In this post I will be signing one of my domains, and publishing the new signed domain. I am working on an install based on the following -:

BIND home – /chroot/named
BIND config – /chroot/named/etc
Zone files – /chroot/named/etc/pri

Preparing and generating DNSSEC keys

Firstly create a folder to keep all of your key files in, in my case I chose /chroot/named/etc/keys

mkdir /chroot/named/etc/keys
chown bind.bind /chroot/named/etc/keys
cd /chroot/named/etc/keys

Next you need to tell BIND where your keys are stored, so add the following in named.conf

key-directory "/etc/keys";

Now generate key files for the domain you are signing -:

dnssec-keygen -a rsasha1 -b 1024 -n zone netwizards.co.uk 
dnssec-keygen -k -a rsasha1 -b 1024 -n zone netwizards.co.uk

Add keys to zone file

Now you need to add the key information to your zone file, this is simply achieved with one command (replacing the paths to suit your install) -:

cat Knetwizards.co.uk.*.key >> /chroot/named/etc/pri/netwizards.co.uk

Sign your zone

Now you can sign your zone, again this a fairly painless process -:

cd /chroot/named/etc/pri
dnssec-signzone -t -g -o netwizards.co.uk netwizards.co.uk \
   /chroot/named/etc/keys/Knetwizards.co.uk.+005+21018.private

If you get an error at this point you are using the wrong key file, you will have two to choose from so just try the other.

Publish the zone file

Now that you have signed your zone, you need to publish the signed zone, simple add .signed to the end of the zone filename in your zone definition. I have also added an update-policy to enable secure updates via nsupdate -:

zone "netwizards.co.uk" IN {
   type master;
   file "pri/netwizards.co.uk.signed";
   update-policy {
      grant netwizards.co.uk subdomain netwizards.co.uk. any;
   };
};

That’s it, restart bind and if you have any slave servers, they don’t need any work, they will just publish what the master tells them.

Initial setup

I am starting from the point where I already have two working routers that can ping each other. R1 has an IP address of 192.168.1.252 and R2 has an IP address of 192.168.2.253. R1 can ping R2 and vice versa. These two routers connect to a switch, the switch also has a PC connected with IP address 192.168.1.1 and a gateway address of 192.168.1.254.

This is our base starting point, see diagram below.

The purpose of this exercise is to create the PC’s gateway address, 192.168.1.254, as a virtual address on the two routers, so if one router goes down, the other will take over the gateway address and the PC will not lose connectivity. We have setup a test 100.100.100.1 destination address for testing purposes. It is beyond the scope of this tutorial to explain how anything in the green circle on the diagram is configured.

Configuring the interfaces on R1 and R2

The interface f0/0 on R1 and R2 have an extremely simple initial configuration, on R1 we have -:

interface FastEthernet0/0  ip address 192.168.1.252 255.255.255.0  duplex full

And on R2 we have -:

interface FastEthernet0/0  ip address 192.168.1.253 255.255.255.0  duplex full

To get HSRP up and running only requires one simple command on each router, on R1 and R2 we need to add the following to get HSRP, in it’s most basic form, up and running -:

interface FastEthernet0/0 standby ip 192.168.1.254

That’s it, the routers are now configured for HSRP, wasn’t that easy?

Confirm HSRP is working correctly

We really should check to see what HSRP is doing and if it is working properly, so on R1 run the command sh standby f0/0 and examine the output.

FastEthernet0/0 - Group 0
State is Active
5 state changes, last state change 00:00:15
Virtual IP address is 192.168.1.254
Active virtual MAC address is 0000.0c07.ac00
Local virtual MAC address is 0000.0c07.ac00 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.000 secs
Preemption disabled
Active router is local
Standby router is 192.168.1.253, priority 100 (expires in 8.648 sec)
Priority 100 (default 100)
IP redundancy name is "hsrp-Fa0/0-0" (default)

From the output we can see that the ‘Active Router’ is local (e.g. R1 itself) and the ‘Standby Router’ is 192.168.2.153 (R2). Now if we shut down interface F0/0 on R1, we can simulate what happens in the event of a link failure. So do that now and examine the output of the sh standby f0/0 on R2.

FastEthernet0/0 - Group 0
State is Active
5 state changes, last state change 00:00:24
Virtual IP address is 192.168.1.254
Active virtual MAC address is 0000.0c07.ac00
Local virtual MAC address is 0000.0c07.ac00 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.260 secs
Preemption disabled
Active router is local
Standby router is unknown
Priority 100 (default 100)
IP redundancy name is "hsrp-Fa0/0-0" (default)

So we now see the R2 is reporting itself as the ‘Active Router’ and the ‘Standby Router’ is unknown, which makes sense as the interface on R1 is currently down. From the PC you would have noticed a few dropped pings while R2 took over the virtual IP address, but connectivity would have been restored rather quickly.

Congratulations, you now have a fully redundant router set-up for the default gateway on your network! Remember, this is only very basic HSRP functionality, a later tutorial will explore HSRP a little further and investigate some of the more advanced functions available.

Google is the single most important search engine in the world today, practically all web users will use Google before any other search engines.

A full fledged SEO industry is running on the google pagerank algorithm decided by Google Inc.

I have seen a lot of developers asking the method of getting google pagerank using php.

The Google search results are ranked by page rank.

We are going to use PHP class “Google PR” from phpclasses.org

Download the class from here.

<?
//Include and instansiate the class
include_once("class.googlepr.php");
$rank = new GooglePR();
//Query the PR value for a url
echo "PageRank - " . $rank->GetPR("http://www.test.com/") . "\n";
?>

Simples!

This guide provides instruction on how to set-up a Juniper Netscreen firewall via SSH or console to allow clients to connect using the shrew.net IPSEC client.

Overview

This configuration described below will allow an IPSEC VPN client to communicate with a single subnet located behind the Juniper firewall. The client will use the push configuration method to acquire it’s appropriate IP addressing parameters from the gateway.

Netscreen Configuration

This guide assumes you have your Juniper configured with a public IP and a private subnet range behind it you want to connect to remotely, it also assumes that this much is already configured, for more information about this consult your Juniper documentation.

Configure VPN user IDs and IP Pool for clients

First we want to create a user and assign that user to a group, this user will be used to log into the VPN using Xauth, you can create as many users as you need. We also need to define an IP range for the connecting clients.

set user "test1" uid 7
set user "test1" type  auth xauth
set user "test1" password "password"
set user "test1" "enable"
set user-group "VPN-Users" id 3
set user-group "VPN-Users" user "test1"
set ippool "VPNClients" 172.16.255.10 172.16.255.254

Configure the IPSEC Phase 1 parameters

Firstly create a user that is used to define the phase 1 ID parameters.

set user "vpn-ikeuser" uid 4
set user "vpn-ikeuser" ike-id fqdn "vpn.netwizards.co.uk" share-limit 10
set user "vpn-ikeuser" type  ike
set user "vpn-ikeuser" "enable"

Next, create a group that can be assigned to an Auto Key Advanced Gateway and put the IKE user in it.

set user-group "XAuth-Global" id 2
set user-group "XAuth-Global" user "vpn-ikeuser"

Create an Auto Key Advanced Gateway

Now we need to create an auto key advanced gateway which will be used to configure the phase 1 IPSEC parameters, we specify a pre-shared key, enable nat-traversal, associate the IKE user group created above, and finally assign the VPN-Users groups in the Xauth parameters to allow our users to login. Also bind out client IP pool to the xauth.

set ike gateway "ras-gw" dialup "XAuth-Global" Aggr outgoing-interface "untrust" \
    preshare "SUPERSECRETKEY" proposal "pre-g2-aes128-sha"
set ike gateway "ras-gw" nat-traversal udp-checksum
set ike gateway "ras-gw" nat-traversal keepalive-frequency 5
set ike gateway "ras-gw" xauth server "Local" user-group "VPN-Users"
unset ike gateway "ras-gw" xauth do-edipi-auth
set xauth lifetime 5
set xauth default ippool "VPNClients"

Create a Tunnel interface and bind this to the Trusted side of the firewall

The tunnel interface will be used to bind the VPN clients to the trusted side of the firewall.

set interface "tunnel.1" zone "Trust"
set interface tunnel.1 ip unnumbered interface trust

Create an Auto Key IKE Gateway

Specify the proposal, bind to the Auto Key Advanced Gateway created above,  bind to our tunnel interface, and set the proxy-id which contains the private subnet our clients would like to connect to.

set vpn "ras-vpn" gateway "ras-gw" no-replay tunnel idletime 1440 \
    proposal "nopfs-esp-aes128-sha"
set vpn "ras-vpn" id 10 bind interface tunnel.1
set l2tp default ppp-auth chap
set vpn "ras-vpn" proxy-id local-ip 172.16.3.0/24 remote-ip 255.255.255.255/32 "ANY"

Route the VPN client subnet out through the tunnel interface

Finally we need to tell the Netscreen to route the VPN client subnet out of the tunnel interface.

set route 172.16.255.0/24 interface tunnel.1 preference 20

Shrew VPN Client Settings

TO-DO

Fortunately you can execute checks via SSH instead. The first step to getting this working is to enable to Nagios server to access the remote server via SSH without a password. This requires creating a SSH kaypair for the Nagios user on the Nagios server -:

su nagios
ssh-keygen -t rsa

Make sure you do not enter a passphrase when prompted.  Now you need to copy the id_rsa.pub created to the remote server you need to login to -:

scp ~/.ssh/id_rsa.pub user@nagios.host:~/.ssh/authorized_keys

You should now be able to SSH to the remote server without providing a password. Obviously you should now make sure you Nagios server is adequately protected as it can access your other server without needing a password.

On the central Nagios server, in the commands.cfg configuration file, define the new checks. The example below defines a new check_ssh_load command:

# 'check_ssh_load' command definition
define command {
        command_name    check_ssh_load
        command_line    $USER1$/check_by_ssh -H $HOSTADDRESS$ -C "/home/user/bin/check_load
        -w $ARG1$ -c $ARG2$"
}

This command will call the check_by_ssh plugin to connect to the specified host (via the $HOSTADDRESS$ macro) and execute the command /home/user/bin/check_load, which is the check_load plugin, on the remote machine; you will need to adjust the path to match the location of that plugin on the remote server. As well, if paths and/or usernames differ on remote servers and you plan to monitor more than one, you may need to define multiple commands, one for each server (or use macros).

Next, edit services.cfg and add the following:

define service {
       use                             local-service
       hostgroup_name                  ssh-nagios-services
       service_description             Current Load
       check_command                   check_ssh_load!5.0,4.0,3.0!10.0,6.0,4.0
}

This defines a new service to execute for hosts in the ssh-nagios-services hostgroup. It calls the defined check_ssh_load command and will put the service in a warn state if the load average hits 5, and a critical state if it hits 10 (adjust to suit, of course).

Finally, edit hostgroups.cfg to create the ssh-nagios-services hostgroup. Systems added to this hostgroup will automatically begin to use the defined service.

define hostgroup {
        hostgroup_name  ssh-nagios-services
        alias           Nagios over SSH
        members         remote1,remote2
}

Here we define that remote1 and remote2 both belong to this hostgroup. As a result, both will start using the check_ssh_load command.

Using check_by_ssh is a convenient and secure way to execute Nagios plugins on remote servers. When all you can see of the status of a remote server is HTTP or SMTP availability, your view of the server is quite restricted. Being able to see local resource usage can allow you to spot problems, and correct them, before they are visible to users.

Initial setup

I am starting from the point where I already have a two working routers that can ping each other. R1 has an IP address of 192.168.1.1/24 and R2 has an IP address of 192.168.1.2/24. R1 can ping R2 and vice versa. R1 has a loopback interface with IP address 10.10.10.1/24 and R2 has a loopback interface with IP address 20.20.20.1/24 This is our base starting point.

Initial routing tables

The first thing we are going to do is check the routing tables of R1 and R2. On R1 we have -:

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, Loopback0
C    192.168.1.0/24 is directly connected, FastEthernet0/0

And on R2 we have -:

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     20.0.0.0/24 is subnetted, 1 subnets
C       20.20.20.0 is directly connected, Loopback0
C    192.168.1.0/24 is directly connected, FastEthernet0/0

Not that the routing tables only contain directly connected subnets as we have not yet configured a routing procotol

Configure OSPF

Now to configure OSPF on both routers, we need the same config on both, this is -:

router ospf 100 log-adjacency-changes network 192.168.1.0 0.0.0.255 area 0 

Now we have OSPF configured, you should see the OSPF adjacency come up on both routers -:

*Mar 1 00:25:41.531: %OSPF-5-ADJCHG: Process 100, Nbr 20.20.20.1 on
fastEthernet0/0 from  LOADING to FULL, Loading Done

Now that we have OSPF up and running, you will notice that the routes for the loopback interfaces are not being sent to the other router. So we to fix this we need to add some config to the OSPF configuration on both routers -:

router ospf 100 redistribute connected subnets 

This command will tell the routers to redistribute connected subnets into OSPF, so if we examine the routing tables now you should see -:

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     20.0.0.0/24 is subnetted, 1 subnets
O E2    20.20.20.0 [110/20] via 192.168.1.2, 00:20:51, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.10.10.0 is directly connected, Loopback0
C    192.168.1.0/24 is directly connected, FastEthernet0/0

Note we now have an OSPF route to R2′s loopback subnet on R1.

Thats it for this tutorial, further tutorials will explore more advanced options of OSPF

!--- Add anti-spoofing entries.

!--- Deny special-use address sources.

!--- Refer to RFC 3330 for additional special use addresses.

access-list 110 deny ip 127.0.0.0 0.255.255.255 any

access-list 110 deny ip 192.0.2.0 0.0.0.255 any

access-list 110 deny ip 224.0.0.0 31.255.255.255 any

access-list 110 deny ip host 255.255.255.255 any

!--- The deny statement should not be configured

!--- on Dynamic Host Configuration Protocol (DHCP) relays.

access-list 110 deny ip host 0.0.0.0 any

!--- Filter RFC 1918 space.

access-list 110 deny ip 10.0.0.0 0.255.255.255 any

access-list 110 deny ip 172.16.0.0 0.15.255.255 any

access-list 110 deny ip 192.168.0.0 0.0.255.255 any

!--- Permit Border Gateway Protocol (BGP) to the edge router.

access-list 110 permit tcp host bgp_peer gt 1023 host router_ip eq bgp

access-list 110 permit tcp host bgp_peer eq bgp host router_ip gt 1023

!--- Deny your space as source (as noted in RFC 2827).

access-list 110 deny ip your Internet-routable subnet any

!--- Explicitly permit return traffic.

!--- Allow specific ICMP types.

access-list 110 permit icmp any any echo-reply

access-list 110 permit icmp any any unreachable

access-list 110 permit icmp any any time-exceeded

access-list 110 deny   icmp any any

!--- These are outgoing DNS queries.

access-list 110 permit udp any eq 53  host primary DNS server gt 1023

!--- Permit older DNS queries and replies to primary DNS server.

access-list 110 permit udp any eq 53  host primary DNS server eq 53

!--- Permit legitimate business traffic.

access-list 110 permit tcp any Internet-routable subnet established

access-list 110 permit udp any range 1 1023 Internet-routable subnet gt 1023

!--- Allow ftp data connections.

access-list 110 permit tcp any eq 20 Internet-routable subnet gt 1023

!--- Allow tftp data and multimedia connections.

access-list 110 permit udp any gt 1023 Internet-routable subnet gt 1023

!--- Explicitly permit externally sourced traffic.

!--- These are incoming DNS queries.

access-list 110 permit udp any gt 1023 host <primary DNS server> eq 53

!-- These are zone transfer DNS queries to primary DNS server.

access-list 110 permit tcp host secondary DNS server gt 1023 host primary DNS server eq 53

!--- Permit older DNS zone transfers.

access-list 110 permit tcp host secondary DNS server eq 53  host primary DNS server eq 53

!--- Deny all other DNS traffic.

access-list 110 deny udp any any eq 53

access-list 110 deny tcp any any eq 53

!--- Allow IPSec VPN traffic.

access-list 110 permit udp any host IPSec headend device eq 500

access-list 110 permit udp any host IPSec headend device eq 4500

access-list 110 permit 50 any host IPSec headend device

access-list 110 permit 51 any host IPSec headend device

access-list 110 deny   ip any host IPSec headend device

!--- These are Internet-sourced connections to

!--- publicly accessible servers.

access-list 110 permit tcp any host public web server eq 80

access-list 110 permit tcp any host public web server eq 443

access-list 110 permit tcp any host public FTP server eq 21

!--- Data connections to the FTP server are allowed 

!--- by the permit established ACE.

!--- Allow PASV data connections to the FTP server.

access-list 110 permit tcp any gt 1023 host public FTP server gt 1023

access-list 110 permit tcp any host public SMTP server eq 25

!--- Explicitly deny all other traffic.

access-list 101 deny ip any any