|
What known issues are there
with SecuRemote/SecureClient
operating behind specific Broadband DSL/Cable routers?
1. Symptom :
"User is not prompted for authentication"
Explanation :
In a scenario with a private IP address (SecureClient has a private IP
address which is also part of the Encryption Domain), SecureClient assumes
that it is located within the Encryption Domain and does not encrypt
packets.
Work-around :
- First work-around : define a different IP address for the SecuRemote/SecureClient
user.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution : Office Mode, a solution to the above problem, was introduced in
NG FP1.
2. Symptom : "Communication with site fails"
There can be a few reasons :
a. Key exchange is performed with the wrong interface IP address of the
VPN/FireWall Module
Explanation : By default the parameter “resolve_interface_ranges” is
“true” on the VPN/FireWall Module (objects_5_0.C). This parameter enables
the Module to send its topology data to the Client during topology
download.
In a situation with private IP networks, SecuRemote/SecureClient may
attempt and
exchange keys with the wrong interface IP address (private instead of
public).
Workaround : Set the parameter “resolve_interface_ranges” to “false” in
objects_5_0.C.
b. Failure in Phase 1
Explanation : The problem is caused by using certificates. If so, then
during key
exchange, the CRL is sent by the VPN/FireWall Module in UDP fragmented
packets.
Some routers do not recognize these packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Use IKE over TCP (available in 4.1 SP4 and NG). Note that you
need 4.1 SP5 on the GW for Cluster support.
c. Failure in Phase 2
Explanation : In Phase2, the packet sent by SecuRemote/SecureClient is
very large and may be fragmented. Some routers do not forward fragmented
packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Force UDP Encapsulation (available since 4.1 SP2 and NG) on the
client. This will reduce the size of the packet in Phase 2 and avoid
fragmentation. Another suggestion is to force SC to send smaller payloads;
the value of the property desktop_ike_p2_prop needs to be changed to
“false” in the objects_5_0.C file of the Mgmt station.
3. Symptom : "Communication with site fails" only a few minutes/hours
after the first authentication or communication from gateway to client
fail.
Explanation : Some NAT devices attribute different real IP addresses to
the client over the time. In this configuration, confusion may arise as
two IP addresses will be assigned to the same VPN/FireWall Module.
Workaround :
- Using keep_alive on the Client will automatically send icmp packets and
refresh the NAT device tables.
Solution : VPN-1/FireWall-1 NG FP2 addresses this issue without need of
keep_alive on the Client : basically, it can clearly distinguish SC new
virtual IP.
- However, if a server (behind the GW) initiates new connections, then it
may not work. In this case, the keep-alive packet also needs to match the
UDP/500 packet in order for the gateway to exchange keys with SC; NG FP3
gateway addresses this issue (keep-alive packets are based on UDP/500).
4. Symptom : "Authentication is successful, but I can not access my
corporate network"
There may be different causes.
a. First Reason : SecureClient has a private IP address which is also
defined in
the internal network (not necessarily in the Encryption Domain).
Explanation: VPN/FireWall Module decrypts the packet, translates the
Source IP address with an internal IP address and forwards the packet to
the server. Then the server replies to the Module, which translates the
Destination IP address with the SecureClient IP address, decides to which
interface to send this packet, and then encrypts the packet. The problem
is that the Module decides to forward the packet before encrypting it;
therefore, the decision is taken with the SecureClient’s internal IP
address (e.g., 10.x.x.x). This explains why you may see an encrypted
packet in the internal network.
Workaround:
- First work-around : define different IP schemas in the Encryption Domain
or in SecuRemote/SecureClient.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution: Available in NG FP1 with Office Mode.
b. Second reason : MTU issue
Explanation :
PPPOE protocol reduces the MTU of 8 bytes. Therefore, in DSL connections
where
PPPOE is involved, there may be some MTU issues.
The PPPOE server receives a large packet from the VPN/FireWall Module,
fragments it into two different packets and forwards it to the Client. The
problem is that some NAT devices (e.g., Linksys) drop UDP fragmented
packets (except UDP Encapsulated packets). Therefore, these packets will
never be received by SecuRemote/SecureClient. Also, some other NAT devices
are unable to fragment packets, and therefore send a specific ICMP packet
to the Client in order to reduce the MTU size. This ICMP packet can not be
understood by the VPN Client (it is a general VPN Client issue, and not a
Check Point-related one).
Workaround : Use a NAT device that allows UDP fragmented packets passing
through.
Solution :
- Reduce MTU on SecuRemote/SecureClient to a lower value. In PPPOE
Environment, 1492 should be OK; for other ISP, with PPTP/L2TP
encapsulation, you may need to reduce MTU even lower. Some utilities like
DRTCP (http://www.dslreports.com/front/drtcp.html) can be used.
- In NG FP3, SC Virtual Adapter has a smaller MTU. Therefore, if you’re
using Office Mode, you should not have this problem.
c. Third reason : two SC users with the same IP behind two different NAT
devices
Explanation : if two SC users have the same IP, then VPN-1 may be
confused.
Work-around : use two different IP for these SC users
Solution : use Office Mode.
5. Symptom : "Two users behind the same NAT device can not have access to
the corporate network"
Scenario : Two SecuRemote users behind the same NAT device.
Explanation : Some NAT devices do not translate the Source port and
therefore cannot support the following scenario: IKE is UDP/500 and UDP
Encapsulation is UDP/2746 over static Source/Destination port. It is not a
Check Point, but a NAT device limitation.
Workaround : Use a NAT device that supports port address translation.
Solution:
- SC NG FP3 addresses this issue, by binding in two different UDP ports
for IKE and UDP Encapsulation. In order to support it, you need to force
UDP Encapsulation on the Client and add the option ChangeUDPsport to
“true” in the userc.C .
- with previous SC builds. Some NAT devices handle ESP packets better than
UDP. Therefore, you may want to force ESP. In order to do it, you need to
disable “force UDP Encapsulation” on the Client. On the Mgmt, you need to
change the property udp_encapsulation_by_qm_id from “true” to “false”.1.
Symptom : "User is not prompted for authentication"
Explanation :
In a scenario with a private IP address (SecureClient has a private IP
address which is also part of the Encryption Domain), SecureClient assumes
that it is located within the Encryption Domain and does not encrypt
packets.
Work-around :
- First work-around : define a different IP address for the SecuRemote/SecureClient
user.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution : Office Mode, a solution to the above problem, was introduced in
NG FP1.
2. Symptom : "Communication with site fails"
There can be a few reasons :
a. Key exchange is performed with the wrong interface IP address of the
VPN/FireWall Module
Explanation : By default the parameter “resolve_interface_ranges” is
“true” on the VPN/FireWall Module (objects_5_0.C). This parameter enables
the Module to send its topology data to the Client during topology
download.
In a situation with private IP networks, SecuRemote/SecureClient may
attempt and
exchange keys with the wrong interface IP address (private instead of
public).
Workaround : Set the parameter “resolve_interface_ranges” to “false” in
objects_5_0.C.
b. Failure in Phase 1
Explanation : The problem is caused by using certificates. If so, then
during key
exchange, the CRL is sent by the VPN/FireWall Module in UDP fragmented
packets.
Some routers do not recognize these packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Use IKE over TCP (available in 4.1 SP4 and NG). Note that you
need 4.1 SP5 on the GW for Cluster support.
c. Failure in Phase 2
Explanation : In Phase2, the packet sent by SecuRemote/SecureClient is
very large and may be fragmented. Some routers do not forward fragmented
packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Force UDP Encapsulation (available since 4.1 SP2 and NG) on the
client. This will reduce the size of the packet in Phase 2 and avoid
fragmentation. Another suggestion is to force SC to send smaller payloads;
the value of the property desktop_ike_p2_prop needs to be changed to
“false” in the objects_5_0.C file of the Mgmt station.
3. Symptom : "Communication with site fails" only a few minutes/hours
after the first authentication or communication from gateway to client
fail.
Explanation : Some NAT devices attribute different real IP addresses to
the client over the time. In this configuration, confusion may arise as
two IP addresses will be assigned to the same VPN/FireWall Module.
Workaround :
- Using keep_alive on the Client will automatically send icmp packets and
refresh the NAT device tables.
Solution : VPN-1/FireWall-1 NG FP2 addresses this issue without need of
keep_alive on the Client : basically, it can clearly distinguish SC new
virtual IP.
- However, if a server (behind the GW) initiates new connections, then it
may not work. In this case, the keep-alive packet also needs to match the
UDP/500 packet in order for the gateway to exchange keys with SC; NG FP3
gateway addresses this issue (keep-alive packets are based on UDP/500).
4. Symptom : "Authentication is successful, but I can not access my
corporate network"
There may be different causes.
a. First Reason : SecureClient has a private IP address which is also
defined in
the internal network (not necessarily in the Encryption Domain).
Explanation: VPN/FireWall Module decrypts the packet, translates the
Source IP address with an internal IP address and forwards the packet to
the server. Then the server replies to the Module, which translates the
Destination IP address with the SecureClient IP address, decides to which
interface to send this packet, and then encrypts the packet. The problem
is that the Module decides to forward the packet before encrypting it;
therefore, the decision is taken with the SecureClient’s internal IP
address (e.g., 10.x.x.x). This explains why you may see an encrypted
packet in the internal network.
Workaround:
- First work-around : define different IP schemas in the Encryption Domain
or in SecuRemote/SecureClient.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution: Available in NG FP1 with Office Mode.
b. Second reason : MTU issue
Explanation :
PPPOE protocol reduces the MTU of 8 bytes. Therefore, in DSL connections
where
PPPOE is involved, there may be some MTU issues.
The PPPOE server receives a large packet from the VPN/FireWall Module,
fragments it into two different packets and forwards it to the Client. The
problem is that some NAT devices (e.g., Linksys) drop UDP fragmented
packets (except UDP Encapsulated packets). Therefore, these packets will
never be received by SecuRemote/SecureClient. Also, some other NAT devices
are unable to fragment packets, and therefore send a specific ICMP packet
to the Client in order to reduce the MTU size. This ICMP packet can not be
understood by the VPN Client (it is a general VPN Client issue, and not a
Check Point-related one).
Workaround : Use a NAT device that allows UDP fragmented packets passing
through.
Solution :
- Reduce MTU on SecuRemote/SecureClient to a lower value. In PPPOE
Environment, 1492 should be OK; for other ISP, with PPTP/L2TP
encapsulation, you may need to reduce MTU even lower. Some utilities like
DRTCP (http://www.dslreports.com/front/drtcp.html) can be used.
- In NG FP3, SC Virtual Adapter has a smaller MTU. Therefore, if you’re
using Office Mode, you should not have this problem.
c. Third reason : two SC users with the same IP behind two different NAT
devices
Explanation : if two SC users have the same IP, then VPN-1 may be
confused.
Work-around : use two different IP for these SC users
Solution : use Office Mode.
5. Symptom : "Two users behind the same NAT device can not have access to
the corporate network"
Scenario : Two SecuRemote users behind the same NAT device.
Explanation : Some NAT devices do not translate the Source port and
therefore cannot support the following scenario: IKE is UDP/500 and UDP
Encapsulation is UDP/2746 over static Source/Destination port. It is not a
Check Point, but a NAT device limitation.
Workaround : Use a NAT device that supports port address translation.
Solution:
- SC NG FP3 addresses this issue, by binding in two different UDP ports
for IKE and UDP Encapsulation. In order to support it, you need to force
UDP Encapsulation on the Client and add the option ChangeUDPsport to
“true” in the userc.C .
- with previous SC builds. Some NAT devices handle ESP packets better than
UDP. Therefore, you may want to force ESP. In order to do it, you need to
disable “force UDP Encapsulation” on the Client. On the Mgmt, you need to
change the property udp_encapsulation_by_qm_id from “true” to “false”.1.
Symptom : "User is not prompted for authentication"
Explanation :
In a scenario with a private IP address (SecureClient has a private IP
address which is also part of the Encryption Domain), SecureClient assumes
that it is located within the Encryption Domain and does not encrypt
packets.
Work-around :
- First work-around : define a different IP address for the SecuRemote/SecureClient
user.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution : Office Mode, a solution to the above problem, was introduced in
NG FP1.
2. Symptom : "Communication with site fails"
There can be a few reasons :
a. Key exchange is performed with the wrong interface IP address of the
VPN/FireWall Module
Explanation : By default the parameter “resolve_interface_ranges” is
“true” on the VPN/FireWall Module (objects_5_0.C). This parameter enables
the Module to send its topology data to the Client during topology
download.
In a situation with private IP networks, SecuRemote/SecureClient may
attempt and
exchange keys with the wrong interface IP address (private instead of
public).
Workaround : Set the parameter “resolve_interface_ranges” to “false” in
objects_5_0.C.
b. Failure in Phase 1
Explanation : The problem is caused by using certificates. If so, then
during key
exchange, the CRL is sent by the VPN/FireWall Module in UDP fragmented
packets.
Some routers do not recognize these packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Use IKE over TCP (available in 4.1 SP4 and NG). Note that you
need 4.1 SP5 on the GW for Cluster support.
c. Failure in Phase 2
Explanation : In Phase2, the packet sent by SecuRemote/SecureClient is
very large and may be fragmented. Some routers do not forward fragmented
packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Force UDP Encapsulation (available since 4.1 SP2 and NG) on the
client. This will reduce the size of the packet in Phase 2 and avoid
fragmentation. Another suggestion is to force SC to send smaller payloads;
the value of the property desktop_ike_p2_prop needs to be changed to
“false” in the objects_5_0.C file of the Mgmt station.
3. Symptom : "Communication with site fails" only a few minutes/hours
after the first authentication or communication from gateway to client
fail.
Explanation : Some NAT devices attribute different real IP addresses to
the client over the time. In this configuration, confusion may arise as
two IP addresses will be assigned to the same VPN/FireWall Module.
Workaround :
- Using keep_alive on the Client will automatically send icmp packets and
refresh the NAT device tables.
Solution : VPN-1/FireWall-1 NG FP2 addresses this issue without need of
keep_alive on the Client : basically, it can clearly distinguish SC new
virtual IP.
- However, if a server (behind the GW) initiates new connections, then it
may not work. In this case, the keep-alive packet also needs to match the
UDP/500 packet in order for the gateway to exchange keys with SC; NG FP3
gateway addresses this issue (keep-alive packets are based on UDP/500).
4. Symptom : "Authentication is successful, but I can not access my
corporate network"
There may be different causes.
a. First Reason : SecureClient has a private IP address which is also
defined in
the internal network (not necessarily in the Encryption Domain).
Explanation: VPN/FireWall Module decrypts the packet, translates the
Source IP address with an internal IP address and forwards the packet to
the server. Then the server replies to the Module, which translates the
Destination IP address with the SecureClient IP address, decides to which
interface to send this packet, and then encrypts the packet. The problem
is that the Module decides to forward the packet before encrypting it;
therefore, the decision is taken with the SecureClient’s internal IP
address (e.g., 10.x.x.x). This explains why you may see an encrypted
packet in the internal network.
Workaround:
- First work-around : define different IP schemas in the Encryption Domain
or in SecuRemote/SecureClient.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution: Available in NG FP1 with Office Mode.
b. Second reason : MTU issue
Explanation :
PPPOE protocol reduces the MTU of 8 bytes. Therefore, in DSL connections
where
PPPOE is involved, there may be some MTU issues.
The PPPOE server receives a large packet from the VPN/FireWall Module,
fragments it into two different packets and forwards it to the Client. The
problem is that some NAT devices (e.g., Linksys) drop UDP fragmented
packets (except UDP Encapsulated packets). Therefore, these packets will
never be received by SecuRemote/SecureClient. Also, some other NAT devices
are unable to fragment packets, and therefore send a specific ICMP packet
to the Client in order to reduce the MTU size. This ICMP packet can not be
understood by the VPN Client (it is a general VPN Client issue, and not a
Check Point-related one).
Workaround : Use a NAT device that allows UDP fragmented packets passing
through.
Solution :
- Reduce MTU on SecuRemote/SecureClient to a lower value. In PPPOE
Environment, 1492 should be OK; for other ISP, with PPTP/L2TP
encapsulation, you may need to reduce MTU even lower. Some utilities like
DRTCP (http://www.dslreports.com/front/drtcp.html) can be used.
- In NG FP3, SC Virtual Adapter has a smaller MTU. Therefore, if you’re
using Office Mode, you should not have this problem.
c. Third reason : two SC users with the same IP behind two different NAT
devices
Explanation : if two SC users have the same IP, then VPN-1 may be
confused.
Work-around : use two different IP for these SC users
Solution : use Office Mode.
5. Symptom : "Two users behind the same NAT device can not have access to
the corporate network"
Scenario : Two SecuRemote users behind the same NAT device.
Explanation : Some NAT devices do not translate the Source port and
therefore cannot support the following scenario: IKE is UDP/500 and UDP
Encapsulation is UDP/2746 over static Source/Destination port. It is not a
Check Point, but a NAT device limitation.
Workaround : Use a NAT device that supports port address translation.
Solution:
- SC NG FP3 addresses this issue, by binding in two different UDP ports
for IKE and UDP Encapsulation. In order to support it, you need to force
UDP Encapsulation on the Client and add the option ChangeUDPsport to
“true” in the userc.C .
- with previous SC builds. Some NAT devices handle ESP packets better than
UDP. Therefore, you may want to force ESP. In order to do it, you need to
disable “force UDP Encapsulation” on the Client. On the Mgmt, you need to
change the property udp_encapsulation_by_qm_id from “true” to “false”.1.
Symptom : "User is not prompted for authentication"
Explanation :
In a scenario with a private IP address (SecureClient has a private IP
address which is also part of the Encryption Domain), SecureClient assumes
that it is located within the Encryption Domain and does not encrypt
packets.
Work-around :
- First work-around : define a different IP address for the SecuRemote/SecureClient
user.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution : Office Mode, a solution to the above problem, was introduced in
NG FP1.
2. Symptom : "Communication with site fails"
There can be a few reasons :
a. Key exchange is performed with the wrong interface IP address of the
VPN/FireWall Module
Explanation : By default the parameter “resolve_interface_ranges” is
“true” on the VPN/FireWall Module (objects_5_0.C). This parameter enables
the Module to send its topology data to the Client during topology
download.
In a situation with private IP networks, SecuRemote/SecureClient may
attempt and
exchange keys with the wrong interface IP address (private instead of
public).
Workaround : Set the parameter “resolve_interface_ranges” to “false” in
objects_5_0.C.
b. Failure in Phase 1
Explanation : The problem is caused by using certificates. If so, then
during key
exchange, the CRL is sent by the VPN/FireWall Module in UDP fragmented
packets.
Some routers do not recognize these packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Use IKE over TCP (available in 4.1 SP4 and NG). Note that you
need 4.1 SP5 on the GW for Cluster support.
c. Failure in Phase 2
Explanation : In Phase2, the packet sent by SecuRemote/SecureClient is
very large and may be fragmented. Some routers do not forward fragmented
packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Force UDP Encapsulation (available since 4.1 SP2 and NG) on the
client. This will reduce the size of the packet in Phase 2 and avoid
fragmentation. Another suggestion is to force SC to send smaller payloads;
the value of the property desktop_ike_p2_prop needs to be changed to
“false” in the objects_5_0.C file of the Mgmt station.
3. Symptom : "Communication with site fails" only a few minutes/hours
after the first authentication or communication from gateway to client
fail.
Explanation : Some NAT devices attribute different real IP addresses to
the client over the time. In this configuration, confusion may arise as
two IP addresses will be assigned to the same VPN/FireWall Module.
Workaround :
- Using keep_alive on the Client will automatically send icmp packets and
refresh the NAT device tables.
Solution : VPN-1/FireWall-1 NG FP2 addresses this issue without need of
keep_alive on the Client : basically, it can clearly distinguish SC new
virtual IP.
- However, if a server (behind the GW) initiates new connections, then it
may not work. In this case, the keep-alive packet also needs to match the
UDP/500 packet in order for the gateway to exchange keys with SC; NG FP3
gateway addresses this issue (keep-alive packets are based on UDP/500).
4. Symptom : "Authentication is successful, but I can not access my
corporate network"
There may be different causes.
a. First Reason : SecureClient has a private IP address which is also
defined in
the internal network (not necessarily in the Encryption Domain).
Explanation: VPN/FireWall Module decrypts the packet, translates the
Source IP address with an internal IP address and forwards the packet to
the server. Then the server replies to the Module, which translates the
Destination IP address with the SecureClient IP address, decides to which
interface to send this packet, and then encrypts the packet. The problem
is that the Module decides to forward the packet before encrypting it;
therefore, the decision is taken with the SecureClient’s internal IP
address (e.g., 10.x.x.x). This explains why you may see an encrypted
packet in the internal network.
Workaround:
- First work-around : define different IP schemas in the Encryption Domain
or in SecuRemote/SecureClient.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution: Available in NG FP1 with Office Mode.
b. Second reason : MTU issue
Explanation :
PPPOE protocol reduces the MTU of 8 bytes. Therefore, in DSL connections
where
PPPOE is involved, there may be some MTU issues.
The PPPOE server receives a large packet from the VPN/FireWall Module,
fragments it into two different packets and forwards it to the Client. The
problem is that some NAT devices (e.g., Linksys) drop UDP fragmented
packets (except UDP Encapsulated packets). Therefore, these packets will
never be received by SecuRemote/SecureClient. Also, some other NAT devices
are unable to fragment packets, and therefore send a specific ICMP packet
to the Client in order to reduce the MTU size. This ICMP packet can not be
understood by the VPN Client (it is a general VPN Client issue, and not a
Check Point-related one).
Workaround : Use a NAT device that allows UDP fragmented packets passing
through.
Solution :
- Reduce MTU on SecuRemote/SecureClient to a lower value. In PPPOE
Environment, 1492 should be OK; for other ISP, with PPTP/L2TP
encapsulation, you may need to reduce MTU even lower. Some utilities like
DRTCP (http://www.dslreports.com/front/drtcp.html) can be used.
- In NG FP3, SC Virtual Adapter has a smaller MTU. Therefore, if you’re
using Office Mode, you should not have this problem.
c. Third reason : two SC users with the same IP behind two different NAT
devices
Explanation : if two SC users have the same IP, then VPN-1 may be
confused.
Work-around : use two different IP for these SC users
Solution : use Office Mode.
5. Symptom : "Two users behind the same NAT device can not have access to
the corporate network"
Scenario : Two SecuRemote users behind the same NAT device.
Explanation : Some NAT devices do not translate the Source port and
therefore cannot support the following scenario: IKE is UDP/500 and UDP
Encapsulation is UDP/2746 over static Source/Destination port. It is not a
Check Point, but a NAT device limitation.
Workaround : Use a NAT device that supports port address translation.
Solution:
- SC NG FP3 addresses this issue, by binding in two different UDP ports
for IKE and UDP Encapsulation. In order to support it, you need to force
UDP Encapsulation on the Client and add the option ChangeUDPsport to
“true” in the userc.C .
- with previous SC builds. Some NAT devices handle ESP packets better than
UDP. Therefore, you may want to force ESP. In order to do it, you need to
disable “force UDP Encapsulation” on the Client. On the Mgmt, you need to
change the property udp_encapsulation_by_qm_id from “true” to “false”.1.
Symptom : "User is not prompted for authentication"
Explanation :
In a scenario with a private IP address (SecureClient has a private IP
address which is also part of the Encryption Domain), SecureClient assumes
that it is located within the Encryption Domain and does not encrypt
packets.
Work-around :
- First work-around : define a different IP address for the SecuRemote/SecureClient
user.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution : Office Mode, a solution to the above problem, was introduced in
NG FP1.
2. Symptom : "Communication with site fails"
There can be a few reasons :
a. Key exchange is performed with the wrong interface IP address of the
VPN/FireWall Module
Explanation : By default the parameter “resolve_interface_ranges” is
“true” on the VPN/FireWall Module (objects_5_0.C). This parameter enables
the Module to send its topology data to the Client during topology
download.
In a situation with private IP networks, SecuRemote/SecureClient may
attempt and
exchange keys with the wrong interface IP address (private instead of
public).
Workaround : Set the parameter “resolve_interface_ranges” to “false” in
objects_5_0.C.
b. Failure in Phase 1
Explanation : The problem is caused by using certificates. If so, then
during key
exchange, the CRL is sent by the VPN/FireWall Module in UDP fragmented
packets.
Some routers do not recognize these packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Use IKE over TCP (available in 4.1 SP4 and NG). Note that you
need 4.1 SP5 on the GW for Cluster support.
c. Failure in Phase 2
Explanation : In Phase2, the packet sent by SecuRemote/SecureClient is
very large and may be fragmented. Some routers do not forward fragmented
packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Force UDP Encapsulation (available since 4.1 SP2 and NG) on the
client. This will reduce the size of the packet in Phase 2 and avoid
fragmentation. Another suggestion is to force SC to send smaller payloads;
the value of the property desktop_ike_p2_prop needs to be changed to
“false” in the objects_5_0.C file of the Mgmt station.
3. Symptom : "Communication with site fails" only a few minutes/hours
after the first authentication or communication from gateway to client
fail.
Explanation : Some NAT devices attribute different real IP addresses to
the client over the time. In this configuration, confusion may arise as
two IP addresses will be assigned to the same VPN/FireWall Module.
Workaround :
- Using keep_alive on the Client will automatically send icmp packets and
refresh the NAT device tables.
Solution : VPN-1/FireWall-1 NG FP2 addresses this issue without need of
keep_alive on the Client : basically, it can clearly distinguish SC new
virtual IP.
- However, if a server (behind the GW) initiates new connections, then it
may not work. In this case, the keep-alive packet also needs to match the
UDP/500 packet in order for the gateway to exchange keys with SC; NG FP3
gateway addresses this issue (keep-alive packets are based on UDP/500).
4. Symptom : "Authentication is successful, but I can not access my
corporate network"
There may be different causes.
a. First Reason : SecureClient has a private IP address which is also
defined in
the internal network (not necessarily in the Encryption Domain).
Explanation: VPN/FireWall Module decrypts the packet, translates the
Source IP address with an internal IP address and forwards the packet to
the server. Then the server replies to the Module, which translates the
Destination IP address with the SecureClient IP address, decides to which
interface to send this packet, and then encrypts the packet. The problem
is that the Module decides to forward the packet before encrypting it;
therefore, the decision is taken with the SecureClient’s internal IP
address (e.g., 10.x.x.x). This explains why you may see an encrypted
packet in the internal network.
Workaround:
- First work-around : define different IP schemas in the Encryption Domain
or in SecuRemote/SecureClient.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution: Available in NG FP1 with Office Mode.
b. Second reason : MTU issue
Explanation :
PPPOE protocol reduces the MTU of 8 bytes. Therefore, in DSL connections
where
PPPOE is involved, there may be some MTU issues.
The PPPOE server receives a large packet from the VPN/FireWall Module,
fragments it into two different packets and forwards it to the Client. The
problem is that some NAT devices (e.g., Linksys) drop UDP fragmented
packets (except UDP Encapsulated packets). Therefore, these packets will
never be received by SecuRemote/SecureClient. Also, some other NAT devices
are unable to fragment packets, and therefore send a specific ICMP packet
to the Client in order to reduce the MTU size. This ICMP packet can not be
understood by the VPN Client (it is a general VPN Client issue, and not a
Check Point-related one).
Workaround : Use a NAT device that allows UDP fragmented packets passing
through.
Solution :
- Reduce MTU on SecuRemote/SecureClient to a lower value. In PPPOE
Environment, 1492 should be OK; for other ISP, with PPTP/L2TP
encapsulation, you may need to reduce MTU even lower. Some utilities like
DRTCP (http://www.dslreports.com/front/drtcp.html) can be used.
- In NG FP3, SC Virtual Adapter has a smaller MTU. Therefore, if you’re
using Office Mode, you should not have this problem.
c. Third reason : two SC users with the same IP behind two different NAT
devices
Explanation : if two SC users have the same IP, then VPN-1 may be
confused.
Work-around : use two different IP for these SC users
Solution : use Office Mode.
5. Symptom : "Two users behind the same NAT device can not have access to
the corporate network"
Scenario : Two SecuRemote users behind the same NAT device.
Explanation : Some NAT devices do not translate the Source port and
therefore cannot support the following scenario: IKE is UDP/500 and UDP
Encapsulation is UDP/2746 over static Source/Destination port. It is not a
Check Point, but a NAT device limitation.
Workaround : Use a NAT device that supports port address translation.
Solution:
- SC NG FP3 addresses this issue, by binding in two different UDP ports
for IKE and UDP Encapsulation. In order to support it, you need to force
UDP Encapsulation on the Client and add the option ChangeUDPsport to
“true” in the userc.C .
- with previous SC builds. Some NAT devices handle ESP packets better than
UDP. Therefore, you may want to force ESP. In order to do it, you need to
disable “force UDP Encapsulation” on the Client. On the Mgmt, you need to
change the property udp_encapsulation_by_qm_id from “true” to “false”.1.
Symptom : "User is not prompted for authentication"
Explanation :
In a scenario with a private IP address (SecureClient has a private IP
address which is also part of the Encryption Domain), SecureClient assumes
that it is located within the Encryption Domain and does not encrypt
packets.
Work-around :
- First work-around : define a different IP address for the SecuRemote/SecureClient
user.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution : Office Mode, a solution to the above problem, was introduced in
NG FP1.
2. Symptom : "Communication with site fails"
There can be a few reasons :
a. Key exchange is performed with the wrong interface IP address of the
VPN/FireWall Module
Explanation : By default the parameter “resolve_interface_ranges” is
“true” on the VPN/FireWall Module (objects_5_0.C). This parameter enables
the Module to send its topology data to the Client during topology
download.
In a situation with private IP networks, SecuRemote/SecureClient may
attempt and
exchange keys with the wrong interface IP address (private instead of
public).
Workaround : Set the parameter “resolve_interface_ranges” to “false” in
objects_5_0.C.
b. Failure in Phase 1
Explanation : The problem is caused by using certificates. If so, then
during key
exchange, the CRL is sent by the VPN/FireWall Module in UDP fragmented
packets.
Some routers do not recognize these packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Use IKE over TCP (available in 4.1 SP4 and NG). Note that you
need 4.1 SP5 on the GW for Cluster support.
c. Failure in Phase 2
Explanation : In Phase2, the packet sent by SecuRemote/SecureClient is
very large and may be fragmented. Some routers do not forward fragmented
packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Force UDP Encapsulation (available since 4.1 SP2 and NG) on the
client. This will reduce the size of the packet in Phase 2 and avoid
fragmentation. Another suggestion is to force SC to send smaller payloads;
the value of the property desktop_ike_p2_prop needs to be changed to
“false” in the objects_5_0.C file of the Mgmt station.
3. Symptom : "Communication with site fails" only a few minutes/hours
after the first authentication or communication from gateway to client
fail.
Explanation : Some NAT devices attribute different real IP addresses to
the client over the time. In this configuration, confusion may arise as
two IP addresses will be assigned to the same VPN/FireWall Module.
Workaround :
- Using keep_alive on the Client will automatically send icmp packets and
refresh the NAT device tables.
Solution : VPN-1/FireWall-1 NG FP2 addresses this issue without need of
keep_alive on the Client : basically, it can clearly distinguish SC new
virtual IP.
- However, if a server (behind the GW) initiates new connections, then it
may not work. In this case, the keep-alive packet also needs to match the
UDP/500 packet in order for the gateway to exchange keys with SC; NG FP3
gateway addresses this issue (keep-alive packets are based on UDP/500).
4. Symptom : "Authentication is successful, but I can not access my
corporate network"
There may be different causes.
a. First Reason : SecureClient has a private IP address which is also
defined in
the internal network (not necessarily in the Encryption Domain).
Explanation: VPN/FireWall Module decrypts the packet, translates the
Source IP address with an internal IP address and forwards the packet to
the server. Then the server replies to the Module, which translates the
Destination IP address with the SecureClient IP address, decides to which
interface to send this packet, and then encrypts the packet. The problem
is that the Module decides to forward the packet before encrypting it;
therefore, the decision is taken with the SecureClient’s internal IP
address (e.g., 10.x.x.x). This explains why you may see an encrypted
packet in the internal network.
Workaround:
- First work-around : define different IP schemas in the Encryption Domain
or in SecuRemote/SecureClient.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution: Available in NG FP1 with Office Mode.
b. Second reason : MTU issue
Explanation :
PPPOE protocol reduces the MTU of 8 bytes. Therefore, in DSL connections
where
PPPOE is involved, there may be some MTU issues.
The PPPOE server receives a large packet from the VPN/FireWall Module,
fragments it into two different packets and forwards it to the Client. The
problem is that some NAT devices (e.g., Linksys) drop UDP fragmented
packets (except UDP Encapsulated packets). Therefore, these packets will
never be received by SecuRemote/SecureClient. Also, some other NAT devices
are unable to fragment packets, and therefore send a specific ICMP packet
to the Client in order to reduce the MTU size. This ICMP packet can not be
understood by the VPN Client (it is a general VPN Client issue, and not a
Check Point-related one).
Workaround : Use a NAT device that allows UDP fragmented packets passing
through.
Solution :
- Reduce MTU on SecuRemote/SecureClient to a lower value. In PPPOE
Environment, 1492 should be OK; for other ISP, with PPTP/L2TP
encapsulation, you may need to reduce MTU even lower. Some utilities like
DRTCP (http://www.dslreports.com/front/drtcp.html) can be used.
- In NG FP3, SC Virtual Adapter has a smaller MTU. Therefore, if you’re
using Office Mode, you should not have this problem.
c. Third reason : two SC users with the same IP behind two different NAT
devices
Explanation : if two SC users have the same IP, then VPN-1 may be
confused.
Work-around : use two different IP for these SC users
Solution : use Office Mode.
5. Symptom : "Two users behind the same NAT device can not have access to
the corporate network"
Scenario : Two SecuRemote users behind the same NAT device.
Explanation : Some NAT devices do not translate the Source port and
therefore cannot support the following scenario: IKE is UDP/500 and UDP
Encapsulation is UDP/2746 over static Source/Destination port. It is not a
Check Point, but a NAT device limitation.
Workaround : Use a NAT device that supports port address translation.
Solution:
- SC NG FP3 addresses this issue, by binding in two different UDP ports
for IKE and UDP Encapsulation. In order to support it, you need to force
UDP Encapsulation on the Client and add the option ChangeUDPsport to
“true” in the userc.C .
- with previous SC builds. Some NAT devices handle ESP packets better than
UDP. Therefore, you may want to force ESP. In order to do it, you need to
disable “force UDP Encapsulation” on the Client. On the Mgmt, you need to
change the property udp_encapsulation_by_qm_id from “true” to “false”.1.
Symptom : "User is not prompted for authentication"
Explanation :
In a scenario with a private IP address (SecureClient has a private IP
address which is also part of the Encryption Domain), SecureClient assumes
that it is located within the Encryption Domain and does not encrypt
packets.
Work-around :
- First work-around : define a different IP address for the SecuRemote/SecureClient
user.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution : Office Mode, a solution to the above problem, was introduced in
NG FP1.
2. Symptom : "Communication with site fails"
There can be a few reasons :
a. Key exchange is performed with the wrong interface IP address of the
VPN/FireWall Module
Explanation : By default the parameter “resolve_interface_ranges” is
“true” on the VPN/FireWall Module (objects_5_0.C). This parameter enables
the Module to send its topology data to the Client during topology
download.
In a situation with private IP networks, SecuRemote/SecureClient may
attempt and
exchange keys with the wrong interface IP address (private instead of
public).
Workaround : Set the parameter “resolve_interface_ranges” to “false” in
objects_5_0.C.
b. Failure in Phase 1
Explanation : The problem is caused by using certificates. If so, then
during key
exchange, the CRL is sent by the VPN/FireWall Module in UDP fragmented
packets.
Some routers do not recognize these packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Use IKE over TCP (available in 4.1 SP4 and NG). Note that you
need 4.1 SP5 on the GW for Cluster support.
c. Failure in Phase 2
Explanation : In Phase2, the packet sent by SecuRemote/SecureClient is
very large and may be fragmented. Some routers do not forward fragmented
packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Force UDP Encapsulation (available since 4.1 SP2 and NG) on the
client. This will reduce the size of the packet in Phase 2 and avoid
fragmentation. Another suggestion is to force SC to send smaller payloads;
the value of the property desktop_ike_p2_prop needs to be changed to
“false” in the objects_5_0.C file of the Mgmt station.
3. Symptom : "Communication with site fails" only a few minutes/hours
after the first authentication or communication from gateway to client
fail.
Explanation : Some NAT devices attribute different real IP addresses to
the client over the time. In this configuration, confusion may arise as
two IP addresses will be assigned to the same VPN/FireWall Module.
Workaround :
- Using keep_alive on the Client will automatically send icmp packets and
refresh the NAT device tables.
Solution : VPN-1/FireWall-1 NG FP2 addresses this issue without need of
keep_alive on the Client : basically, it can clearly distinguish SC new
virtual IP.
- However, if a server (behind the GW) initiates new connections, then it
may not work. In this case, the keep-alive packet also needs to match the
UDP/500 packet in order for the gateway to exchange keys with SC; NG FP3
gateway addresses this issue (keep-alive packets are based on UDP/500).
4. Symptom : "Authentication is successful, but I can not access my
corporate network"
There may be different causes.
a. First Reason : SecureClient has a private IP address which is also
defined in
the internal network (not necessarily in the Encryption Domain).
Explanation: VPN/FireWall Module decrypts the packet, translates the
Source IP address with an internal IP address and forwards the packet to
the server. Then the server replies to the Module, which translates the
Destination IP address with the SecureClient IP address, decides to which
interface to send this packet, and then encrypts the packet. The problem
is that the Module decides to forward the packet before encrypting it;
therefore, the decision is taken with the SecureClient’s internal IP
address (e.g., 10.x.x.x). This explains why you may see an encrypted
packet in the internal network.
Workaround:
- First work-around : define different IP schemas in the Encryption Domain
or in SecuRemote/SecureClient.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution: Available in NG FP1 with Office Mode.
b. Second reason : MTU issue
Explanation :
PPPOE protocol reduces the MTU of 8 bytes. Therefore, in DSL connections
where
PPPOE is involved, there may be some MTU issues.
The PPPOE server receives a large packet from the VPN/FireWall Module,
fragments it into two different packets and forwards it to the Client. The
problem is that some NAT devices (e.g., Linksys) drop UDP fragmented
packets (except UDP Encapsulated packets). Therefore, these packets will
never be received by SecuRemote/SecureClient. Also, some other NAT devices
are unable to fragment packets, and therefore send a specific ICMP packet
to the Client in order to reduce the MTU size. This ICMP packet can not be
understood by the VPN Client (it is a general VPN Client issue, and not a
Check Point-related one).
Workaround : Use a NAT device that allows UDP fragmented packets passing
through.
Solution :
- Reduce MTU on SecuRemote/SecureClient to a lower value. In PPPOE
Environment, 1492 should be OK; for other ISP, with PPTP/L2TP
encapsulation, you may need to reduce MTU even lower. Some utilities like
DRTCP (http://www.dslreports.com/front/drtcp.html) can be used.
- In NG FP3, SC Virtual Adapter has a smaller MTU. Therefore, if you’re
using Office Mode, you should not have this problem.
c. Third reason : two SC users with the same IP behind two different NAT
devices
Explanation : if two SC users have the same IP, then VPN-1 may be
confused.
Work-around : use two different IP for these SC users
Solution : use Office Mode.
5. Symptom : "Two users behind the same NAT device can not have access to
the corporate network"
Scenario : Two SecuRemote users behind the same NAT device.
Explanation : Some NAT devices do not translate the Source port and
therefore cannot support the following scenario: IKE is UDP/500 and UDP
Encapsulation is UDP/2746 over static Source/Destination port. It is not a
Check Point, but a NAT device limitation.
Workaround : Use a NAT device that supports port address translation.
Solution:
- SC NG FP3 addresses this issue, by binding in two different UDP ports
for IKE and UDP Encapsulation. In order to support it, you need to force
UDP Encapsulation on the Client and add the option ChangeUDPsport to
“true” in the userc.C .
- with previous SC builds. Some NAT devices handle ESP packets better than
UDP. Therefore, you may want to force ESP. In order to do it, you need to
disable “force UDP Encapsulation” on the Client. On the Mgmt, you need to
change the property udp_encapsulation_by_qm_id from “true” to “false”.1.
Symptom : "User is not prompted for authentication"
Explanation :
In a scenario with a private IP address (SecureClient has a private IP
address which is also part of the Encryption Domain), SecureClient assumes
that it is located within the Encryption Domain and does not encrypt
packets.
Work-around :
- First work-around : define a different IP address for the SecuRemote/SecureClient
user.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution : Office Mode, a solution to the above problem, was introduced in
NG FP1.
2. Symptom : "Communication with site fails"
There can be a few reasons :
a. Key exchange is performed with the wrong interface IP address of the
VPN/FireWall Module
Explanation : By default the parameter “resolve_interface_ranges” is
“true” on the VPN/FireWall Module (objects_5_0.C). This parameter enables
the Module to send its topology data to the Client during topology
download.
In a situation with private IP networks, SecuRemote/SecureClient may
attempt and
exchange keys with the wrong interface IP address (private instead of
public).
Workaround : Set the parameter “resolve_interface_ranges” to “false” in
objects_5_0.C.
b. Failure in Phase 1
Explanation : The problem is caused by using certificates. If so, then
during key
exchange, the CRL is sent by the VPN/FireWall Module in UDP fragmented
packets.
Some routers do not recognize these packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Use IKE over TCP (available in 4.1 SP4 and NG). Note that you
need 4.1 SP5 on the GW for Cluster support.
c. Failure in Phase 2
Explanation : In Phase2, the packet sent by SecuRemote/SecureClient is
very large and may be fragmented. Some routers do not forward fragmented
packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Force UDP Encapsulation (available since 4.1 SP2 and NG) on the
client. This will reduce the size of the packet in Phase 2 and avoid
fragmentation. Another suggestion is to force SC to send smaller payloads;
the value of the property desktop_ike_p2_prop needs to be changed to
“false” in the objects_5_0.C file of the Mgmt station.
3. Symptom : "Communication with site fails" only a few minutes/hours
after the first authentication or communication from gateway to client
fail.
Explanation : Some NAT devices attribute different real IP addresses to
the client over the time. In this configuration, confusion may arise as
two IP addresses will be assigned to the same VPN/FireWall Module.
Workaround :
- Using keep_alive on the Client will automatically send icmp packets and
refresh the NAT device tables.
Solution : VPN-1/FireWall-1 NG FP2 addresses this issue without need of
keep_alive on the Client : basically, it can clearly distinguish SC new
virtual IP.
- However, if a server (behind the GW) initiates new connections, then it
may not work. In this case, the keep-alive packet also needs to match the
UDP/500 packet in order for the gateway to exchange keys with SC; NG FP3
gateway addresses this issue (keep-alive packets are based on UDP/500).
4. Symptom : "Authentication is successful, but I can not access my
corporate network"
There may be different causes.
a. First Reason : SecureClient has a private IP address which is also
defined in
the internal network (not necessarily in the Encryption Domain).
Explanation: VPN/FireWall Module decrypts the packet, translates the
Source IP address with an internal IP address and forwards the packet to
the server. Then the server replies to the Module, which translates the
Destination IP address with the SecureClient IP address, decides to which
interface to send this packet, and then encrypts the packet. The problem
is that the Module decides to forward the packet before encrypting it;
therefore, the decision is taken with the SecureClient’s internal IP
address (e.g., 10.x.x.x). This explains why you may see an encrypted
packet in the internal network.
Workaround:
- First work-around : define different IP schemas in the Encryption Domain
or in SecuRemote/SecureClient.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution: Available in NG FP1 with Office Mode.
b. Second reason : MTU issue
Explanation :
PPPOE protocol reduces the MTU of 8 bytes. Therefore, in DSL connections
where
PPPOE is involved, there may be some MTU issues.
The PPPOE server receives a large packet from the VPN/FireWall Module,
fragments it into two different packets and forwards it to the Client. The
problem is that some NAT devices (e.g., Linksys) drop UDP fragmented
packets (except UDP Encapsulated packets). Therefore, these packets will
never be received by SecuRemote/SecureClient. Also, some other NAT devices
are unable to fragment packets, and therefore send a specific ICMP packet
to the Client in order to reduce the MTU size. This ICMP packet can not be
understood by the VPN Client (it is a general VPN Client issue, and not a
Check Point-related one).
Workaround : Use a NAT device that allows UDP fragmented packets passing
through.
Solution :
- Reduce MTU on SecuRemote/SecureClient to a lower value. In PPPOE
Environment, 1492 should be OK; for other ISP, with PPTP/L2TP
encapsulation, you may need to reduce MTU even lower. Some utilities like
DRTCP (http://www.dslreports.com/front/drtcp.html) can be used.
- In NG FP3, SC Virtual Adapter has a smaller MTU. Therefore, if you’re
using Office Mode, you should not have this problem.
c. Third reason : two SC users with the same IP behind two different NAT
devices
Explanation : if two SC users have the same IP, then VPN-1 may be
confused.
Work-around : use two different IP for these SC users
Solution : use Office Mode.
5. Symptom : "Two users behind the same NAT device can not have access to
the corporate network"
Scenario : Two SecuRemote users behind the same NAT device.
Explanation : Some NAT devices do not translate the Source port and
therefore cannot support the following scenario: IKE is UDP/500 and UDP
Encapsulation is UDP/2746 over static Source/Destination port. It is not a
Check Point, but a NAT device limitation.
Workaround : Use a NAT device that supports port address translation.
Solution:
- SC NG FP3 addresses this issue, by binding in two different UDP ports
for IKE and UDP Encapsulation. In order to support it, you need to force
UDP Encapsulation on the Client and add the option ChangeUDPsport to
“true” in the userc.C .
- with previous SC builds. Some NAT devices handle ESP packets better than
UDP. Therefore, you may want to force ESP. In order to do it, you need to
disable “force UDP Encapsulation” on the Client. On the Mgmt, you need to
change the property udp_encapsulation_by_qm_id from “true” to “false”.1.
Symptom : "User is not prompted for authentication"
Explanation :
In a scenario with a private IP address (SecureClient has a private IP
address which is also part of the Encryption Domain), SecureClient assumes
that it is located within the Encryption Domain and does not encrypt
packets.
Work-around :
- First work-around : define a different IP address for the SecuRemote/SecureClient
user.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution : Office Mode, a solution to the above problem, was introduced in
NG FP1.
2. Symptom : "Communication with site fails"
There can be a few reasons :
a. Key exchange is performed with the wrong interface IP address of the
VPN/FireWall Module
Explanation : By default the parameter “resolve_interface_ranges” is
“true” on the VPN/FireWall Module (objects_5_0.C). This parameter enables
the Module to send its topology data to the Client during topology
download.
In a situation with private IP networks, SecuRemote/SecureClient may
attempt and
exchange keys with the wrong interface IP address (private instead of
public).
Workaround : Set the parameter “resolve_interface_ranges” to “false” in
objects_5_0.C.
b. Failure in Phase 1
Explanation : The problem is caused by using certificates. If so, then
during key
exchange, the CRL is sent by the VPN/FireWall Module in UDP fragmented
packets.
Some routers do not recognize these packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Use IKE over TCP (available in 4.1 SP4 and NG). Note that you
need 4.1 SP5 on the GW for Cluster support.
c. Failure in Phase 2
Explanation : In Phase2, the packet sent by SecuRemote/SecureClient is
very large and may be fragmented. Some routers do not forward fragmented
packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Force UDP Encapsulation (available since 4.1 SP2 and NG) on the
client. This will reduce the size of the packet in Phase 2 and avoid
fragmentation. Another suggestion is to force SC to send smaller payloads;
the value of the property desktop_ike_p2_prop needs to be changed to
“false” in the objects_5_0.C file of the Mgmt station.
3. Symptom : "Communication with site fails" only a few minutes/hours
after the first authentication or communication from gateway to client
fail.
Explanation : Some NAT devices attribute different real IP addresses to
the client over the time. In this configuration, confusion may arise as
two IP addresses will be assigned to the same VPN/FireWall Module.
Workaround :
- Using keep_alive on the Client will automatically send icmp packets and
refresh the NAT device tables.
Solution : VPN-1/FireWall-1 NG FP2 addresses this issue without need of
keep_alive on the Client : basically, it can clearly distinguish SC new
virtual IP.
- However, if a server (behind the GW) initiates new connections, then it
may not work. In this case, the keep-alive packet also needs to match the
UDP/500 packet in order for the gateway to exchange keys with SC; NG FP3
gateway addresses this issue (keep-alive packets are based on UDP/500).
4. Symptom : "Authentication is successful, but I can not access my
corporate network"
There may be different causes.
a. First Reason : SecureClient has a private IP address which is also
defined in
the internal network (not necessarily in the Encryption Domain).
Explanation: VPN/FireWall Module decrypts the packet, translates the
Source IP address with an internal IP address and forwards the packet to
the server. Then the server replies to the Module, which translates the
Destination IP address with the SecureClient IP address, decides to which
interface to send this packet, and then encrypts the packet. The problem
is that the Module decides to forward the packet before encrypting it;
therefore, the decision is taken with the SecureClient’s internal IP
address (e.g., 10.x.x.x). This explains why you may see an encrypted
packet in the internal network.
Workaround:
- First work-around : define different IP schemas in the Encryption Domain
or in SecuRemote/SecureClient.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution: Available in NG FP1 with Office Mode.
b. Second reason : MTU issue
Explanation :
PPPOE protocol reduces the MTU of 8 bytes. Therefore, in DSL connections
where
PPPOE is involved, there may be some MTU issues.
The PPPOE server receives a large packet from the VPN/FireWall Module,
fragments it into two different packets and forwards it to the Client. The
problem is that some NAT devices (e.g., Linksys) drop UDP fragmented
packets (except UDP Encapsulated packets). Therefore, these packets will
never be received by SecuRemote/SecureClient. Also, some other NAT devices
are unable to fragment packets, and therefore send a specific ICMP packet
to the Client in order to reduce the MTU size. This ICMP packet can not be
understood by the VPN Client (it is a general VPN Client issue, and not a
Check Point-related one).
Workaround : Use a NAT device that allows UDP fragmented packets passing
through.
Solution :
- Reduce MTU on SecuRemote/SecureClient to a lower value. In PPPOE
Environment, 1492 should be OK; for other ISP, with PPTP/L2TP
encapsulation, you may need to reduce MTU even lower. Some utilities like
DRTCP (http://www.dslreports.com/front/drtcp.html) can be used.
- In NG FP3, SC Virtual Adapter has a smaller MTU. Therefore, if you’re
using Office Mode, you should not have this problem.
c. Third reason : two SC users with the same IP behind two different NAT
devices
Explanation : if two SC users have the same IP, then VPN-1 may be
confused.
Work-around : use two different IP for these SC users
Solution : use Office Mode.
5. Symptom : "Two users behind the same NAT device can not have access to
the corporate network"
Scenario : Two SecuRemote users behind the same NAT device.
Explanation : Some NAT devices do not translate the Source port and
therefore cannot support the following scenario: IKE is UDP/500 and UDP
Encapsulation is UDP/2746 over static Source/Destination port. It is not a
Check Point, but a NAT device limitation.
Workaround : Use a NAT device that supports port address translation.
Solution:
- SC NG FP3 addresses this issue, by binding in two different UDP ports
for IKE and UDP Encapsulation. In order to support it, you need to force
UDP Encapsulation on the Client and add the option ChangeUDPsport to
“true” in the userc.C .
- with previous SC builds. Some NAT devices handle ESP packets better than
UDP. Therefore, you may want to force ESP. In order to do it, you need to
disable “force UDP Encapsulation” on the Client. On the Mgmt, you need to
change the property udp_encapsulation_by_qm_id from “true” to “false”.1.
Symptom : "User is not prompted for authentication"
Explanation :
In a scenario with a private IP address (SecureClient has a private IP
address which is also part of the Encryption Domain), SecureClient assumes
that it is located within the Encryption Domain and does not encrypt
packets.
Work-around :
- First work-around : define a different IP address for the SecuRemote/SecureClient
user.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution : Office Mode, a solution to the above problem, was introduced in
NG FP1.
2. Symptom : "Communication with site fails"
There can be a few reasons :
a. Key exchange is performed with the wrong interface IP address of the
VPN/FireWall Module
Explanation : By default the parameter “resolve_interface_ranges” is
“true” on the VPN/FireWall Module (objects_5_0.C). This parameter enables
the Module to send its topology data to the Client during topology
download.
In a situation with private IP networks, SecuRemote/SecureClient may
attempt and
exchange keys with the wrong interface IP address (private instead of
public).
Workaround : Set the parameter “resolve_interface_ranges” to “false” in
objects_5_0.C.
b. Failure in Phase 1
Explanation : The problem is caused by using certificates. If so, then
during key
exchange, the CRL is sent by the VPN/FireWall Module in UDP fragmented
packets.
Some routers do not recognize these packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Use IKE over TCP (available in 4.1 SP4 and NG). Note that you
need 4.1 SP5 on the GW for Cluster support.
c. Failure in Phase 2
Explanation : In Phase2, the packet sent by SecuRemote/SecureClient is
very large and may be fragmented. Some routers do not forward fragmented
packets and drop them.
Workaround : Some NAT devices (e.g., Linksys) address this issue in their
latest
firmware update. Updating the firmware may help.
Solution : Force UDP Encapsulation (available since 4.1 SP2 and NG) on the
client. This will reduce the size of the packet in Phase 2 and avoid
fragmentation. Another suggestion is to force SC to send smaller payloads;
the value of the property desktop_ike_p2_prop needs to be changed to
“false” in the objects_5_0.C file of the Mgmt station.
3. Symptom : "Communication with site fails" only a few minutes/hours
after the first authentication or communication from gateway to client
fail.
Explanation : Some NAT devices attribute different real IP addresses to
the client over the time. In this configuration, confusion may arise as
two IP addresses will be assigned to the same VPN/FireWall Module.
Workaround :
- Using keep_alive on the Client will automatically send icmp packets and
refresh the NAT device tables.
Solution : VPN-1/FireWall-1 NG FP2 addresses this issue without need of
keep_alive on the Client : basically, it can clearly distinguish SC new
virtual IP.
- However, if a server (behind the GW) initiates new connections, then it
may not work. In this case, the keep-alive packet also needs to match the
UDP/500 packet in order for the gateway to exchange keys with SC; NG FP3
gateway addresses this issue (keep-alive packets are based on UDP/500).
4. Symptom : "Authentication is successful, but I can not access my
corporate network"
There may be different causes.
a. First Reason : SecureClient has a private IP address which is also
defined in
the internal network (not necessarily in the Encryption Domain).
Explanation: VPN/FireWall Module decrypts the packet, translates the
Source IP address with an internal IP address and forwards the packet to
the server. Then the server replies to the Module, which translates the
Destination IP address with the SecureClient IP address, decides to which
interface to send this packet, and then encrypts the packet. The problem
is that the Module decides to forward the packet before encrypting it;
therefore, the decision is taken with the SecureClient’s internal IP
address (e.g., 10.x.x.x). This explains why you may see an encrypted
packet in the internal network.
Workaround:
- First work-around : define different IP schemas in the Encryption Domain
or in SecuRemote/SecureClient.
- Second work-around : if you can’t change SR/SC IP, then you can install
a new NAT device, put SR/SC behind this NAT device and define a different
IP.
Solution: Available in NG FP1 with Office Mode.
b. Second reason : MTU issue
Explanation :
PPPOE protocol reduces the MTU of 8 bytes. Therefore, in DSL connections
where
PPPOE is involved, there may be some MTU issues.
The PPPOE server receives a large packet from the VPN/FireWall Module,
fragments it into two different packets and forwards it to the Client. The
problem is that some NAT devices (e.g., Linksys) drop UDP fragmented
packets (except UDP Encapsulated packets). Therefore, these packets will
never be received by SecuRemote/SecureClient. Also, some other NAT devices
are unable to fragment packets, and therefore send a specific ICMP packet
to the Client in order to reduce the MTU size. This ICMP packet can not be
understood by the VPN Client (it is a general VPN Client issue, and not a
Check Point-related one).
Workaround : Use a NAT device that allows UDP fragmented packets passing
through.
Solution :
- Reduce MTU on SecuRemote/SecureClient to a lower value. In PPPOE
Environment, 1492 should be OK; for other ISP, with PPTP/L2TP
encapsulation, you may need to reduce MTU even lower. Some utilities like
DRTCP (http://www.dslreports.com/front/drtcp.html) can be used.
- In NG FP3, SC Virtual Adapter has a smaller MTU. Therefore, if you’re
using Office Mode, you should not have this problem.
c. Third reason : two SC users with the same IP behind two different NAT
devices
Explanation : if two SC users have the same IP, then VPN-1 may be
confused.
Work-around : use two different IP for these SC users
Solution : use Office Mode.
5. Symptom : "Two users behind the same NAT device can not have access to
the corporate network"
Scenario : Two SecuRemote users behind the same NAT device.
Explanation : Some NAT devices do not translate the Source port and
therefore cannot support the following scenario: IKE is UDP/500 and UDP
Encapsulation is UDP/2746 over static Source/Destination port. It is not a
Check Point, but a NAT device limitation.
Workaround : Use a NAT device that supports port address translation.
Solution:
- SC NG FP3 addresses this issue, by binding in two different UDP ports
for IKE and UDP Encapsulation. In order to support it, you need to force
UDP Encapsulation on the Client and add the option ChangeUDPsport to
“true” in the userc.C .
- with previous SC builds. Some NAT devices handle ESP packets better than
UDP. Therefore, you may want to force ESP. In order to do it, you need to
disable “force UDP Encapsulation” on the Client. On the Mgmt, you need to
change the property udp_encapsulation_by_qm_id from “true” to “false”.
24/JULY/03
<
back
|