|
|
|
|
|
|
|
|
 |
 |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [FW-1] SecureRemote - NATTing issue??
Hi Group: Thank you for your support. So far, we have not found a correct solution to this problem so I have condensed the subject and troubleshooting for easier reading to resubmit to this group. The comments and suggestions (from me, you, client) that seemed least likely a culprit have been put at the rear of this document and the more likely put in front. To summarize briefly, the problem is that periodically (several times a day) the VPN malfunctions and starts sending packets to the private IP address from the remote client instead of the public IP, causing packets to be dropped. The problem can be temorarily corrected by either waiting (problem corrects itself), by rebooting, or by deleting and recreating the site definition. It's a Host<->Gateway VPN, from client?s boss' home SecuRemote to their Internet firewall. Since his boss is behind a NAT-ing ADSL gateway/firewall, it uses udp encapsulation. What is actually going on is pretty clear, however. If he tcpdumps on the ADSL fw/router in front of the SecuRemote machine, it is quite revealing. While SR is working correctly, it is sending the udp encapsulated IPsec packets to the correct interface of the FW. When it starts misbehaving, it starts trying to send the same packets to the IP address of the internal interface of the firewall (which is, of course, a private IP address: RFC 1918). I have not yet seen any reason why it starts sending to the wrong IP suddenly. ++++++++++++++++++ My questions to the group is that: 1. I remember reading that this is suppose to be a static nat configuration. Isn?t this true? ? he is using a Global nat. 2. Any comments about the userc.C file? 3. Other possible areas I should look into? 4. Any other brilliant minds want to give me an idea? (I have been out of circulation (working in networks) for some time and am anxious to get back to work, but in this regard, I am not actually able to physically look at the configs. myself.) ++++++++++++++++++ I asked the other engineer some specific questions and he answered them as follows. Hi Chris, we have not met yet, so let me introduce myself. .... My job is basically dealing with anything related to IT security (except viruses). My boss, told me that you would research his SecuRemote problem. I received your questions, so here come my answers (although I am not sure I understand all of them, so feel free to ask again): >1. from end to end setup My client?s remark:It's a Host<->Gateway VPN, from my boss' home SecuRemote to our Internet firewall. Since my boss is behind a NAT-ing ADSL gateway/firewall, it uses udp encapsulation. >2. Encryptions - setup instructions if you know them My client?s remark:I'm not quite sure what you mean by this question... >3. Multiple entry points? Others having same problem? My client?s remark:No MEP. Someone else at our company might have the same problems, although I have not sniffed his connection yet. >4. VPN cards? My client?s remark:Nope. >5. Hardware configurations. Any other problems exist other than VPN? My client?s remark:Company firewall: noname PC: 1GHz Celeron, 128M memory, 2 double Intel and a single (unused) D-Link network cards SecuRemote host: no idea >6. OS platforms My client?s remark:Company firewall: Red Hat Linux 7.3 SecuRemote host: Windows XP >7. Fw platforms - versions, management consoles, inspection modules My client?s remark:NGFP3 with current hotfixes The SecuRemote is the most current FP3 version (but same problem with the FP4 version) >What type of problems: >1. Connectivity, communication slow, etc. Does it ever correct itself? My client?s remark:VPN connection sometimes dies (non-VPN ones still work). After a few minutes (5-10 or more) it is usually OK again. >2. What type of error messages My client?s remark:None at all (apart from the can't connect, unreachable, etc. stuff from the applications). >3. Frequency of problems My client?s remark:Varies, but many times a day. >4. What you have done to correct the problem in past My client?s remark:Rebooting always helps. So does deleting and recreating the site definition in SecuRemote. Or just waiting. All these solutions are temporary, however. >5. What you think is causing the problem My client?s remark:Stupid Check Point, perhaps? ;) What is actually going on is pretty clear, however. If I tcpdump on the ADSL fw/router in front of the SecuRemote machine, it is quite revealing. While SR is working correctly, it is sending the udp encapsulated IPsec packets to the correct interface of the FW. When it starts misbehaving, it starts trying to send the same packets to the IP address of the internal interface of the firewall (which is, of course, a private IP address: RFC 1918). I have not yet seen any reason why it starts sending to the wrong IP suddenly. >6. Who has helped you in the past and what have they said and done My client?s remark:I searched the Check Point KB for a while, and I did find relevant resolutions (mostly doing with resolve_interface_ranges and sometimes contradicting each other), but they did not seem to help. But I will try it again if you think that is the right solution. ++++++++++++++++++ FW-1 group remarks: > I don't believe the route table comes directly into play whatsoever. > The topology for your network (all the networks that exist behind your > firewall) gets communicated to the client and in stored in files (look > at the userc.c file) at the client. Any communications from the client > destined towards any host that exists on the networks described in > userc.c then gets encrypted. The destination of that encrypted packet > then is the gateway (firewall) that the client selected. In non-mep > situations there is only one gateway. In mep the client has to decide > which gateway to use. Once the gateway is decided the packet is sent > along its way. Only at this point is the routing table of the client > used, to determine how best to reach the gateway (normally the default > route, the gateway of your ISP will be used). My client?s remark: Yes, I completely agree with this remark. And, just to state the obvious, when the routing table of the client comes into play, the packet already has the wrong (ie. rfc1918) destination address. My remarks: > The SecureRemote documentation says that it is always good to do a > clean install by doing a complete uninstall of older versions. Has > this been done? My client?s remark:I know that my boss installed the newest SecuRemote, and I am going to ask him if he did a complete uninstall or just installed over the old one (which was FP3). My remarks: > Has this PC ever been moved from another network? Say, > from the local RFC 1918 network to home which may explain why it may > maintain valid archived information to the local network? My client?s remark:This sounds like a good idea, and I don't remember. The site Definition has been deleted and recreated many times since, however. Still, even more reason to try a complete uninstall. (I would consider it a bug, but maybe I am being too strict...) My remark: > I suspect the problem is in the userc.C file and that it may have something to do with the resolve_interface_ranges or other components, but let me look into it further before I make a suggestion. > Has the userc.C file been manually changed? My client?s remark:No, we never edited anything manually in this installation. My remark: > Since the workstation client needed to download the topology that contains all of the network behind the firewall from the SecureClient Server (Of course, this information will also be defined on the firewall), how was this enacted? Are there other SecureRemote users experiencing similar problems? This should be verified, as it will help better isolate the problem. How was another client's policy enacted ? in the same way? My client?s remark:As I said before, someone else might have the same problem, but I cannot check, because I cannot tcpdump on his side. Of course, by the nature of this problem, I will never see anything on our side. My remark: > Was there ever a personal firewall on the SecureRemote. Please verify that it was disabled or removed. I recently had a small issue where the customer put a personal firewall on Win XP and the configurations would not update without finding it and disabling it. My client?s remark:I have no control over the remote machine, but I am pretty confident there never has been any personal firewall. I will ask my boss about it. My remark: > Are you using Global or static routes? Are there static arp tables? My client?s remark:There are no static arp entries on the firewall (we have no static nat). My remark: > How does the client box (running SR) route to them? My client?s remark:The SR box has a default GW to the Linux ADSL/firewall gateway, which also dynamically NATs the traffic. From there it goes via the Internet to our leased line router, which does not change it, then to our firewall. > Finally, I have found a similar problem, which happens to be on the Checkpoint email club which I subscribe to. I will monitor the results and let you know, as the verdict is not in yet. It has been suggested that their problem may be a nat misconfiguration. Are you getting a "no valid SA" in the logs when the problem arises? My client?s remark:No, we get absolutely nothing in the firewall logs. SR just suddenly starts sending to the rfc1918 address instead of the public one, of which the firewall sees nothing of course. ++++++++ > +++++++ > FW-1 group remarks: > What have you got selected under the VPN-1 Net > NAT properties in the Global properties menu? You should have 'Hide all connections' My client?s remark:I am not sure that this applies to us, as we use traditional VPN setup. +++++++++++++++ My client?s remark:I don't really think it is either routing or arp, but I may be wrong. FW-1 group remarks:> How are your network routes defined behind the firewall? My client?s remark:Only the trivial interface routes: there is only one network on each interface. ++++++++++++++++ My remarks: Unless there is a true bug somewhere, the fact that this issue does correct itself may indicate that there are conflicting configurations that are likely using conflicting cache and update/refresh mechanisms. My remarks: > As a side note, there were security issues with LINUX 7.2 and SecureRemote ? and I do not know what exactly those problems were, but they seem to have been repaired by LINUX 7.3, which you have. Although kernel version 2.4.9-13 fixed some of those critical security issues, the latest kernel is 2.4.21, which repairs a variety of problems, including security, which you should consider as a LINUX upgrade. I have kernel 2.4.18. My client?s remark:Yeah, you just found my biggest beef with Check Point. Because of their braindead kernel module policy (compare to nvidia, who have a more intelligent one while still delivering binary-only drivers), you can only use one single (or very few) kernel packages that were blessed by CP (basically under which they compiled the modules). The latest of these is the 2.4.18-5 Red Hat kernel, featuring a few security holes. (Yes, this topic can always raise my blood pressure.) So upgrading the linux kernel is sadly out of the question. Christopher J. Dias - CCSA, CCSE (Checkpoint), MCP + I,MCSE, (Microsoft), CCNA, CCNP (Cisco). CSE (Novell) Cím:1121 Budapest Fülemile út 12-18 4.ép.3/11. Telefon: 36 1 275-4008 Mobil:06-20/803 9687 [email protected] --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software ================================================= To set vacation, Out-Of-Office, or away messages, send an email to [email protected] in the BODY of the email add: set fw-1-mailinglist nomail ================================================= To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================= If you have any questions on how to change your subscription options, email [email protected] =================================================
|
||||||||||
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
