NETASQ Technical Support Training Session 3

IPSec

© NETASQ 2006

Summary • General uses and IPSec VPN concepts • Special features : – NAT Traversal (NAT-T) – Dead Peer Detection (DPD) – Keep Alive

• • • •

Tunnel negotiation, step by step Packet handling, step by step Diagnostic methodology Known problems, common errors and limitations

NETASQ – CORPORATE PRESENTATION

2

General uses and IPSec VPN concepts •

When a client has to reach an internal server or when several private LAN have to be linked together through the Internet.

•

IPSec tunnels ease the communications by enabling the hosts to work with their real IP, just AS IF they were simply routed ; no NAT is needed.

•

IPSec tunnels provide integrity and confidentiality thanks to cryptography (transporting the original IP packets using AH/ESP protocols).

•

In the old days, static tunnels were setup with manually defined keys and SPI injected into the kernel IPSec stack. The trouble was the keys were only renewed when the administrator had time to do it. NETASQ – CORPORATE PRESENTATION

3

General uses and IPSec VPN concepts • Nowadays, thanks to ISAKMP (Internet Security Association & Key Management Protocol), the keys are dynamically and regularly negotiated ; ensuring a better security level. • The NETASQ ISAKMP/IPSec implementation: – the kernel takes care of the IPSec traffic : • Decrypting the traffic, and choosing, thanks to its IPSec policy, whether an outgoing packet has to be routed or encrypted.

– the ISAKMP daemon racoon is in charge of : • providing the keys requested by the kernel ; • and make sure it will be able to provide these keys (DPD).

NETASQ – CORPORATE PRESENTATION

4

Specials features NAT Traversal (NAT-T) •

Negotiated during first exchange.

•

If NAT is detected (on one or both sides), the remaining negotiation as well as the IPSec traffic itself will be encapsulated using UDP.

•

Two drafts (now RFC3947) : 500/udp (draft 1) or 4500/udp (draft 2).

•

For a full NAT-T implementation, both the kernel and the ISAKMP daemon must know about this feature.

NETASQ – CORPORATE PRESENTATION

5

Specials features Dead Peer Detection (DPD) Goal : ensure the peer still knows the current (and common) ISAKMP-SA • • •

DPD tests the validity of the ISAKMP-SA (phase 1) by sending Informational packets ; These packets are encrypted with the ISAKMP-SA (and so are considered phase 2 packets) : These packets contains messages : • R-U-THERE requests are sent ; • and then R-U-THERE-ACK replies are expected.

NETASQ – CORPORATE PRESENTATION

6

Specials features Dead Peer Detection (DPD) •

DPD is fully handled by racoon, the kernel isn’t involved ;

•

Manual settings : • VPN Tunnel / Advanced / DPD Support / Mode must be set to Manual ; • Delay : delay between R-U-There requests emissions ; • Retry : in case of failure, the time before sending a new R-U-There request ; • Maximum failures : the number of failures before considering the peer being dead.

•

Two builtin templates : • Mode set to High : delay = 30, retry = 5 and maximum failures = 3 ; • Mode set to Low : delay = 600, retry = 10 and maximum failures = 5 ;

NETASQ – CORPORATE PRESENTATION

7

Specials features Dead Peer Detection (DPD) What occurs when the DPD reaches the maximum failures limit ? •

Delete every IPSec-SA corresponding to the tunnel ;

•

Delete of every ISAKMP-SA corresponding to the tunnel.

NETASQ – CORPORATE PRESENTATION

8

Specials features Keep Alive •

Force IPSec-SA renewal even if no real user traffic is passing through the tunnel ;

•

Generate fake traffic that match the traffic endpoints ;

•

Traffic (~30 bytes per packets) sent to 9/udp (discard_udp) and with no reply expected ;

•

Standalone program (~/sbin/keepalive) distinct from the IPSec stack as well as from racoon ;

•

Task scheduled using eventd. NETASQ – CORPORATE PRESENTATION

9

Negociations, step-by-step Phase 1 • Capabilities/supported features (NAT-T, DPD,…) ; • proposals (algorithm, lifetime, DH) ; • and identity (ID type, etc). Once the phase 1 has been successfully negotiated, a bidirectionnal key called ISAKMP-SA is known by both the initiator and the responder. This key is then used to protect the phase 2 negotiation using encryption. racoon is in charge of keeping this key and renewing it when necessary. NETASQ – CORPORATE PRESENTATION

10

Negociations, step-by-step Phase 2 • Proposals (algorithm, lifetime, PFS) ; • and traffic end-points. Once the phase 2 has been successfully negotiated, a pair of unidirectionnal keys each called an IPSec-SA is stored and indexed (SPI) in the kernel IPSec structures. One of the IPSec-SA is used to encrypt the outgoing traffic while the other one is used to decrypt the incoming traffic.

NETASQ – CORPORATE PRESENTATION

11

Packet handling, step-by-step VPN policy activation 0) the envpn slot_number command is launched : • the SPD is built for the predefined traffic end-points ; • the SPD is loaded into the kernel structures ; • and the racoon daemon is loaded.

NETASQ – CORPORATE PRESENTATION

12

Packet handling, step-by-step Which actions are triggered by an incoming packet 1) a packet arrives with source and destination IP addresses 2) the kernel has to decide whether this packet should be simply routed or encrypted for the VPN 3) the kernel walk through the SPD looking for an entry corresponding to source and destination of the packet being processed 4) if a matching entry is found in the SPD, the kernel now walk through the SAD looking for the corresponding IPSec-SA

NETASQ – CORPORATE PRESENTATION

13

Packet handling, step-by-step Which actions are triggered by an incoming packet A] no corresponding IPSec-SA exists in the SAD 5-a) the kernel asks racoon, the ISAKMP daemon, to get the needed IPSec-SA used to encrypt the traffic 6-a) if no valid ISAKMP-SA is available, racoon delays the IPSec-SA negotiation to negotiate an ISAKMP-SA first 7-a) racoon sends the first phase1 packet 8-a) it receives an acceptable response (a proposal with acceptable identity and algorithms), then acknowledges the phase1 with the peer NETASQ – CORPORATE PRESENTATION

14

Packet handling, step-by-step Which actions are triggered by an incoming packet A] no corresponding IPSec-SA exists in the SAD 9-a) continues with the phase2 negotiation 10-a) receives an acceptable response (proposal with acceptable algorithms and traffic end-points), then acknowledges the phase2 with the peer 11-a) the negotiated IPSec-SA are then loaded into the kernel IPSec stack structures ; now the pair of IPSec-SA is available to the kernel suitable for encryption

NETASQ – CORPORATE PRESENTATION

15

Packet handling, step-by-step Which actions are triggered by an incoming packet B] a corresponding IPSec-SA exists and isn’t dying 5-b) as long as a valid IPSec-SA exists for this traffic, the packet is encrypted and sent to the remote security gateway, i.e., the remote tunnel endpoint

C] a corresponding IPSec-SA exists and is dying 5-c) the kernel applies B] to encrypt the traffic and A simultaneously to ensure the IPSec-SA renewal in advance. The new IPSec-SA will be used as soon as it’s mature, the previous one will be left in the dying state untill its death

NETASQ – CORPORATE PRESENTATION

16

