cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
697
Views
0
Helpful
3
Replies

Check Point Client over PIX (PATed)

dwalsh
Level 1
Level 1

Hello,

I'm having a problem getting a Check Point Secure Remote client to work over a PIX PATed interface. Here's the problem:

User is on a 10.x.x.x network here. They are PATed to an interface on the Cisco PIX as they head to the Check Point VPN termination point. They are able to successfully authenticate, but then it comes back with an error "Tunnel Test Failed." and they can't do anything on the other end. I do have IKE over TCP and UDP Encapsulation both turned on and separately turned on, but no luck.

I took the client home thinking it was a problem with the Check Point VPN termination point configuration. I set up my home Linksys router with the same addressing as at work (i.e. 10.x.x.x). It worked fine.

This then tells me that the problem is somehwere on the Cisco stuff at work.

Any ideas?

TIA,

Dave

3 Replies 3

sergej.gurenko
Level 1
Level 1

I have booth CheckPoint and PIX experience.

Make sure that IP address of SecuRemote client is not inside CheckPoint protected subnet. If SecureClient have protected subnet ip address SecureClient think that there is no need to connect to the FW-1 :) because you are inside protected perimeter. It is a common problem! Do you use same inside subnets with LinkSys and PIX?

Which version of CheckPoint do you use? FW and Client. Did checkpoint allow connecting when you creating a new site and doing initial configuration? And fails only when you are trying to connect? Do you using office or transparent mode? Do you use connect mode? Did you tried to recreate Site in SecureRemote?

Hi Sergei,

Thanks for responding. I'll try to answer your questions best I can. However, since I don't manage the Check Point FW, it's kind of hard.

Q1. Do you use same inside subnets with LinkSys and PIX?

A1. Yes. We set up both exactly the same (i.e. 10.64.0.0/128).

Q2. Which version of CheckPoint do you use?

A2a. Not sure, but it's fairly recent and its NG.

A2b. The client just says R55 Build v082 (again, the latest)

Q3. Did checkpoint allow connecting when you creating a new site and doing initial configuration?

A3. Not sure what you mean.

Q4. And fails only when you are trying to connect?

A4. It does authenticate, but then I get that "Tunnel Test Failed" and I can't do anything at all.

Q5. Do you using office or transparent mode?

A5. I think it's transparent mode.

Q6. Do you use connect mode?

A6. Not sure what you mean.

Q7. Did you tried to recreate Site in SecureRemote?

A7. No.

The really peculiar thing is that it works just fine if I take it home behind a Linksys router. I take it to work behind the PIX and it bombs. I did look closer at the PIX log and I'm seeing the following:

Deny udp src outside:192.168.45.1/2746 dst inside:142.176.0.17/27322 by access-group "acl_out"

This is confusing to me. Why would I even be seeing a 192.168.x.x number coming back at me? It shouldn't even be routable across the Net. Just for the heck of it, I did permit the traffic from that, but it didn't help. And I didn't even see any hits on the ACL.

I'm deeply confused on this. Any help you can provide is sure welcome.

Thanks,

Dave

Do you use access-lists on PIX for filtering outbound traffic, or you are using default AdaptiveSecurityAlgoritm rules (all TCP/UDP traffic from highest sec level to lowest allowed)

UDP port 2746 is used CheckPoint NAT traversal mechanism. You log is showing that UDP traffic from CheckPoint SecuRemote with internal IP is not allowed to pass thought PIX firewall.

There are two NAT traversal technologies

--begin--

NAT Traversal

The UDP encapsulation feature solves the problem of a Remote Access Client located behind a NAT device that requires an UDP packet. Since IPSEC packets do not contain a UDP header, the client can encapsulate the whole packet with an UDP header. The header is stripped from the packet before the packet is handled by the IPSEC code. Enabling the UDP encapsulation feature means that the Gateway handles IPSEC packets with UDP encapsulation as well as regular IPSEC packets.

By default, both the source port and destination port in the added UDP header are set to 2746. If desired, set another port as the Allocated port. The designated port is downloaded to the Remote Access client when the client is updated.

Visitor Mode

When a Remote Access client resides behind a device that allows only HTTP or HTTPS connections (or has restrictions on other ports,) a regular VPN cannot be established. Solve this problem by enabling Visitor Mode. By enabling Visitor Mode the communication with the Remote Access client is encapsulated in headers that refer to an allowed port number. By default, 443 is the allowed port. If both parties agreed on a different Allocated port, the port can be reset. Setting of the Allocated IP Address is usually not required. Reset the Allocated IP Address only if another service must run on the same Gateway and bind to the same port allocated for Visitor Mode. Once the desired IP is set, a special daemon runs on the Gateway to handle visitor mode connections; this daemon binds to port 443.

--end--

The booth methods must be enabled per Gateway in RemoteAccess menu (if you want to use them).

Also in global properties "Gateway support IKE over TCP" must be enabled (Remote Access>VPN Basic). Don’t forget to push the policy after changes.

Q3. Did checkpoint allow connecting when you creating a new site and doing initial configuration?

With checkpoint VPN client you first need to create site (icon looks like a binding) When you creating site VPN client asks for username/password and connects to the VPN gateway and downloads all info about protected subnets (topology), VPN capabilities and so on. Then VPN client is ready for use. Theoretically VPN client update topology info time to time, but my experience shows that it is better delete the site (icon) and recreate.

Q6. Do you use connect mode?

Connect mode is like Dial-UP – when you want VPN you are push connect button, whan it is no need push disconnect. Cisco software VPN Client use such ideology. CheckPoint by default use unique (hard to understand) transparent mode. VPN driver analyze all traffic and when is sees packets for protected subnet (VPN domain) it encrypts them and sends to according VPN gateway. There is no connect/disconnect events then.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: