Ipsec implementation

There are many methods to IP Security. In the Microsoft’s Windows 2003 the server version, there are many such techniques and tweaks which are useful to help provide a secure base to the system. The operating system is very good in protecting the system from attacks which may be active attacks or in some cases passive attacks. The procedures for IPSec are placed properly into the system which helps it tackle such attacks. This is possible by providing a secure packet filter for packet transport and also using cryptography. This technology is very in high use for communication types like host to host, router to router, gateway to gateway, site to site and also in virtual private networks. Some other places for successful implementation are secure servers. The IPSec comes as a basic Group Policy controlled by Dos Prompt commands and it also has user interface with custom programs installed.

The implementation of IPSec involves these steps:

• Overview of IPSec Deployment
• Determining Our Internet Protocol Security targets
• Preparing a Internet Protocol Security Policy
• Implementation of the designed policies

Overview of IPSec Deployment:

There are many techniques such as usage of cryptography and authentication software to secure the communication in a network. The connection may be between two parties or between a group of users. Security is to make sure that the communication is not broken, the communication is not intervened and the data is not altered. The Internet Protocol Security has some features which help running a secure transmission. IPSec has set procedures which help achieve these ends.

Today there are many companies and it is getting harder day by day to ensure the security of such humungous networks with a heavy workload on the networks. It is also very hard to track any attacks on the network in millions and millions of request. Using firewalls to protect a network did work for some days but it has proved to be impractical as it has no proper rules to detect intrusions or attacks. The advent of IPSec is a leap in computer and network security. This protocol has a wide spectrum of features which are strong enough to contain such high volume of network requests and also handle intrusions.

The Internet Protocol for Security is not a versatile detection protocol. It is capable of managing most of the policies to grant or reject, block and negotiate the traffic in a network. This can also be permitted to a specific set of addresses or in some cases protocol and also a different policy to each port. It is recommended that we use ICF (Internet Connection Firewall) when we are in need of a firewall which is capable of providing a network interface for very big networks. This is because the internet protocol for Security has a very strict and a very stern strategy which is based on static filtering based on IP addresses. But this is it is totally different in the case of the Internet Connection Firewall. The ICF has policies which has a set of filter for all the addresses which are capable of being accessed. The Internet Protocol for Security can be used when the restriction is only to a particular set of addresses or the communication between a group of computers.

There are many ways to use IPSec in a network but the best way is bye using a directory with all the domains and also a GP when needed.

Some areas of interest when implementing IPSecurity:

The decision of where we must secure computers and how on our network which can be done by running a group of systems in a directory which is also called as the Active Directory Organisational Units or OUs. The next step is to determine the strength of the policies we assign.

Determining Our Internet Protocol Security targets:

The first step in deploying IPSec on our server or the network can be done properly by deciding which set of systems are in dire need of security. There are surely some places on the network which are in a need of higher security than the other sections. It is for sure that IPSec is capable of providing optimal security but the problems starts when the network slows down due to the excessive data to be processed and also a large number of systems for IPSec to follow and maintain. In some cases, there are systems which are not upgraded to be able to support the IPSecurity.

Determining Your IPsec Needs

In beginning of the protocol design procedure, proper planning should be done to make sure that our current network environment available for use. It is always helpful to have a set of the network topology with all of its hardware and software components. This procedure is of high importance mainly in the designing procedure. IPSecurity is highly vulnerable to a network topology. There are many network topologies in which IPSec is not well suited.

Preparing a Internet Protocol Security Policy:

As said earlier, there are many network topologies which are not suitable to the default structure of the IPSec policies. There is a need to develop a custom IPSec set of policies well suited for the current network. Some organisations can run their network with a small set of policies. But in companies with a very huge network, there are many policies which are to be implemented properly and also a stringent structure is to be maintained.

Steps below shows how IP Sec policies work.

Designing IPsec Policies

There might be some cases where the company or the organisation is interested in implementing a policy which sets a secure communication between two specified computers. This can be done by restricting all traffic and adding exceptions which relates to these two systems. This method can be done vice versa. A network can be setup with policies to allow all requests and block specific ports or computers. To implement such exceptions, a thorough analysis of the network is clearly needed.

Computer roles:

Security for Data Transmission: Security needs are different from each and every data packet transmitted. The security policies are also very different. There are many levels in this instance. When considering encryption, there are many types such as AES, DE5, RSA and many more. RSA is the best encryption software available presently. These programs can be used to secure files on transmission, on a network or even in the system.