Diagnostic methodology Analysis of an IPSec-SA Here is an IPSec-SA extracted from the SAD, i.e., from the output of the showSAD command : 172.30.12.1 10.33.5.79 esp mode=tunnel spi=66064855(0x03f011d7) reqid=16398(0x0000400e) E: aes-cbc 6dda0f24 7885cef4 3e781823 e37d653d 80660d57 220b7220 60 […] A: hmac-sha1 d79ceced 93cff8ee 7fd05d60 b29f94f3 aaf9104d seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Nov 24 07:22:19 2006 current: Nov 24 07:30:45 2006 diff: 506(s) hard: 3600(s) soft: 2880(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=127 pid=33287 refcnt=1 NETASQ – CORPORATE PRESENTATION

17

Diagnostic methodology Analysis of an IPSec-SA 172.30.12.1 10.33.5.79 […]

• • • • • •

The couple of IP addresses correspond to the tunnel endpoints ; An IPSec-SA is unidirectionnal ; The first IP address is the expected source of IPSec packets while the second one is their expected destination ; If 10.33.5.79 is the IP address of the firewall, this IPSec-SA is said to be an incoming IPSec-SA while in the other case it’s an outgoing IPSec-SA ; Incoming IPSec-SA are used to decrypt IPSec packets while outgoing ones are used to encrypt them ; A tunnel is made of a pair of IPSec-SA. NETASQ – CORPORATE PRESENTATION

18

Diagnostic methodology Analysis of an IPSec-SA 172.30.12.1 10.33.5.79 esp mode=tunnel spi=66064855(0x03f011d7) reqid=16398(0x0000400e) […]

•

The SPI (Security Policy Index) uniquely identify the parameters that must be used to encrypt/decrypt data ;

•

The SPI change after each negotiation/re-negotiation.

NETASQ – CORPORATE PRESENTATION

19

Diagnostic methodology Analysis of an IPSec-SA 172.30.12.1 10.33.5.79 esp mode=tunnel spi=66064855(0x03f011d7) reqid=16398(0x0000400e) […]

•

The ReqID is used to link entries found in the SAD to entries found in the SPD ;

•

The ReqID only change when the IPSec configuration is reloaded.

NETASQ – CORPORATE PRESENTATION

20

Diagnostic methodology Analysis of an IPSec-SA Here is an extract of SPD, i.e., part of the output of the showSPD command : 192.10.10.0/24[any] 10.212.1.0/24[any] any in ipsec esp/tunnel/172.30.12.1-10.33.5.79/unique#16398 spid=16 seq=172 pid=33288 refcnt=1

•

The third line show the ReqID of this security policy ;

•

This security policy concerns communications between 192.10.10/24 and 10.212.1/24 ;

•

The tunnel endpoints are also part of the SPD. NETASQ – CORPORATE PRESENTATION

21

Diagnostic methodology Analysis of an IPSec-SA 172.30.12.1 10.33.5.79 esp mode=tunnel spi=66064855(0x03f011d7) reqid=16398(0x0000400e) E: aes-cbc 6dda0f24 7885cef4 3e781823 e37d653d 80660d57 220b7220 60 […] A: hmac-sha1 d79ceced 93cff8ee 7fd05d60 b29f94f3 aaf9104d seq=0x00000000 replay=4 flags=0x00000000 state=mature […]

•

Encryption algorithm and hash algorithm ;

•

State of an IPSec-SA : • larval : the IPSec-SA is being built ; • mature : the IPSec-SA is fully fonctionnal ; • dying : IPSec-SA’s lifetime has reached the soft limit and a replacement one must be negotiated.

NETASQ – CORPORATE PRESENTATION

22

Diagnostic methodology Analysis of an IPSec-SA 172.30.12.1 10.33.5.79 […] seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Nov 24 07:22:19 2006 current: Nov 24 07:30:45 2006 diff: 506(s) hard: 3600(s) soft: 2880(s) […]

•

The field created show the birth date and time ;

•

Current lifetime and limits are described as follow : • diff : current lifetime expressed in seconds since birth ; • soft : soft limit, i.e., reaching this limit switch state from mature to dying ; • hard : hard limit, i.e., reaching this limit lead to the death of the IPSec-SA.

NETASQ – CORPORATE PRESENTATION

23

Diagnostic methodology Analysis of an IPSec-SA 172.30.12.1 10.33.5.79 […] diff: 506(s) hard: 3600(s) soft: 2880(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) […]

•

Field current show the number of bytes sent using this IPSec-SA ;

•

Fields hard and soft on the same line are unused.

NETASQ – CORPORATE PRESENTATION

24

Diagnostic methodology Avoid problems from the beginning •

Prefer using the strict or exact mode (avoid claim or obey as much as possible)

•

Always try to simplify the configuration by limiting it to a single pair of algorithms in each proposals

•

Set the policies to the exact same values on both side (except the identifier)

NETASQ – CORPORATE PRESENTATION

25

Diagnostic methodology Diagnosing problems : where and what to look at ? •

Look at the VPN logs and alarm logs on both sites : –

the responder is very likely to report the more useful information about the reason of the failure – whereas the initiator may report a simple "negociation failed due to timeout" if it gets no reply

•

Compare the messages reported in the logs with those described in the VPN logs document Interpretation of the VPN logs – See the array in Appendix at the end of the presentation (a more readable version of this document will be maintained up-to-date and available for download in PDF format on NETASQ.com)

NETASQ – CORPORATE PRESENTATION

26

Diagnostic methodology Diagnosing problems: seeing phase1 settings with •

tcpdump

If you have a doubt on the settings proposed by the initiator, (for example, in case of interoperability problem with other product), tcpdump can display the proposals content of the phase1 tcpdump -ni fxp0 -s0 port 500 or port 4500

Example with a MAIN MODE negotiation (notice the "ident" at the end of the first line) : INITIATOR : 10.1.15.62.500 > 10.1.15.63.500: isakmp: phase 1 I ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=aes)(type=keylen value=0080) (type=auth value=preshared)(type=hash value=sha1)(type=group desc value=modp1024))))

NETASQ – CORPORATE PRESENTATION

27

Diagnostic methodology Diagnosing problems: seeing phase1 settings with

tcpdump

RESPONDER : 10.1.15.63.500 > 10.1.15.62.500: isakmp: phase 1 R ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=aes)(type=keylen value=0080) (type=auth value=preshared)(type=hash value=sha1)(type=group desc value=modp1024))))

