VPN behind Checkpoint firewall

[jabbott]

I need to setup a rule for a contractor to connect to his office's vpn. He is on our network which is behind a checkpoint firewall. He is using the Cisco VPN client software on his laptop to connect to a cisco 3000 vpn. He has it set to do IPSEC over UDP (NAT/PAT).

I have setup a rule for him on our checkpoint that should allow everything from his laptop out, and I even setup a second rule that allows ANY from his office back in. I still get a block message in tracker that says IKE is being blocked. What really confuses me is that it is being blocked by my rule that says Accept Any.

[Sergej]

Ask user to enable NAT traversal on Cisco VPN Client. This function is disabled by default. Also it is good to know if this function enabled on VPN3000. Usually it is on (If administrator do not want constant problems with VPN users)
This can be Checkpoint NAT problem.

[jabbott]

Where is Nat traversal? I can't find that anywhere on the client. The client is version 4.6.x Mac.

We have an email into the admin on the other side.

Thanks for the reply.

--ja

[Sergej]

Here it is.

http://www.cisco.com/univercd/cc/td/....htm#wp1001717

[ddarby1]

Slight correction guys:

The IPSEC over UDP (NAT/PAT) is selected by default on the Cisco VPN Client.

What is the version of Check Point S/W and the exact syntax of the rule in question?

I think I might have a go at recreating this problem using a PIX, Cisco VPN Client and Check Point.

[Sergej]

Originally Posted by ddarby1

The IPSEC over UDP (NAT/PAT) is selected by default on the Cisco VPN Client.

You need to put the check box on the "Enable Transport Tunneling" to made this option active.

[jabbott]

Not sure how to get a rules print out (can you tell I am new at my job? Sorry.) Here is a screen shot of the gui.



If this is not good enough, let me know and I can figure out how to get a text listing.

I have checked with the remote VPN-3000 admin. He confirmed that NAT Traversal is turned on at the vpn end. I checked with my own eyes that the NET Traversal checkie box is checked on the client end.

If I do a tcpdump on the client laptop I get:
11:44:49.974426 IP maclaptop.inet.prettylake.net.isakmp > 156.92.29.240.isakmp: isakmp: phase 1 I agg
13:45:13.682938 IP maclaptop.inet.prettylake.net.isakmp > 156.92.29.240.isakmp: isakmp: phase 1 I agg
13:45:18.972323 IP maclaptop.inet.prettylake.net.isakmp > 156.92.29.240.isakmp: isakmp: phase 1 I agg

I have done a monitor on the checkpoint and have seen the packets there. I am seeing if I can work with someone and drop a sniffer on the outside of our checkpoint to confirm there are packets coming back from the remote vpn. I see no reason why there should not be.

--ja

[Sergej]

I'm using Cisco VPN client daily to connect to some customer sites. Our office is protected with CheckPoint firewall. I do not have such problems.
Try to install VPN client on Windows for test.
Try to 1-to-1 this user behind any other unused external address.

What CP firewall version do you have?

[ddarby1]

Apologies Sergej, even the picture shows it not ticked - my mistake.
I was using the Cisco VPN Client for Windows 4.6 as reference and noticed that the 'Enable Transport Tunneling' box was hecked as default.

Back to the problem, I quickly setup a similar? configuration using a PIX, NGX, Laptop with VPN Client and a router for the internet.

It worked straight away as Sergej mentioned.

I started with a security rule where the laptop could access any destination and a NAT rule where the laptop IP (in fact the internal network) was Hidden behind a single external IP.

In the above case, NAT-T behaves as expected from the Cisco VPN Client.

Going back to your screen shot, it looks like Security Rule #2 should be sufficient on its own, plus a NAT rule, which we can't see.

Presumably the VPN connection works fine normally for the user?

[jabbott]

Yes, the user says he uses the vpn client all the time. This is the first place he has ever had trouble.

The NAT rule shouldn't have to be anything other than our standard nat rule, right? We already have a running network. People are using workstations, surfing out on the net, all behind a natted IP. So, that should be the same rule that covers it, right?

It sure looks to me like rule #2 would be enough to do it too. But I read somewhere on the net in a help document that "All" doesn't cut it for VPN connections. That is why I created rule #1. The ports and protocols I have listed were the ones the document said I had to list seperatly. --It didn't work before I put them in either.

And that really is part of what confuses me so much. Rule number 1, which is a pass rule, not a block rule, generates this in tracker when I try to connect the VPN.

Number: 1770419
Date: 28Feb2006
Time: 13:30:01
Product: VPN-1 & FireWall-1
Interface: eth0
Origin: inetfw (60.224.130.126)
Type: Log
Action: Drop
Service: IKE (500)
Source: John_Abbott_Laptop (192.168.0.172)
Destination: John_Abbott_RemoteSite (156.92.29.240)
Protocol: udp
Rule: 1
Source Port: IKE (500)

So how can a pass rule be creating this block?

--ja

[Lackie]

What type of hardware are you using for your firewall. I have seen Nokia's have trouble with encrypted UDP packets before.

[jabbott]

Hey everyone. I have been gone for a week and then buried for another week but now I am back to this problem. Since I have last posted I got a network tap in place outside the checkpoint. I can now sniff inbound and outbound traffic and I can see that no packets are getting outside of the checkpoint heading toward the remote vpn box. (using tcpdump -vv -s 0 -i sk1 host XXX.XXX.XXX.XXX) So, it seems like I am having trouble somewhere on the inside.

[jabbott]

Is it possible this problem I am having has anything to do with the checkpoint firewall setting in Remote Access:
"Support NAT traversal mechanism (UDP encapsulation)" that I currently have set to VPN1_IPSEC_encapsulation.

Should it be set to something else for this laptop to connect out to a cisco vpn-3000? Can anyone tell me what the default setting is?

--ja

[Lackie]

That setting is for SecuRemote / Secure Client. Not for passing a 3rd party client through the firewall.

What type of hardware are you using for your firewalls? I believe I asked this before but didn't get a response.

[jabbott]

It is somewhere I can't get to in the building without major hurdles. Wanting to take a quick look at it won't pass the first hurdle. So, I asked someone who has worked here longer than I have and they said it is an HP DL-380. They seemed to say it with authority, so it must be correct.

--ja

[chillyjim]

What version of Check Point are you using?

Have you check VPN Protocols section in Smart Defense?

In particular there is a Block IKE Aggressive Exchange section. Cisco's VPN client uses IKE in Aggressive Mode by default, and this protection will block it.

[jabbott]

If I go into the dashboard and do "Help/About Checkpoint SmartDashboard"

I get:
SmartDashboard
NG with Application Intelligence (R55)
Build 127

But is that just the dashboard version info? How do I tell about the actual checkpoint version number?

I don't think we have/pay-for SmartDefense.

[Lackie]

As a test can you statically nat this client to an external IP address rather than hiding it behind the firewall IP address?

[Sergej]

Originally Posted by jabbott

I don't think we have/pay-for SmartDefense.

Ewer If you did not pay for smart defence a lot of rules are included initially. The only difference is you not have upgrades via upgrade button (but still have upgrades by installing of a new version).

[Sergej]

Originally Posted by chillyjim

Have you check VPN Protocols section in Smart Defense?

In particular there is a Block IKE Aggressive Exchange section. Cisco's VPN client uses IKE in Aggressive Mode by default, and this protection will block it.

Yes this rule enabled by default on the NGX. What a funny trick to beat competitor VPN client :)

What a terrible issue! :)

Attack ID: CPAI-2004-15
Description: The Internet Key Exchange (IKE) protocol discloses username information when Aggressive Mode is used for shared secret authentication.