rent IP address in the MIB entry belonging to peer B.
(3)
Your device sends the initial ISDN call to peer B, which transfers the IP address of
peer A and the token as per the callback configuration.
(4)
Peer B extracts the IP address of peer A and the token from the ISDN call and as-
signs them to peer A based on the calling party number configured (the ISDN number
used by peer A to send the initial call to peer B).
(5)
The IPSec Daemon at peer B's device can use the transferred IP address to initiate
phase 1 negotiation with peer A. Here the token is returned to peer A in part of the
payload in IKE negotiation.
(6)
Peer A is now able to compare the token returned by peer B with the entries in the
MIB and so identify the peer without knowing its IP address.
As peer A and peer B can now mutually identify each other, negotiations can also be con-
ducted in the ID Protect mode using preshared keys.
Note
In some countries (e.g. Switzerland), the call in the D channel can also incur costs. An
incorrect configuration at the called side can mean that the called side opens the B
channel the calling side incurs costs.
Fields in the IPSec Callback menu
Field
Description
Mode
Select the Callback Mode.
Possible values:
•
%
(default value): IPSec callback is deactivated. The
local device neither reacts to incoming ISDN calls nor initiates
ISDN calls to the remote device.
•
&&
: The local device only reacts to incoming ISDN calls
and, if necessary, initiates setting up an IPSec tunnel to the
peer. No ISDN calls are sent to the remote device to cause
this to set up an IPSec tunnel.
•
0%
: The local device sends an ISDN call to the remote
device to cause this to set up an IPSec tunnel. The device
does not react to incoming ISDN calls.
•
>
: Your device can react to incoming ISDN calls and send
ISDN calls to the remote device. The setting up of an IPSec
tunnel is executed (after an incoming ISDN call) and initiated
Funkwerk Enterprise Communications GmbH
18 VPN
bintec Rxxx2/RTxxx2
323