Notes On Ipsec Testing And Verification - Allied Telesis AR Router Configuration

6.8. Notes on IPSec Testing and Verification

Testing of an IPSec tunnel.
The following are precautions to testing through IPSec tunnels:
•
The 'ip local' ip address is best left at default. If 'ip local' is set to an address other default, this may
invalidate ISAKMP negotiation.
•
Do not expect to test sending traffic through the IPSec tunnel by pinging from IPSec router to IPSec
router. You must test between hosts or servers behind the IPSec router gateways (LAN to LAN), to
ensure this traffic will match the IPSec tunnel policy address selectors.
Verification of an IPSec tunnel.
It is good practice to confirm that traffic is being encrypted. A good initial check is to observe the
ISAKMP negotiation entries in the system log ('sh log'). This ISAKMP check is only valid if you are
using ISAKMP (ie: not manual keys). There will be several phases of negotiation, and they should
indicate successful completion. If you can see no negotiation entries in the log, or if you only see an
initial start and no completed phases, then this suggests a configuration error, or no ISAKMP
negotition received from the peer. Checking 'sh fire event' will allow you to see what traffic has been
received from the peer, and if it has been allowed by the firewall.
Confirmation that traffic is actually being encrypted is best seen by using a counter command such as
SH IPSEC POLI=TUNNEL COUNT. Every time you ping a set of 5 pings, the "outProcessDone"
counters (in the Outbound Packet Processing Counters section) should increment by 5. Also, the
echo reply traffic should cause the "inProcessDone" counters (in the Inbound Packet Processing
Counters section) to increment by 5.
It is important that the IPSec policies be configured in the correct order.
If you have a "permit" IPSec Policy with open policy address selectors, (intended to allow
unencrypted Internet access), then this policy must be configured last – after the ACTION=IPSEC
POLICIES. Otherwise this Permit Policy will process all traffic and no traffic will be encrypted. The
order of the IPSec policies can be checked by the SH IPSEC POLI command. In the output of this
command, each policy is assigned a position number.
Troubleshooting of an IPSec tunnel.
If problems continue, then ISAKMP and IPSec debugging modes may be used. Turning on all debug modes is rather
verbose, so we recommend basic ISAKMP debugging initially. The routine below also illustrates a method to easily disable
the debugging mode after testing.
•
'dis isakmp debug=all'
buffer)
• 'ena isakmp debug=state'
• If more detail is needed then issue this command 'ena isakmp debug=trace'
• To disable debugging after your test, simply press up arrow once (or twice) to recall the disable command, then
press enter. (VT-100 arrows may need to be enabled).
If the basic ISAKMP debugging modes to not reveal a problem to you, then all debugging modes should be enabled and
captured to a text file and sent to your support centre. Please capture the debugging output from the router attempting to
initiate IPSec and ISAKMP by using 'ena ipsec poli=tunnel debug=all' and 'ena isakmp debug=all'. Also capture 'sh log' to
show ISAKMP log entries (as mentioned above), and capture 'sh fire event' and 'sh debug'. Forward all this debugging to
your local technical support for analysis. Your local support center also have access to advanced support centers if
necessary. (Allied Telesyn offers technical assistance in partnership with our authorised distributors and resellers. For
technical assistance, please contact the authorised distributor or reseller in your area). Please refer to
http://www.alliedtelesyn.co.nz/support/support.html for a list of Authorised Distributor & Resellers.
Helpful Scripts
Revision 5.8.7; 5 April 2001
(This may give an error, but our intention is to have this command in the command
(This should allow you to see if ISAKMP is operating)
Helpful Scripts
Page
41