Operating System – Computers: IPSecurity is a very unique technique used to implement security in a network. There are many operating systems which are not so advanced to implement IPSec. There is no support for IPSec. But there are many operating systems which are capable of running IPSec in transport mode. Some other cases, the policies are stored locally which makes it easier to decide as the implementation doesn’t take long enough. In some cases, IPSec policies are implemented through the Group Policy.

General IPSec Policy Settings

General IPSec policy settings must be specified whether we want the policy to provide packet filtering or end-to-end networks.

IPSec Rules

IPSec rules determine which traffic is affected by an IPSec policy and which actions take place when that type of traffic is encountered. Table6.5 describes the contents of IPSec rules that two computers use to establish a secure, authenticated channel.

Specifies a named list of filters. Each filter in the filter list specifies the types of traffic to which the filter action is applied. Filters can be defined to match specific IP protocols, source and destination TCP and UDP ports, and source and destination IP addresses.

The filter list name might include the version number, the last update time, and the administrative owner. Each computer discards the filter list name during policy processing.

Filter action

Specifies whether a packet is permitted, blocked, or secured. If packets are to be secured, specifies how they are secured. A list of security methods specifies the security protocol, cryptographic algorithm, and session key regeneration frequency.

Request Security

Authentication methods

One or more authentication methods, which are specified in order of preference. Available options are KerberosV5, certificate, or preshared key.

Specifies whether to use tunnel mode and, if so, the tunnel’s endpoint.

Specifies whether the rule applies to LAN connections, remote access connections, or both.

Assigning IPSec Policies:

As a domain administrator, we can configure IPSec policies to meet the security requirements of a user, group, application, domain, site, or global enterprise from a domain controller. IPSec policy can also be implemented in a non-Windows2000-based domain environment by using local IPSec policies.

Deploying Our IPSec Solution:

After scoping our needs, building IPSec policies, and determining our strategy for assigning the policies to specific OUs, test the IPSec policies in a lab environment and conduct a pilot project before rolling them out for production use.

To ensure that IPSec policy functions as expected and provides the appropriate level of security, test specific IPSec policy configurations on clients and servers in a lab environment, and then conduct pilot or beta tests in a limited operational environment before conducting a full-scale deployment.

A Cryptographic Evaluation of IPsec:

Even with all the serious critisisms that we have on IPsec, it is probably
the best IP security protocol available at the moment. We have looked at other,
functionally similar, protocols in the past (including PPTP [SM98, SM99]) in
much the same manner as we have looked at IPsec. None of these protocols
come anywhere near their target, but the others manage to miss the mark by a
wider margin than IPsec. This difference is less significant from a security point
of view; there are no points for getting security nearly right. From a marketing
point of view, this is important. IPsec is the current best practice,” no matter
how badly that reects on our ability to create a good security standard.

Our main criticism of IPsec is its complexity. IPsec contains too many options
and too much exibility; there are often several ways of doing the same or similar
things. This is a typical committee efiect. Committees are notorious for adding
features, options, and additional exibility to satisfy various factions within the
committee. As we all know, this additional complexity and bloat is seriously
detrimental to a normal (functional) standard. However, it has a devastating
efiect on a security standard.

It is instructive to compare this to the approach taken by NIST for the development
of AES [NIST97a, NIST97b]. Instead of a committee, NIST organized a
contest. Several small groups each created their own proposal, and the process is limited to picking one of them. At the time of writing there has been one stage
of elimination, and any one of the five remaining candidates will make a much better standard than any committee could ever have made.

The Complexity Trap: Security’s worst enemy is complexity.

Complexity of IPsec In our opinion, IPsec is too complex to be secure. The
design obviously tries to support many difierent situations with difierent options.
We feel very strongly that the resulting system is well beyond the level of
complexity that can be analysed or properly implemented with current methodologies.
Thus, no IPsec system will achieve the goal of providing a high level of
security.

IPsec has two modes of operation: transport mode and tunnel mode. There
are two protocols: AH and ESP. AH provides authentication, ESP provides authentication,
encryption, or both. This creates a lot of extra complexity: two
machines that wish to authenticate a packet can use a total of four difierent
modes: transport/AH, tunnel/AH, transport/ESP with NULL encryption, and
tunnel/ESP with NULL encryption. The difierences between these options, both
in functionality and performance, are minor. The documentation also makes it
clear that under some circumstances it is envisioned to use two protocols: AH
for the authentication and ESP for the encryption.

Modes As far as we can determine, the functionality of tunnel mode is a superset
of the functionality of transport mode. (From a network point of view, one
can view tunnel mode as a special case of transport mode, but from a security
point of view this is not the case.) The only advantage that we can see to transport
mode is that it results in a somewhat smaller bandwidth overhead. However,
the tunnel mode could be extended in a straightforward way with a specialized
header-compression scheme that we will explain shortly. This would achieve virtually
the same performance as transport mode without introducing an entirely
new mode. We therefore recommend that transport mode be eliminated.

Recommendation 1 Eliminate transport mode.

Without any documented rationale, we do not know why IPsec has two
modes. In our opinion it would require a very compelling argument to introduce
a second major mode of operation. The extra cost of a second mode (in
terms of added complexity and resulting loss of security) is huge, and it certainly
should not be introduced without clearly documented reasons.

Eliminating transport mode also eliminates the need to separate the machines
on the network into the two categories of hosts and security gateways. The main
distinction seems to be that security gateways may not use transport mode;
without transport mode the distinction is no longer necessary.

Protocols The functionality provided by the two protocols overlaps somewhat.
AH provides authentication of the payload and the packet header, while ESP
provides authentication and confidentiality of the payload.

In transport mode, AH provides a stronger authentication than ESP can provide,
as it also authenticates the IP header fields. One of the standard modes of
operation would seem to be to use both AH and ESP in transport mode. In tunnel
mode, ESP provides the same level of authentication (as the payload includes
the original IP header), and AH is typically not combined with ESP [KA98c,
section 4.5]. (Implementations are not required to support nested tunnels that
would allow ESP and AH to both be used in tunnel mode.)

One can question why the IP header fields are being authenticated at all. The
authentication of the payload proves that it came from someone who knows the
proper authentication key. That by itself should provide adequate information.
The IP header fields are only used to get the data to the recipient, and should
not afiect the interpretation of the packet. There might be a very good reason
why the IP header fields need to be authenticated, but until somebody provides
that reason the rationale remains unclear to us.

The AH protocol [KA98a] authenticates the IP headers of the loour layers.
This is a clear violation of the modularization of the protocol stack. It creates
all kind of problems, as some header fields change in transit. As a result, the
AH protocol needs to be aware of all data formats used at loour layers so that
these mutable fields can be avoided. This is a very ugly construction, and one
that will create more problems when future extensions to the IP protocol are
made that create new fields that the AH protocol is not aware of. Also, as some
header fields are not authenticated, the receiving application still cannot rely on
the entire packet. To fully understand the authentication provided by AH, an
application needs to take into account the same complex IP header parsing rules
that AH uses. The complex definition of the functionality that AH provides can
easily lead to security-relevant errors.

The tunnel/ESP authentication avoids this problem, but uses more bandwidth.
The extra bandwidth requirement can be reduced by a simple specialized
compression scheme: for some suitably chosen set of IP header fields X, a single
bit in the ESP header indicates whether the X fields in the inner IP header are
identical to the corresponding fields in the outer header.2 The fields in question
are then removed to reduce the payload size. This compression should be
applied after computing the authentication but before any encryption. The authentication
is thus still computed on the entire original packet. The receiver
reconstitutes the original packet using the outer header fields, and verifies the
authentication. A suitable choice of the set of header fields X allows tunnel/ESP
to achieve virtually the same low message expansion as transport/AH.

We conclude that eliminating transport mode allows the elimination of the
AH protocol as well, without loss of functionality. We therefore recommend that
the AH protocol be eliminated.

IPSEC methodology using different operating systems:

IPSEC is a framework for security that operates at the Network Layer by extending the IP packet header. This gives it the ability to encrypt any higher layer protocol, including TCP and UDP sessions, so it offers the greatest flexibility of all the existing TCP/IP cryptosystems. While conceptually simple, setting up IPSEC is much more complex that installing SSH, for example.

IPSEC also has the disadvantage of requiring operating system support, since most O/S kernels don’t allow direct manipulation of IP headers. Linux IPSEC support (the FreeS/WAN project), for example, isn’t included in the standard kernel distribution for this reason, and has to be applied as an add-on. Furthermore, putting the cryptography in the kernel isolates it from the application, making it more difficult to code crypto-aware software. Using SSL, for example, simply requires linking a library into the application and allows the application to easily query what certificates have been used to authenticate a client.

