CPUG

The Check Point User Group

A Resource For The Check Point Community.  Fast.  Useful.  Independent.

1. CCSA/CCSE One-Week Dual-Certification Training Course with CPUG in San Francisco!
    Courses Starting 12/8, (2009) 1/19, 2/9, 3/9, 4/6, 5/4, 6/8, 7/6, 8/3.
2. Join Us On LinkedIn - We now have a CPUG group.


Go Back   CPUG: The Check Point User Group > Check Point Firewall-1/VPN-1 And Related Products > SmartDefense
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 2007-01-06
Junior Member
 
Join Date: 2006-08-30
Posts: 5
Rep Power: 0
packnet has an average reputation (10+)
Default VPN error - SmartDefense

NGX HFA3, VPN with an ASA. Simple HTTP request, key install looks good. I get good log entries for the encrypted connection to a remote web server over http, but it is followed within about a minute by this error:

reason: WSE0010005 can't connect to server 'xxx.xxxxxx.com'
resource:
http://xxx.xxxxxx.com

I've obfuscated the URL in the info from the log entry above.

I've not contacted the peer yet to check their logs, but I'm frustrated that I can't seem to search on that WSE entry. I have no http security server definitions, or resources defined in this policy. The error is listed by the SmartDefense daemon, but I'm still not entirely sure what function may be picking that up. For all I know, their server is down and that's just the response that comes back.
Reply With Quote
  #2 (permalink)  
Old 2007-01-26
Junior Member
 
Join Date: 2006-05-26
Location: Wisconsin, USA
Posts: 17
Rep Power: 0
ldgunnink has an average reputation (10+)
Default Re: VPN error - SmartDefense

I'm not sure if you are still having this problem, but I recently saw this as well. I set up an IPSO cluster with 2 IP265s, and after the cluster came up, the users saw that some web sites were accessible, and some were not. The logs showed the error you mentioned, but I also saw much of the traffic being accepted, even though the sites were not accessible.

Long story short, we eventually determined that that problem was caused by the Smart Defense rule (under Web Intelligence in R60) "ASCII only response headers." Even though we only had this rule set to monitor, it still blocked the http connections. After we completely disabled this Smart Defense rule and pushed the policy, the problem disappeared. I hope this helps.

Loren
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


All times are GMT -7. The time now is 11:16.


Powered by vBulletin® Version 3.7.4
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.2.0