|
|
|
|
|
|
|
|
 |
 |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [FW-1] SecuRemote through NAT device???
I can authenticate without error. After reading and thing about Don's message about SecuRemote decoding the encapsulated packets and discovering the 192.168.x.x origin, I tried something new. Just for yucks, I started running tracert's on my internal (at work) network for random 192.168.x.x addresses and found something interesting. I found that in fact, there is indeed a 192.168.x.x network here that was set up years ago and forgotten about. I am quite embarrassed to add that it was set up by none other than yours truly. What a dolt I am. So, I am, for the first time in a very long time, optimistic that this "rogue" network was in fact causing my SR traffic to "disappear" and with a few routing changes I'll actually be able to get this work! Dang, I still can't believe how many months I spent on this for it to (most likely) be something so dumb. If that is what was causing the problem and if it does indeed work now, I definitely owe everyone a huge apology for wasting their time. I'll let you know. Still though, I wouldn't have even thought to look for a rogue network if it weren't for several people on this list reminding me that this could be a problem and Don's last message. So, if it does in fact work now, I owe it to you all. I'll let you all know, Words can't convey how appreciative I am for all of the help I've received here. Thanks guys, Christian -----Original Message----- From: Don [mailto:[email protected]] Sent: Thursday, January 10, 2002 7:58 PM To: [email protected] Subject: Re: [FW-1] SecuRemote through NAT device??? > Question is, does my firewall box know to send the 192.168.x.x > traffic back to the SR client it originated from. Your firewall should be sending the traffic to the default router which would be the correct behavior. > Actually, it wouldn't even > be coming from a 192.168.x.x address would it? Wouldn't my client side > Linksys device repackage the packet as if it was coming from the public side > of Linksys device assigned through DHCP by the ISP? After all, that's what > NAT is all about. But SecuRemote interferes with this procedure. Yes the UDP encapsulated packets are rewritten, but when CheckPoint decodes the encapsulated packets, it discovers the original address (the 192.168.x.x address) of the originating system. > Since it works fine without the device. My assumption would be that > something is going wrong with the repackaging of packets either as they go > out, or as they return. Who knows at this point, seems like it could be > anything. Without a traffic dump it is very hard to determine what is going wrong. You may wish to install a sniffer such as Ethereal to help you figure out where the traffic is coming from and going to. Can you authenticate to the firewall? Or is even this failing? -Don ================================================= 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] ================================================= ================================================= 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] =================================================
|
||||||||||
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
