PDA

View Full Version : Securemote - Gateway not responding



suzy_reid
2006-04-21, 08:06
We added another interface yesterday to our firewall - did the "get topology" - rebooted and all worked fine . However now no one can connect with Securemote anymore - they all get "gateway not responding".

In the logs - IKE mode completes ok (under rule 0) but nothing else is logged and the user gets an error message "gateway not responding". We have nothing hitting the firewall on rule 1 (the securemote rule) or any VPN type traffic at all being logged.

The firewall was bringing up the new interface (10.3.1.1) as itself when we did a "get" of the firewall object itself - but we amended the hosts file with the proper external interface and rebooted and now the public IP is coming up ok here.

any ideas appreciated!!

iafilius
2006-04-24, 08:39
Probably everyone connects after the topo update to the private ip ?

Greetings,

suzy_reid
2006-04-24, 10:04
No - no one connects -in the logs just an IKE connection from the client and then nothing else in the logs - the users keep getting a "gateway not respondning" message.

On closer inspection by running netstat -an the firewall is not listening on port 500... how do I get the fw to begin listening?!?!

thanks

iafilius
2006-04-25, 02:52
Hi, looks like a crashed vpnd ?
Just try a restart.

LeNNoX
2006-05-09, 18:19
Suzy_Reid,

I'm having the same problem - did you manage to fix it + how?

have tried restart - no joy
did tcpdump on the FW interface, can't see any connection attempts other than topo request!
Internet Access for remote users is via dsl broadband, gonna it through a dial-up connection.

LeNNoX

LeNNoX
2006-05-11, 04:18
Problem sorted.

Our internal network is 162.10.x.x (yes, I know we shouldn't be using that address, has been like that before I started here).
I built the firewall on a 162.10.x.x address and it confiured it's self as an external interface, setup another interface with real world address.
When users got the topology, they got the 162.10.x.x address & were unable to route back to our firewall (as 162.10.x.x is a reall world address).

Changed the interface to be internal & update topolog - works fine.

LeNNoX

suzy_reid
2006-05-15, 04:55
for info

Our issue is still outstanding - even after we rebuilt the box with SPLAT (previously we were on Windows 2000) and installed NGX and then reimported the upgrade_export which was taken before we had the issues!!

This is now with Checkpoint ..... will update when I know more.. sigh

Jason
2006-06-08, 23:03
Hi, I am having the same problem, too!! I manually defined the interface to be internal, and only one external interface, but still get the same problem!! There is someone said that using SecuRemote R55 will be good, anyone tried!

cqliuke
2006-06-17, 05:25
Too Bad,I I am having the same problem,Are there some people solve this problem.

http://www.cpug.org/forums/showthread.php?t=1761

http://www.netexpert.cn/viewthread.p...extra=page%3D1

RayPesek
2006-06-17, 08:26
The firewall object really needs to be configured with the external IP address, not the internal address.

Configuring it with the internal address was common before central licensing because a change of ISP's meant you had to re-license the firewall. Central licensing eliminated that problem.

Having the firewall object defined with the internal address is guaranteed to cause VPN issues.

A "gateway not responding" issue can be caused by a number of things. One of the biggest is a crummy home router (usually spelled "D-Link") between SecuRemote/SecureClient and the firewall. If you have SecureClient, enable Visitor Mode. That virtually eliminated this problem for us.

Visitor Mode tunnels all of the remote access protocols over TCP 443 (HTTPS). It causes more workload on the laptop and on the firewall end because of the double encryption/decryption, but unless really low-end equipment is being used, it's not noticeable and it does get you connected. It's pretty nice to hear from an executive that he was sitting in a hotel lobby connected with ease by Visitor Mode wireless while a friend was sitting next to him using Cisco and was unable to get connected. :-)

If you're running Nokia, you MUST first change the Voyager SSL interface to use another port. If you enable Visitor Mode while leaving Voyaged on TCP 443, you will make the Voyager interface available from the Internet.

If you're using Implied Rules, make sure you check the box to log implioed rules or you can be missing some clues.

Also check the topology update interval. If I recall, it's set to some ridiculously high number. I set ours to one hour. That guarantees that topology changes will get downloaded on each connect. It's a tiny file and does not impact performance at all.

And check "IKE over TCP" and "UDP Encapsulation". We have had them both checked for everyone for years as well.

Ray

cqliuke
2006-06-25, 10:33
I have solved this problem by captured data packets.