| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| Oh great ones... excuse me for my stupidity! I have office-mode working great. NGX-R60a. The secureclient (also NGX-R60a pulls an IP from the firewall of 10.5.1.1 /24. This network is NOT in my encryption domain, of course. I have my internal routers pointed to the interenal interface of my firewall... everything works great... EXCEPT... I have a Cisco Router on the other side of my network. The secure client can ping it just fine- every interface. The problem is that it cannot get across the NAT that leads to a vendor network. The vendor network address the client is trying to hit is (say for instance) 177.73.150.50. The tokenring connection between my network and theirs is 177.73.47.1 and 177.73.47.2 (their side) with my outside IP set to nat all to 177.73.146.1 (their request and it works fine for non secureclient folks). Here is the deal. My secure client can ping all the way to my token ring interface that connects me to them (10.104.1.1) but when I try to ping the host 177.73.150.50, or the other side of the token ring it fails. ICMP is blocked on their side, so no doubt it will always fail, but I should see the translation in my router when I do a "sho IP NAT TRANS DET". I have enabled verbose debugging and never see the 10.5.1.1 address being translated. What's up with that? Does it have something to do with my firewall being setup for IP NAT traveral or something? Why won't the Cisco Router see the packet and translate it? I have gone over my routing a thousand times, I have made sure the 177.73.x.x addresses are inside my encryption domain and am sure it has nothing to do with routing. The packet makes it there, and will not jump the NAT. Please help. Mr. Nobody Dodads Inc. |
| |||
| There has to be a guru out there to give some insite on this... if I ping from inside the network using an extended ping from a Cisco router, spoofing the source address, it works.... the very same address the Office Mode client has... so it is not an issue with the IP, it has something to do with the packet.... HELPPPPPPPPPPPPPP! |
| |||
| Take a PC with a sniffer and sniff each segment of you chain. http://www.networkchemistry.com/products/packetyzer/ is a good one. Make sure you ICMP packets reach cisco router. You can use (icmp) filter for sniffer for limiting the scope. |
| |||
| Set up an access-list on the router to capture the interesting traffic and run a 'deb ip pack <access-list number>' to see if the traffic makes it to the router. It sounds like the traffic may not even get there. Maybe a routing issue. I'm assuming your firewall has a route to the specified router for the addresses behind it? |
| |||
| from the kb: This is because IKE negotiations involve sending UDP packets which under certain conditions generate multiple IP fragments. NAT devices used by ISPs are unable to properly translate IP fragments, which leads to the loss of these packets. This problem can be overcome by configuring VPN-1/FireWall-1 to conduct Phase 1 IKE negotiations over TCP instead of UDP. solution: KE over TCP can be configured as follows: 1) In SecuRemote/SecureClient, select Tools > Encryption Scheme. 2) In the Default Key Scheme window, click Advanced 3) In the Advanced IKE Settings section, check the Support IKE over TCP checkbox 4) Define a rule in the Rule Base that allows the IKE_TCP service (TCP port 500) to the VPN/FireWall Module 5) Edit the objects.C in 4.1 per How to make changes to the objects.C file Add the property ":desktop_site_default_tcp_ike (true)" to the :props section in the objects.C file on Management Server (which enables IKE over TCP on all gateways managed by the Management Server) OR Enable the property ":supports_tcp_ike" for a specific gateway object. This requires locating the correct section for hte gateway and then locating parameter to change. |
| |||
| The packets are making it there... the station can ping the inside NAT interfaces and the interface that is actually doing the NATing... however cannot get to the other side. By that I mean a NAT table entry is never created. I assume the UPD fragment issue would be a factor only if I could not reach the intended target, right? HELP! |
| |||
| Quote:
Do the end node have ONE default gateway? |
| |||
| I put a sniffer on the end node, and it is NOT being NAT'd- you are exactly right. The router seems to be ignoring the packet and I cannot understand why. The packet when it hits the router to be NAT'd looks EXACTLY like a packet sent from inside the network in EVERY WAY. Packet length, header, size, ports, flags, raw data, EVERYTHING. In 15 years I have not seen a problem so seemly impossible as this one. A sniffer doesn't lie, if the packets are the same, why is one being ignored? In addition, when I do a debug IP NAT DETAIL, it does not even show that the request was made, dropped, mismapped or anything. Any ideas on how to go at this? Cisco no longer supports the 4700 routers, so I am on my own even thought it is a 12.0 version of IOS. Thanks |
| |||
| Both are checked to answer the client config question... I did it all combinations with the same result. I need NAT because it is a vendor requirement. They refuse to open their mainframe up to my network, therefore I have to NAT so they can create their access list based on the NAT'd address... same thing as opening it up to my whole network anyway... I agree.... Any change a static NAT would help? I will try it... |
![]() |
| Thread Tools | |
| Display Modes | |
| |