IPSEC defines a “Security Association” (SA) as its primitive means of protecting IP packets. An SA is defined by the packet’s destination IP address and a 32-bit Security Parameter Index (SPI), that functions somewhat like a TCP or UDP port number. SAs can operate in transport mode, where the IPSEC data field begins with upper level packet headers (usually TCP, UDP, or ICMP), or in tunnel mode, where the IPSEC data field begins with an entirely new IP packet header, ala RFC 2003. Furthermore, SAs can be encapsulated within SAs, forming SA bundles, allowing layered IPSEC protection.

For example, one SA might protect all traffic through a gateway, while another SA would protect all traffic to a particular host. The packets finally routed across the network would be encapsulated in an SA bundle consisting of both SAs.

A common use of IPSEC is the construction of a Virtual Private Network (VPN), where multiple segments of a private network are linked over a public network using encrypted tunnels. This allows applications on the private network to communicate securely without any local cryptographic support, since the VPN routers perform the encryption and decryption. IPSEC is well suited for this environment, more so than tunneling PPP over SSL or SSH, since it operates directly on the IP packets and preserves a one-to-one correspondence between packets inside and outside the network. In the case of tunneling PPP over an encrypted TCP connection, any packet loss in the public network would trigger a TCP retransmission, stalling the link until the packet was delivered. In particular, running Voice Over IP (VoIP) traffic through a TCP/PPP tunnel would largely defeat the RTP protocol used for VoIP; IPSEC is better suited in this case.

IPsec Development for Linux:

In the Linux IPv4 IPsec world, a lot of people use
FreeS/WAN project’s implementation. It consists of an inkernel
IPsec processing part, Key Exchange daemon ‘Pluto’
and some utility commands/scripts.

To run Pluto with small changes on our IPsec kernel
implementation and reduce impact for user who use
FreeS/WAN implementation, we have decided to keep compatibility
with FreeS/WAN’s IPsec programming interface
between kernel and userland. For this, we use the same
PF KEY interface which FreeS/WAN project extended.

In kernel IPsec packet processing part, we developed
AH, ESP, SAD and SPD from scratch. PF KEY interface
PF KEY(v2), which is described in RFC2367, is key
management API mainly for IPsec. PF KEY is used for
handling the IPsec Security Association Database. Additionally
we have to handle the IPsec Security Policy
Database, but there is no standard for the IPsec Security
Policy management API. In FreeS/WAN implementation,
PF KEY interface is extended to manage the IPsec Security
Policy Database. Our kernel 2.4 IPsec implementation
also uses the same PF KEY interface as FreeS/WAN’s one.
It is important to be able to run the FreeS/WAN’s userland
application (e.g., Pluto) with small changes.

Encryption and Authentication algorithm

We provide HMAC-SHA1 and HMAC-MD5 for authentication,
NULL, DES-CBC, 3DES-CBS and AES for encryption.
We thought encryption and authentication algorithm
is not only used by IPsec and there are many algorithms
so that we consider encryption and authentication algorithm
and those interface should have good modularity.
We adopted cipher modules which provided by CryptoAPI
Project.

Security Association and Security Policy

SA and SP themselves don’t depend substantially on the
IP version. FreeS/WAN project architecture depends on
their special virtual network interface for IPsec because it
might focus on IPv4 tunnel mode (Their implementation
also provides IPv4 transport mode). Their SA, SP, SAD and
SPD also depend on their special virtual network interface.

We considered and decided it was not suit to IPv6 because the IPv6 stack needed the neighbor discovery and the auto address configuration in its basic specification. If we had
implemented IPv6 IPsec stack with their architecture, we
had to implement those basic specification in their special
virtual network interface. Therefore we implemented our
own SAD and SPD in order to handle both IPv4 and IPv6.

To improve the system performance, Each database will
be locked by smallest granularity. And in many cases we
use the ‘read lock’. SA and SP are managed by the reference
counter to prevent used SA from removing by accident.

IPsec Packet Processing

Output

There are various packet output paths from the IP(v4/6)
layer to the network driver layer in Linux kernel networking
stack (TCP, UDP/ICMP, and NDP[10] for IPv6).

The packets which may be applied IPsec will go
through these paths. We had to add IPsec functionality
for these output paths, e.g, in IPv6 ip6 xmit()
for TCP, ip6 build xmit() for UDP/ICMP and
ndisc send ns()/ndisc send rs() for neighbor
discovery packets.

Output process is as follows):

1. check IPsec SP
2. lookup the IPsec SA by the IPsec SP
3. apply IPsec processing to the packet
4. output the packet to the network driver layer

To reduce SA searhing time, we link the SP and the
found SA after lookup from the first time.

Input

