Verify IPSec Policies with Pass or Discard transforms.
To verify proper operation of IPSec policies with pass or discard actions
in the transform list, generate network traffic that matches the
IPSec policy's packet filter or that matches the IPSec
policy's IP address, port, and protocol parameters.
Run the following command to determine the action taken by IPSec/9000.
ipsec_report -cache
Search the command output for the entry with the matching
source and destination IP addresses, source and destination port
numbers, and protocol. Check the value of the Filter field.
This is the action taken by IPSec/9000. Match the transform configured
for the IPSec policy Pass or Discard).
For more information on the ipsec_report command, refer to the ipsec_report man page in chapter 2.
Verify IPSec Policies with AH or ESP transforms.
To verify proper operation of IPSec policies with AH or ESP transforms,
generate network traffic that matches the IPSec policy's packet
filter or that matches the IPSec policy's IP address, port,
and protocol parameters.
After doing so, run the following commands:
ipsec_report -policy
ipsec_report -sad
Or, run:
ipsec_report -all
From the output of ipsec_report, you
can verify the status of the outbound IPSec SA for the packets using
the IPSec policy you are verifying.
To verify the inbound IPSec SA, you must get the remote system's
SPI (Security Parameters Index) for its corresponding outbound IPSec SA.
Check the Hashed or Ordered Policy Rule output (-policy
output) for entries that correspond to the IPSec policy
you are verifying.
There will be multiple entries for each IPSec policy. Find
an outbound entry. The outbound entry for the policy you are verifying
should have a Security Parameters Index (SPI), such as SPI
(hex): BE882:
Rule ID: telnet_in Cookie: 3 State: Ready Src IP Addr: 15.13.115.112 Prefix Length: 32 Src Port number: 23 Dst IP Addr: 15.13.115.101 Prefix Length: 32 Dst Port number: * Network Protocol: * Direction: outbound Filter: Secure Shared SA: Yes Number of SA(s) Needed: 1 Number of SA(s) Created: 1 Kernel Requests Queued: 0 -- SA Number 1 -- Security Association Type: ESP Encryption Algorithm: 3DES-CBC Authentication Algorithm: None SPI (hex): BE882 SPI updated: ISAKMP |
Next, check the Security Association database output (-sad
output)
for the Security
association with the corresponding SPI:
------------- Security Association ----------------Sequence number: 1 SPI (hex): BE882 State: MATURESecurity Association Type: ESP with 3DES-CBC encryption and No authenticationSrc IP Addr: 15.13.115.112 Dst IP Addr: 15.13.115.101--- Current Lifetimes --- bytes processed: 6256 addtime (seconds): 3 usetime (seconds): 30 --- Hard Lifetimes --- bytes processed: 0 addtime (seconds): 28800 usetime (seconds): 28800 |
On this system, there are only two IPSec SAs. The information
for the second IPSec SA corresponds to inbound traffic from the
remote system (the source address is 15.13.115.101), so we can assume
that this second SA corresponds to the inbound traffic for the policy.
----------- Security Association ------------------------ Sequence number: 2 SPI (hex): 13BDB7 State: MATURE Security Association Type: ESP with 3DES-CBC encryption and No authentication Src IP Addr: 15.13.115.101 Dst IP Addr: 15.13.115.112 --- Current Lifetimes --- bytes processed: 6344 addtime (seconds): 31 usetime (seconds): 30 --- Hard Lifetimes --- bytes processed: 0 addtime (seconds): 28800 usetime (seconds): 28800 |
For more information on the ipsec_report command, refer to
the ipsec_report man page in Chapter 2.