– Values are in hexadecimal lifeduration 0e10 = 3600 sec keylen 0080 = 128 bits

NETASQ – CORPORATE PRESENTATION

28

Diagnostic methodology Diagnosing problems : seeing phase1 settings with

tcpdump

AGGRESSIVE MODE (notice the agg at the end of the first line): INITIATOR 10.1.15.62.500 > 10.1.15.63.500: isakmp: phase 1 I agg: (sa: doi=ipsec situation=identity (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=aes)(type=keylen value=0080) (type=auth value=preshared)(type=hash value=sha1)(type=group desc value=modp1024)))) (id: idtype=user FQDN protoid=0 port=0 len=17 [email protected])

RESPONDER 10.1.15.63.500 > 10.1.15.62.500: isakmp: phase 1 R agg: (sa: doi=ipsec situation=identity (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=0e10)(type=enc value=aes)(type=keylen value=0080) (type=auth value=preshared)(type=hash value=sha1)(type=group desc value=modp1024)))) (id: idtype=user FQDN protoid=0 port=0 len=17 [email protected])

NETASQ – CORPORATE PRESENTATION

29

Diagnostic methodology Diagnosing problems : activating the racoon verbose •

If you didn't find any configuration error corresponding the cases described in the document, you'll probably have to activate the ISAKMP daemon verbose mode.

•

If possible limit the number of active tunnels by disabling the tunnels that don't have any problems ; with less tunnels, the verbose file will be lighter and obviously easier to understand.

•

Since 6.1, the verbose directive is written into the configuration; so it is slot dependant; (it used to be global in 6.0 and previous versions)

•

You may copy your current slot into a free slot in which you’ll activate the verbose mode

•

The VPN slots are files called 01-10 and located in ~/ConfigFiles/VPN/

NETASQ – CORPORATE PRESENTATION

30

Diagnostic methodology Diagnosing problems : activating the racoon verbose To activate the verbose mode – edit the file with joe or vi : joe ~/ConfigFiles/VPN/01

– Add or modify the Verbose= and VerboseFile= tokens in the [global] section [global] Verbose=2 VerboseFile=/log/dbg/racoon.dbg

– Deactivate/reactivate the VPN slot: envpn 00 && envpn 01

– The verbose messages of racoon actions are now written into this /log/dbg/racoon.dbg file NETASQ – CORPORATE PRESENTATION

31

Diagnostic methodology Diagnosing problems : tunnel is up but no communication flows through it No need to activate racoon verbose mode; as the tunnel is up, it means the negotiation was successful, so racoon has already done its job properly. – Try to find out were the packets are blocked by following the path a packet go along: – Local site • With tcpdump, have a look at the traffic on the first interface the packet should hit (IN) • Then have a look on the ipsec interface (lo1); outgoing packets that matched the SPD and are to be encrypted will be seen here • See whether encrypted traffic is going out on the external interface (if this traffic is fragmented you may need to adjust the MSS auto-limit in the ASQ configuration)

– Remote site • • • •

On the remote site, see whether encrypted packet are received Look for the corresponding decrypted packet on the ipsec interface See the same packet forwarded to the real destination on the IN interface Search for the reply packet on the IN and ipsec interfaces NETASQ – CORPORATE PRESENTATION

32

Known problem, common errors and limitations Features : Not supported yet, but planned : - Full NAT-T support, with adapted kernel structures to keep track of the source port of each client in the SAD. Not supported yet, and not officially planned : - Mode Config : feature designed to deliver the traffic end-point to the client (its local traffic endpoint would act as a virtual IP), as well as a DNS server and a WINS server.

Known problem (currently investigated by R&D) : - the DPD could conclude to the death of a peer because the phase 1 expired on the remote gateway but as a phase 2 is still valid and used. NETASQ – CORPORATE PRESENTATION

33

Known problem, common errors and limitations Frequent, but non trivial, configuration errors : The traffic end-points seem correctly defined but the corresponding objects do not match : double check the objects, especially for networks, double check the netmask The traffic end-points seem correctly defined but another tunnel has a matching configuration by using larger networks as traffic end-points The filter rules are not correctly defined (ex: wrong interface, wrong ports,…) The implicit filter rules for VPN enabling the negociations have been disabled and no explicit rules have been defined The local tunnel end-point is not correctly defined (ex: firewall_out instead of firewall_dialup)

NETASQ – CORPORATE PRESENTATION

34

NETASQ – CORPORATE PRESENTATION

35