IP, then we accept it.
0.0.0.0 a.b.c.d
(NOT
0.0.0.0)
System checks both type and content
a.b.c.d Blank 1. System will check the ID type and the
content.
2. The contents will match only if the ID
content of coming packet is a.b.c.d because
system will put Secure Gateway Address as
Peer ID content.
a.b.c.d e.f.g.h 1. System will check the ID type and the
content.
2. The contents will match only if the ID
content of coming packet is e.f.g.h.
*Runtime Check: During IKE negotiation, we will check ID of incoming packet and
see if it matches our setting of “Peer ID Type” and “Peer ID Content”.
Summary:
1. When Local ID Content is blank or 0.0.0.0, during IKE negotiation, my ID
content will be “My IP Addr” (if it’s not 0.0.0.0) or local’s WAN IP.
2. When “Peer ID Content” is not blank or 0.0.0.0, ID of incoming packet has to
match our setting. Or the connection request will be rejected.
3. When “Secure Gateway IP Addr” is 0.0.0.0 and “Peer ID Content” is blank or
0.0.0.0, system can only check ID type. This is a kind of “dynamic rule” which
means it accepts incoming request from any IP, and these requests’ ID type is IP.
So if user put such a kind of rule in top of rule list, it may be matched first. To
avoid this problem, we will enhance it in the future.
To Next Page
Loading...
