Tim,
I personally havn't had much chance to play with 4.1, so I'm not exactly
sure what has changed since 4.0. You are correct that ISAKMP/OAKLEY now
equals IKE. But as far as why you have to explicitly allow that traffic
even though it's not considered a "control connection", I am also
baffled. I'll be at the Check Point OPSEC Conference in Chicago
tomorrow and will ask about it.
Jason
[EMAIL PROTECTED] wrote:
>
> Forgot to mention that we do have "Accept Firewall-1 Control Connections"
> unchecked but still don't quite get the 'IKE' bit...
>
> Tim Higgins
>
>
> [EMAIL PROTECTED]
> Sent by: To: Jason Witty
><[EMAIL PROTECTED]>
> [EMAIL PROTECTED] cc:
>[EMAIL PROTECTED], [EMAIL PROTECTED]
> kpoint.com Subject: Re:
>[FW1] Secure Remote - required rules.
>
>
> 21/06/00 13:24
>
>
>
> Hi
>
> Is this changed in 4.1(2000) ? - we just use the "Firewall" group which
> includes ISAKMP - I believe that this is the IKE 'protocol' ?
>
> Tim Higgins
>
> Jason Witty <[EMAIL PROTECTED]>
> Sent by: To: Jim
> Shaw <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> "'[EMAIL PROTECTED]'"
> kpoint.com
> <[EMAIL PROTECTED]>
> cc:
> Subject:
> Re: [FW1] Secure Remote - required rules.
> 21/06/00 11:45
>
> According to a few of my friends at Check Point, you must use a "Any FW IKE
> ACCEPT) rule, if you uncheck the "Accept Firewall-1 Control Connections"
> box in the policy properties. Had that box been checked, you wouldn't need
> an explicit rule to allow IKE\SecuRemote - but then you'd be allowing a lot
> more... Hope this helps!
>
> Jason
>
> At 03:35 PM 6/21/00 +1200, Jim Shaw wrote:
> >
> >I have resolved a problem I had with SR but now find that unless the
> >client can do a key exchange using IKE to the firewall it does not
> >connect. The client sits saying "Exchanging Keys" and then errors out.
> >
> >I am using SR build 4157 - the most recent I think, talking to
> >Checkpoint 2000. I am using IKE with VPN-1 username/password
> >authentication.
> >
> >I downloaded the topology while on an internal network with a rule
> >permitting some clients to connect directly to the firewall. No problem
> >there. Dialing in from outside with the LAN card disabled I get a
> >connection failed error with log entries in the FW log indicating that
> >it is refusing IKE port connections because of my "Any, FW, Any Any
> >Drop" rule.
> >
> >I have a rule preceding that that permits "SRUsers@Any, MyNet, Any,
> >Client Encrypt" which is what I understand was all that is necessary to
> >get SR clients working.
> >
> >It works if I add a rule that says "Any, Firewall, IKE, Accept". I don't
> >like that but appear to have no option.
> >
> >Anyone got any ideas?
> >Jim
> >
> >Ryan Finnesey wrote:
> >>
> >> Is this the same thing has Mail Prory in Firewall 4.1. Because I am
> running
> >> 4.0 soon to be 4.1 on a Sun box. I need something to take the mail from
> the
> >> Internet and pass it to the Exchange Server that is on the LAN. What is
> the
> >> best thing to use ?
> >>
> >> Ryan V. Finnesey
> >> Network Administrator
> >> @tmosphere Interactive
> >> 1375 Broadway, 11th floor
> >> New York, NY 10018
> >> 212 827 2507 phone
> >> 212 827 2525 fax
> >> [EMAIL PROTECTED]
> >>
> >> -----Original Message-----
> >> From: Olaf Selke [mailto:[EMAIL PROTECTED]]
> >> Sent: Tuesday, June 20, 2000 2:23 PM
> >> To: [EMAIL PROTECTED]
> >> Subject: [FW1] 4.1 smtp security server not fully rfc821 compliant,
> >> <#@[]> 'invalid address syntax'
> >>
> >> platform: 4.1 SP1+Hotfix 41603 [VPN + DES + STRONG], Solaris 7
> >>
> >> hi list,
> >> it looks like the fw-1 smtp security server isn't fully RFC821
> >> compliant. Mails with a sender address <#@[]> are accepted by the smtp
> >> security server with a reply code '250 Ok'. This means according RFC821
> >> everything is fine: "250 Requested mail action okay, completed".
> >> Nevertheless they are not delivered to the final destination
> >> by the fw-1 mail dequeuer.
> >>
> >> The trouble is caused by the fw-1 mail dequeuer which logs
> >> "failed: 553 Invalid address syntax" and drops the mail silently! This
> >> means bounces (<#@[]> usually are bounces) do vanish on the firewall
> >> system without notice. My customer doesn't really like the idea that
> >> mails are vanishing on his firewall system. <#@[]> is supposed to be
> >> a valid address.
> >>
> >> Attached you'll find some verbatim stuff documenting in more detail
> >> what I'm talking about.
> >>
> >> Olaf
> >> --
> >> Olaf Selke, [EMAIL PROTECTED], voice +49 5241 80-7069
> >>
> >> ======= the sender <#@[]> is accepted and confirmed with code 250 ======
> >>
> >> root@mx [/] >>telnet internal 25
> >> Trying ...
> >> Connected to internal.mediaways.net.
> >> Escape character is '^]'.
> >> 220 CheckPoint FireWall-1 secure SMTP server
> >> mail from: <#@[]>
> >> 250 <#@[]>... Sender ok
> >> rcpt to: <[EMAIL PROTECTED]>
> >> 250 <[EMAIL PROTECTED] Recipient ok
> >> data
> >> 354 Enter mail, end with "." on a line by itself
> >> test with <#@[]>
> >
> >--
> >Jim Shaw Email: [EMAIL PROTECTED]
> >Optimation NZ Ltd, DDI: +64-4-470-5831
> >P.O. Box 10616, Ph: +64-4-472-7218
> >Level 2, Optimation House, Fax: +64-4-472-7219
> >1 Grey Street, Web: http://www.optimation.co.nz
> >Wellington,
> >New Zealand
> >
> >
> >
> ===========================================================================
> =====
> > 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 message is intended solely for the use of the individual
> or organisation to whom it is addressed. It may contain
> privileged or confidential information. If you have received
> this message in error, please notify the originator immediately.
> If you are not the intended recipient, you should not use,
> copy, alter, or disclose the contents of this message. All
> information or opinions expressed in this message and/or
> any attachments are those of the author and are not
> necessarily those of Hughes Network Systems Limited,
> including its European subsidiaries and affiliates. Hughes
> Network Systems Limited, including its European
> subsidiaries and affiliates accepts no responsibility for loss
> or damage arising from its use, including damage from virus.
> #**********************************************************************
>
> ================================================================================
>
> To unsubscribe from this mailing list, please see the instructions at
> http://www.checkpoint.com/services/mailing.html
> ================================================================================
>
> #**********************************************************************
> This message is intended solely for the use of the individual
> or organisation to whom it is addressed. It may contain
> privileged or confidential information. If you have received
> this message in error, please notify the originator immediately.
> If you are not the intended recipient, you should not use,
> copy, alter, or disclose the contents of this message. All
> information or opinions expressed in this message and/or
> any attachments are those of the author and are not
> necessarily those of Hughes Network Systems Limited,
> including its European subsidiaries and affiliates. Hughes
> Network Systems Limited, including its European
> subsidiaries and affiliates accepts no responsibility for loss
> or damage arising from its use, including damage from virus.
> #**********************************************************************
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