At input, there is only path for IP packets. We added IPsec
processing part in ip6 input finish.

Input process is as follows:

1. receive the packet
2. lookup the IPsec SA by SPI(which resides in AH/ESP header)
3. check integrity and decrypt
4. check IPsec Policy.

IPsec Tunnel mode

We are using IPv6-over-IPv6(and IPv4-over-IPv4) virtual
tunnel device to implement IPsec tunnel mode. This
implementation can avoid to duplication code of encapsulation/
decapsulation outer IP header compairing with having
these code in the IPsec processing part itself. The virtual
tunnel device is not different from the normal IP-over-IP
virtual tunnel device in Linux.

4 IPsec implementation for kernel 2.6

The most important difference between ours and them is SAD/SPD part. They thought the whole SPD/SAD mechanic should be flow cache based lookup system shared by
IPv4 and IPv6. One month later, they introduced the new
network architecture called ‘XFRM’ to Linux kernel 2.5.
At first their developing code lacked IPv6 IPsec only for
IPv4 IPsec. In order to suport IPv6 IPsec, we have implemented
IPv6 IPsec code based on XFRM (and discarded our
original code).

PF KEY interface

The PF KEY interface of Linux kernel 2.6(and 2.5) is
compatible with KAME[3] PF KEY interface. We can use
‘setkey’ command for configuring SA and SP and ‘Racoon’
for IKE. Additionally we can add IPsec Policy each socket
via Netlink3. They have suported only IPv4 in their first
code, we have added IPv6 support.

Security Association and Security Policy

On the XFRM architecture, IPsec SP, which is represented
as xfrm policy structure, will be bound to
the routing flow cache (and IPsec policy will point
IPsec SA bundle) and IPsec SA, which is represented as
xfrm state structure, is included in destination cache,
dst entry structure. The chaining destination cache
means IPsec SA bundle.

IPsec Packet Processing

Output

The output part of the XFRM architecture is placed between
the IP layer and the network driver layer. In general, non
IPsec packet will be passed to the network driver layer by a
single destination output function, which is resolved routing
lookup. But IPsec packet will be need to apply some IPsec
processing (e.g., encryption, hash). XFRM functions make
a chain of destination output functions (We call Stackable
Destination, as shown in Figure3). Each function match
each IPsec processing (AH, ESP and IPcomp[11]).

To be more specific, in order to pass a packet to the network
driver layer we have to do as follows.

1. lookup routing table to decide output function by
   ip6 route output
2. lookup IPsec Security Policy
3. lookup IPsec Security Association(s) suitable for IPsec
   Security Policy and create destination chain
4. to apply IPsec, pass a packet to the destination chain

Input

The input part of the XFRM architecture is simpler than output.
The XFRM input function is handled as same as upper
layer protocols like TCP, UDP, etc. In IPv6, IPsec headers
are defined as IPv6 extension header but IPsec input functions
are handled as an upper layer protocol handler. As the
result of introducing IPv6 IPsec input processing in Linux.

kernel, inconsistencies existed between IPsec headers and other IPv6 extension headers. In order to resolve this, we
moved to the other IPv6 extension header handler functions
to upper layer protocol handler. In detail, we registered
IPsec header (both AH and ESP) handler functions with upper
layer protocol handler array inet6 protos.

Incoming IPsec packet processing flow is as follows:

1. process IP packet from IP header in sequence
2. process IPsec part (check integrity and decrypt) if
   founded
3. check IPsec Security Policy
4. pass IP packet next handler

IPsec Tunnel mode

Linux kernel 2.6 IPsec tunnel mode doesn’t use the virtual
tunnel device to create tunnel. The IPsec stack builds
the outer IP header during IPsec processing by itself.

IPSec Best practices

Best practices

IPSEC in transport mode has some serious advantages over other solutions. Compared to other technologies, IPSEC is built into to the Linux kernel. In other words there is nodaemonrunning in the background. Better yet, IPSEC does not require port-forwarding; some people elect to useSSH, stunnel, and other technologies that rely onport forwarding. With IPSEC, you simply have to run a program and it’s configuration file. After running it,encryptionbetween hosts is mandatory. Connections will be refused if the other connection does not have the appropriate keys. Groups of computers can share the same key, and it can even be done on a per-port setting (for example securing VNC, etc).

Downsides?

IPSEC in transport mode does have a couple draw backs. In transport mode you cannot have any dynamic setups where the IP addresses change from time to time. In other words, IPSEC is usually insufficient for workstation environments or dynamically assigned networks. Also, if you want to do a per-port setup the configuration becomes harder.

