Page 12 - Overview of Secure VPN Implementation
For any routable packet the routing table is referenced to determine the appropriate
destination. If the packet is for an L2TP destination then IP Office checks the status of
the tunnel. If established the packet is forwarded. If the packet is addressed to an L2TP
destination and the tunnel is not active, then IP Office uses the remote gateway entry
on the L2TP form and initiates the tunnel setup. The routable packet is queued until the
tunnel is established. When the tunnel is established the routable packet is forwarded
inside the tunnel.
No
No
Yes
No
Yes
Treat as unprotected
packet
Forward to IPSec
Forward packet
to destination
Drop packet
Is the
L2TP tunnel
destination
established?
Check for an
IPSec Policy match
for this packet?
Yes
Is the packet
for an L2TP
destination?
Any packet
Check Routing Table
Forward outside
L2TP tunnel
Queue Packet
or
Use Remote
Gateway address to
establish tunnel
Forward inside
L2TP tunnel
Is the
L2TP tunnel
established?
Close L2TP after 3
failed attempts
No
Yes
Figure 6. L2TP Implementation
When the L2TP packet is to be forwarded it may be the case that the IPSec tunnel peer
or endpoint address require IPSec protection. If so, the outgoing L2TP packet is
encrypted inside IPSec, as in the case for an unprotected packet (see previous
paragraphs). In this way L2TP can be tunneled inside IPSec. If the L2TP tunnel peer
address does not require protection then an L2TP packet is sent directly without IPSec
protection.
With IP Office version 3.0+ implementation it is also permissible for an ESP packet to
be routed to an L2TP destination (i.e. using the routing table) and in this way IPSec to
tunnel inside L2TP.
Page 12 - Overview of Secure VPN Implementation
IP Office (R3.0)
L2TP Implementation
40DHB0002UKER Issue 3 (4th February 2005)