|
|
|
|
|
|
|
|
 |
 |
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] FW: RE: [FW1] SecureRemote via Internet connection sharing throug h h a DSL
I have been struggling with this issue for weeks. I poured over the Phoneboy.com site, Linksys FAQ's and this mailing list for a solution. Basically I would see a key exchange at the firewall and the first packet from the system behind the Linksys router and no return packets. Yesterday while looking at the firewall I noticed that the DMZ interface was on 192.168.1.1. I changed this to a different subnet and rebooted this morning. Low and behold it started working. What happens when Joe user and Jim user both make a SR connection from home on different cable systems but both with the same address (192.168.1.100 say) from the LAN side of their respective Linksys router? I tend to think they each come from different public address so they should be ok. Is my logic here correct? Thanks, Dan -----Original Message----- From: Frank Darden [mailto:[email protected]] Sent: Tuesday, July 31, 2001 11:51 AM To: 'Zielke, Alex'; 'Jesus Calvo Hernandez' Cc: 'Checkpoint Mailing List (E-mail)' Subject: RE: RE: [FW1] SecureRemote via Internet connection sharing throug h a DSL This is totally not true. IKE/IPSEC works great from behind hide NAT with Checkpoint Firewall-1. You might need to use IKE over TCP, and then UDP encapsulation for the SR session. This can all be handled by the latest version of Securemote Frank -----Original Message----- From: Zielke, Alex [mailto:[email protected]] Sent: Monday, July 30, 2001 2:12 PM To: 'Jesus Calvo Hernandez' Cc: Checkpoint Mailing List (E-mail) Subject: RE: RE: [FW1] SecureRemote via Internet connection sharing throug h a DSL If you are using IPSEC through NAT, you may run into problems. IPSEC will only work with static NAT and not hide NAT. Usually broadband solutions like the ones your users have, will not provide enough addresses to do static NAT thus causing a problem. The solution, if you are using IPSEC, you can not have any devices in between the tunnel endpoints doing any kind of hide NAT. Each box needs to sit directly on the Internet or statically Nat'd to an internal address. -----Original Message----- From: Jesus Calvo Hernandez [mailto:[email protected]] Sent: Sunday, July 29, 2001 6:56 AM To: Chris Moore Cc: FW1-list (E-mail); 'Mike Sponsler' Subject: Re: RE: [FW1] SecureRemote via Internet connection sharing through a DSL << File: Card for <[email protected]> >> Hi all I´ve faced the same problem: nat and securemote together do not work. It seems that the encryption performed by securemote somehow hides all trace of internal private ip addressing on the home site so the nat router is not able to nat the internal private address to the public ip routable on the internet. That way the packet arrives to the firewall with a private ip address and no return is possible to home devices, as that ip is not routable. The encrypted packets do arrive to the firewall gateway, I´ve seen it on the log, but with private addressing (not natted to the public ip of the adsl router), so when returning packets they are dropped by the boundary router of the firewall. What´s funny is that other different encryption clients (Altavista tunnel if you know it) do work under the same conditions. So Altavista seems to do the thing right, encrypting only data and not the tcp header in order to let the router nat the packet correctly to traverse the internet to get to the company and then back to the home device. The sad thing is that Altavista is out of production, as Compaq bought Digital and obsoleted it. So if Altavista is able to work what makes it different from securemote that makes this last unusable on adsl routers performing nat? And best, how can we make securemote behave like altavista in terms of nat, if possible? These two questions remain to be answered in order for me to tell my bosses (who all have nat routers with adsl at home) what to do to be able to work at home like they were at the office. Any hint from any charitable soul would be much appreciated. Best regards ----- Original Message ----- From: Chris Moore <[email protected]> Date: Friday, July 27, 2001 2:25 pm Subject: RE: [FW1] SecureRemote via Internet connection sharing through a DSL > > Mike, > > SecuRemote can work over broadband (DSL or cable) with some > restrictions.In my experience, the most common failure is the user > is using the same IP > addressing scheme as our internal network. Sometimes this is not > modifiable, so it will not work, period. In other cases, the user > has to be > a member of a particular workgroup/domain to gain Internet access > thru his > provider. This has worked as well, but the user must enter his > domain\account info whenever he wants to access our network resources. > Then, there is the case where the DSL service utilizes the PPPoE > protocol.I've been successful using the RASPPPOE dialer available > on the Internet to > assist here. > > Finally, if there is any NAT at the user's end, SecuRemote will > not work (in > my experience). This happens with users behind routers performing > NAT, and > with Internet Connection Sharing. Although I haven't tried it > yet, but I've > heard using UDP encapsulation will resolve this. > > ------------------- > Chris Moore > [email protected] > > > -----Original Message----- > From: Mike Sponsler [mailto:[email protected]] > Sent: Wednesday, July 25, 2001 11:05 AM > To: [email protected] > Subject: [FW1] SecureRemote via Internet connection sharing > through a > DSL > > > > Greetings, > > I've got a few users on my network that are running internet > connection > sharing through thier DSL/Cable Modems at thier homes. Has anyone > ever > had anything like this work? It makes me nervous that checkpoint > doesn't out right support DSL or Cable modems, and reading through > phone > boy's website, it seems that you basicly have to hack the secure > remote > install to get SecureRemote to work at all via a DSL or Cable modem. > > I'm running FW 4.1 sp3 on a NT boxen. I'm not sure what kind of > DSL/Cable modems my co-workers have. Any advice in general for > this > would be well appreciated. > > -- > Mike Sponsler > [email protected] > > > > > ======================================================================== ==== > ==== > To unsubscribe from this mailing list, please see the > instructions at > http://www.checkpoint.com/services/mailing.html > ======================================================================== ==== > ==== > > > ======================================================================== ======== > To unsubscribe from this mailing list, please see the > instructions at > http://www.checkpoint.com/services/mailing.html > ======================================================================== ======== > > ------------------------------------------------------------------ This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of SchlumbergerSema. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. ------------------------------------------------------------------ ============================================================================ ==== To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ============================================================================ ==== ============================================================================ ==== To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ============================================================================ ==== ================================================================================ To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================================================
|
||||||||||
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