Security Implications

A very astute user can use IPSEC to bypass firewalls and other security measures. Since IPSEC uses cryptography, information is passed between machines in encrypted format. If the keys are not known, there is no practical way to decrypt the information (it is virtual impossible due to the sheer amount of time it would take).

Machine-to-Machine IPSEC installations should be considered as Virtual Private Networks (VPNs) for security considerations. Please check with yoursystem administrator, business policies, and laws and regulations of your locality in order to establish whether or not to institute IPSEC.

Requirements

• ipsec-tools package
• static IP addresses for each machine

Configuration file

The configuration file, /etc/setkey.conf, contains the information about the IPSECpolicy. Below is a sampleconfiguration policy(i.e. don’t implement this policy because it is insecure).

These lines are the actual keys and the encryption that will be used. The first block has the keys that will be used for authentication. In this case, it is the “hmac-md5″algorithm. The second block contains the keys that will be used for privacy, and the method of encryption. In the example, AES-CBC will be used, which is probably stronger than should be required; the key that we will be using is 194bits, meaning that it is good enough for US Government Secret and below classifications.

The final block includes the actual policy. This is where you can put port numbers and even define whether it will be TCP orUDP.

Generating the keys

The more random the key, the better. Obviously, the example above is insufficient to secure a network. The following command will generate a random key. While running this command, you’ll need to wiggle the mouse to make it run faster. Or, if you are using a terminal use/dev/urandom instead.

dd if=/dev/random count=16 bs=1| xxd -ps

Depending on the size of the key that you want, adjust the count (16 will produce a 128 bit key, 24 will produce a 196 bit key, and 32 will produce a 512 bit key)

The size of the key is important. If you really paranoid or just haveCPUcycles to burn on cryptography, use a 256 bit key. Generally speaking 256-bit encryption is becoming the standard for sensitive data. For most applications, it is overkill. In this example, we are using the AES-CBC cipher which is used by the US Government. At the time of this writing AES 128 bit-key lengths is the defacto standard for anything that is “Secret” or below, while AES 196 or 256 bit-key lengths are required for “Top Secret.” Needless to say, the choice of the cryptographic strength and the cipher is largely your choice.

After you have hashed out the configuration file, you can load it using the “setkey -f /etc/setkey.conf” command. If there are any errors, it will tell you. Otherwise, after the command has been run, it is immediately active. Any connection to or from the machine in question that meets a rule will have to be appropriately encrypted.

If you should find that you have rendered your system unable to connect to the world, type “setkey-FP.”

Testing

The testing is rather simple – if after loading the configuration file you can access the other server, then it worked. Otherwise, there is a problem. If you are particularly interested to see that the data is indeed being encrypted, a simple tcpdump will show it to you:

Adjust your firewall

Since IPSEC will only encrypt traffic from one IP address to another, you may need to change you firewall rules to reflect this behavior. For example, if an application is listening on 5901 (VNC) and all the machines that will access the ports need have IPSEC, it would be advisable to shut out everyone except the IP addresses you want. Otherwise a user could connect from a non-IPSEC secured machine and then transmit the data unencrypted.

In other words, IPSEC is only part of the equation.

Conflicts

If you are using a desktop IPSEC client like Raccoon you may have your rules cleared. You may need to edit your configuration files in order to include the rules.

Side note

On a practical level IPSEC is great to secure applications with out additional overhead. At the time of writing this, I had three problems:

• Securing several hosts with out using a full-fledged VPN solution like OpenVPN
• Running Synergy
• Securing VNC
• Concern fortelnet

Obviously, the first item was an outcrop of the last three. IPSEC soon became the best choice for me. Other people might find that solutions like “stunnel” and ssh will work for them. The biggest issue was that I wanted something that would just work. I didn’t want something that I would have to monkey around or have to drop into a super-user in order to fix a problem here and a problem there. I found IPSEC to be faster than any of the other solutions although I don’t have hard numbers on it.

Conclusion

IPSec has an extensive set of parameters within its architecture, and the interaction of those factors is not always intuitively clear. However, the IPSec communications driver follows these rules to the letter, giving system administrators and developers utilizing this system a means to follow and interpret security results, even when they are unexpected. Fortunately, the challenges of the IPSec architecture are commensurate with its poour, and the effort to thoroughly understand its intricacies will repay we with an invaluable defense against many forms of system attack. IPSec configuration may not be point-and-click simple, but it is actually easier to configure than most firewalls or other network security tools that filter packets.