Hi Again,
I just would like to update this thread so that if somebody
else runs into
the same problems this maybe could help.
As I said before, in the Ipso 4.2 Build 081 a01 Release
Notes, on page
167, I found the following PR:
<snip>
Multiple Interfaces Enhancement <PR 44876>
NGX R60 includes a feature to prevent routing asymmetries
that can occur
with SecureClient connections if your gateway has more than
one external
interface. You use this feature by accessing the Gateway
Properties/Remote
Access/Office Mode window and checking the box next to
“support
connectivity enhancement for gateways with multiple external
interfaces.”
If you enable this feature in an IP cluster running IPSO
4.2, you will not
be able to establish SecureClient connections with the
cluster.
</snip>
In fact, we had this feature enabled, and after I disabled
it, the
Secureclient connections are working fine. After reenabling
this feature,
the Secureclient connections began to fail again. So I am
quite sure that
this was the problem. I want you to know that after
disabling this
feature, the Secureclient connections did not start to work
immediately
and a cpstop, cptstart on the gateways may be necessary.
Kind regards,
Eric Janz
Eric Janz <e.janz BARCELOVIAJES.COM>
Enviado por: Mailing list for discussion of Firewall-1
<FW-1-MAILINGLISTAMADEUS.US.CHECKPOINT.COM>
21/04/2008 17:21
Por favor, responda a
Mailing list for discussion of Firewall-1
<FW-1-MAILINGLISTAMADEUS.US.CHECKPOINT.COM>
Para
FW-1-MAILINGLISTAMADEUS.US.CHECKPOINT.COM
cc
Asunto
Re: [FW-1] Secureclients are failing intermitently after
upgrading an
Nokia Cluster to NGX R65 ( local interface address spoofing
)
Hi Hakan,
thanks a lot for your response. I have done the ping test
from the
Internet Router to the cluster IP but I only see one request
and one
response but nothing gets dropped, everythings seems to be
ok and uses the
cluster ips and macs.
16:37:29.990063 <internet-router-mac> >
00:50:5a:39:fa:01, ethertype IPv4
(0x0800), length 98: IP <internet-router-ip> >
<cluster-external-ip: icmp
64: echo request seq 7
16:37:29.990261 00:50:5a:39:fa:01 >
<internet-router-mac>, ethertype IPv4
(0x0800), length 98: IP <cluster-external-ip> >
<internet-router-ip>: icmp
64: echo reply seq 7
The interface setup is as follows:
node-one[admin]# ifconfig eth-s1p1c1
eth-s1p1c1: lname eth-s1p1c1
flags=e7<UP,PHYS_AVAIL,LINK_AVAIL,BROADCAST,MULTICAST,AUT
OLINK> vlan-id 9
inet mtu 1500
inet <node-one-external-ip>/24 broadcast
<external-net.255>
inet <cluster-external-ip>/24 broadcast
<external-net.255>
clustermac 0:50:5a:39:fa:1
phys eth-s1p1
flags=4133<UP,LINK,BROADCAST,MULTICAST,PRESENT>
ether 0:a0:8e:bb:29:e0 speed 1000M full duplex
I think that the problem is caused by a Bug in Nokia IPSO
4.2 that maybe
is solved in the Build 81 01a that states that in previous
releases ( we
are using IPSO 4.2 Build 78 ) there is some kind of problem
when using nat
over the cluster interfaces and simmetric interface hash
algorithm:
<snip: Getting Started Guide and Release Notes for Nokia
IPSO 4.2 Part No.
N450000717 Rev 001 Build 081 a01 Published March 2008, page
22,23>
...
Fix for Issue with NAT and Cluster IP Address <PR
69063>
If you use IP clustering with a previous build of IPSO 4.2
and also use
NAT, a
problem can occur if both of the following are true:
You use a cluster IP address as the address to hide behind.
You set the cluster hash options to force connections to be
symmetric (one
node handles all the traffic for a connection).
In this situation, previous builds of IPSO 4.2 do not force
connections to
be
symmetric. This can prevent connections from being
established in
situations
in which one node does not receive all of the TCP handshake
packets, such
as
the following:
1. Node 1 receives a syn packet.
2. Node 2 receives the corresponding syn ack packet.
3. If the firewalls have not synchronized connection
information for this
connection when node 2 receives the syn ack, it drops
the packet
because
it did not receive the appropriate syn packet.
Connection
establishment is
not completed.
This problem occurs only if you use a cluster IP address to
hide behind.
It
does not occur with other addresses and is fixed in Build
081 a01.
...
</snip>
In fact, in our VPN connections, each cluster node hides
behind the
cluster IP and the interface hash algorithm is set to
default. At this
moment I also oppened a SR with Nokia and I am waiting if
changing the
interface hash algorithm will resolve the problem and if
this can be done
without disrupting traffic.
I found also another known limitation:
<snip: Getting Started Guide and Release Notes for Nokia
IPSO 4.2 Part No.
N450000717 Rev 001 Build 081 a01 Published March 2008, page
167>
...
Multiple Interfaces Enhancement <PR 44876>
NGX R60 includes a feature to prevent routing
asymmetries that
can occur
with SecureClient connections if your gateway has
more than one
external
interface. You use this feature by accessing the
Gateway
Properties/Remote
Access/Office Mode window and checking the box
next to “support
connectivity enhancement for gateways with
multiple external
interfaces.”
If you enable this feature in an IP cluster
running IPSO 4.2,
you will not be
able to establish SecureClient connections with
the cluster.
...
</snip>
By now I disabled the Multiple Interfaces Enhancement.
¿ any ideas about this ? ¿ somebody else has this problems
with a similar
setup ?
Thanks in advance for all your advice,
Best Regards,
Eric Janz
Hakan Ünsal <hakan.unsalITWAYVAD.COM>
Enviado por: Mailing list for discussion of Firewall-1
<FW-1-MAILINGLISTAMADEUS.US.CHECKPOINT.COM>
21/04/2008 11:35
Por favor, responda a
Mailing list for discussion of Firewall-1
<FW-1-MAILINGLISTAMADEUS.US.CHECKPOINT.COM>
Para
FW-1-MAILINGLISTAMADEUS.US.CHECKPOINT.COM
cc
Asunto
Re: [FW-1] Secureclients are failing intermitently after
upgrading an
Nokia Cluster to NGX R65 ( local interface address spoofing
)
Eric,
Maybe you should try to run tcpdump with the -e parameter to
see the MAC
address of the device which actually sends the suspicious
packet you
mention. What you see in the Origin column of the log
example you sent,
doesn't always mean that this packet is actually coming from
the active
member of the cluster. It could be a problem in the switches
(if, for
example, they are also clustered and some small config issue
has been
overlooked) which causes them to send the packets which
originated from
the
active member back to the cluster IP address. In your case,
I wouldn't be
surprised if you see outputs not exactly but similar to
below when you
ping
the cluster IP from the Internet router:
<time> <MAC-of-switch> <MAC-active-node>
ip 74: <router-ip> ->
<cluster-ip>: icmp: echo request
<time> <MAC-active-node> <MAC-of-switch>
ip 74: <act-node-ip> ->
<router-ip>: icmp: echo reply
<time> <MAC-of-switch> <MAC-active-node>
ip 74: <act-node-ip> ->
<router-ip>: icmp: echo reply
In this case, line 3 is the reason of logs you see (for some
erroneous
reason, switch is sending back the packet). FW-1 doesn't
like packets
where
the src ip belongs to one of its interfaces but the src MAC
does not
belong
to its Mac address (which is called local interface address
spoofing and
addresses the situation when a bad guy in the LAN plays the
role of FW-1)
> -----Original Message-----
> From: Mailing list for discussion of Firewall-1
[mailto:FW-1-
> MAILINGLISTAMADEUS.US.CHECKPOINT.COM] On Behalf Of
Eric Janz
> Sent: Monday, April 21, 2008 10:26 AM
> To: FW-1-MAILINGLISTAMADEUS.US.CHECKPOINT.COM
> Subject: Re: [FW-1] Secureclients are failing
intermitently after
> upgrading an Nokia Cluster to NGX R65 ( local interface
address
> spoofing )
>
> Good Morning !
>
> Well, as I thought on Friday, the problem still
persists. After the
> traffic was again balanced on both cluster nodes, the
Securemote
> connections fail again with "local address
spoofing" and we get entries
> in
> the log like the following one:
>
> Number: 28864
> Date: 21Apr2008
> Time: 8:04:28
> Product: VPN-1 Power/UTM
> Interface:
<external-interface>
> Origin:
<cluster-node-1-external-ip>
> Type: Alert
> Action: Drop
> Protocol: udp
> Service:
VPN1_IPSEC_encapsulation (2746)
> Source:
<cluster-external-ip>
> Destination:
<securemote-client-public-ip>
> Source Port:
VPN1_IPSEC_encapsulation
> Information: message_info: Local
interface address
> spoofing
> SmartDefense Profile: Default_Protection
> Policy Info: Policy Name:
<Policy>
> Created at: Fri
Apr 18 17:45:09
> 2008
> Installed from:
<Smartcenter>
>
>
> ¿ Any idea about this ? ¿ Did somebody see the same
strange behaviour ?
>
> Thanks again for any advice,
> Kind Regards,
> Eric Janz
>
>
> Mailing list for discussion of Firewall-1
> <FW-1-MAILINGLISTAMADEUS.US.CHECKPOINT.COM> wrote on 18/04/2008
> 19:03:33:
>
> > Hi again,
> >
> > just a comment about this, the NTP setup on the
Nokia Cluster is set
> in
> a
> > manner so that the sync cluster ip address's serve
as NTP Master. I
> found
> > a Known Limitation in the IPSO 4.2 Build 78
Release Notes which
> states
> > that in this version there is some kind of problem
due to that it is
> not
>
> > recommended to use the cluster members as NTP
Masters even not using
> the
>
> > cluster sync ip's. In fact, the cluster nodes
local time differes one
> > second ¿ could this be a reason for the
"local interface address
> spoofing"
> > ?
> >
> > <--- snip "Getting Started and Release
Notes for IPSO 4.2 ( Build 078
> ),
>
> > page 145 --->
> > Do Not Configure Nodes as NTP Server <PR
52178>
> > If you enable VRRP or clustering, do not
use any of the nodes
> as
>
> > an NTP
> > server. An issue with xntpd can cause the
node to enter into
> a
> > continuous loop
> > of leave and join mode, thus disrupting
traffic. You can
> still
> > configure nodes
> > to be NTP clients.
> > <--- snip --->
> >
> > By now I setup an external NTP server and now the
local time of the
> > cluster members is sync'd and the VPN Clients are
also working. Both
> > cluster members leaved the cluster and rejoined,
98% of the actual
> > connections are assigned to the master node and
all new connections
> are
> > going to the member node ( I am using static work
assigment ) ¿ Maybe
> the
> > VPN connections are only working at this moment
because every new
> > connection is going through the same node ?
> >
> > What do you think ?
> >
> > Well, thanks again in advance,
> > I will update this thread with the final results,
> >
> >
> > Kind Regards,
> > Eric Janz
> >
> >
> >
> >
> > Eric Janz <e.janzBARCELOVIAJES.COM>
> > Enviado por: Mailing list for discussion of
Firewall-1
> > <FW-1-MAILINGLISTAMADEUS.US.CHECKPOINT.COM>
> > 18/04/2008 14:07
> > Por favor, responda a
> > Mailing list for discussion of Firewall-1
> > <FW-1-MAILINGLISTAMADEUS.US.CHECKPOINT.COM>
> >
> >
> > Para
> > FW-1-MAILINGLISTAMADEUS.US.CHECKPOINT.COM
> > cc
> >
> > Asunto
> > [FW-1] Secureclients are failing intermitently
after upgrading an
> Nokia
> > Cluster to NGX R65 ( local interface address
spoofing )
> >
> >
> >
> >
> >
> >
> > Hi Everybody,
> >
> > We had a 2 nodes Nokia IP380 Cluster with IPSO 3.8
and Checkpoint NGX
> R60
> > and upgraded it last week to a 2 nodes Nokia IP690
Cluster with IPSO
> 4.2
>
> > Build 078 and have installed Checkpoint VPN-1
Power NGX R65 without
> HFA's.
> >
> > The nokia cluster is working in forwarding mode
and static work
> assignment
> >
> > with the failure interval set to 5000ms. The cpu
and memory
> utilization
> is
> >
> > normal. At the Checkpoint level we are using Nokia
IP Clustering Load
> > Sharing. We have remote clients which are
connecting with Secure
> Client
> > using different versions ( R55, R56, R60 ) in
office mode and they
> get
> IPs
> >
> > assigned from our central dhcp server. The office
mode antispoofing
> is
> on
> > and configured with the network range that can be
assigned by the
> dhcp
> > server and this network is not used locally and
always gets routed
> through
> >
> > the Firewall.
> >
> > Everything went fine, we first upgraded our
Smartcenter and then
> changed
>
> > the gateways, but a few days ago we noticed that
the VPN connections
> fail
> > "sometimes". At the user laptops we see
that the tunnel test is
> failing
> > but it says that the connection was established
successfully.
> >
> > I have read a lot of SK's and googled around
"local interface address
> > spoofing" and "tunnel test failure"
without a lot of success and
> after
> > testing a lot of options in the gateway
configuration (MEP on/off,
> Dynamic
> >
> > Gateway Address Resolution vs Gateway Address
Resolution from
> topology,
> > etc ) I found that the only way to get the client
vpn connections to
> work
> > is removing one node from the cluster leaving the
other one alone.
> >
> > At Smartview Tracker I found log entries that
state that there is
> "local
>
> > interface address spoofing" and it seems to
me that this is happening
> when
> >
> > the client establishes the VPN through one gateway
but the response
> is
> > trying to get out the other one ¿ is that a
possible problem ? ¿
> shouldnt
> > the connections be sincronized between the cluster
members ?
> >
> > Number: 13474
> > Date: 18Apr2008
> > Time: 13:01:46
> > Product: VPN-1 Power/UTM
> > Interface: eth-s1p1c1
> > Origin:
<cluster-node-2-external-ip>
> > Type: Alert
> > Action: Drop
> > Protocol: udp
> > Service: 10366
> > Source:
<cluster-external-ip>
> > Destination:
<remote-client-public-dsl-ip>
> > Source Port: IKE_NAT_TRAVERSAL
> > Information: message_info:
Local interface address
> > spoofing
> > SmartDefense Profile: Default_Protection
> > Policy Info: Policy Name:
policy1
> > Created
at: Fri Apr 18
> 12:50:08
> > 2008
> > Installed
from: smartcenter
> >
> >
> > When this is happening, I try to ping from the
remote client a local
> pc
> > and I can see with a tcpdump that the packets are
arriving to the
> local
> pc
> >
> > with the office mode remote source ip from the
remote client and that
> the
> > local pc is responding. This response arrives to
the firewall and
> gets
> > dropped due to the local interface address
spoofing ¿?
> >
> >
> > Thanks a lot in advance for any advice,
> > Kind Regards,
> > Eric Janz
> >
> >
> >
Scanned by Check Point Total Security Gateway.
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to LISTSERVamadeus.us.checkpoint.com
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
fw-1-ownerts.checkpoint.com
=================================================
--
ADVERTENCIA LEGAL
El contenido de este correo es confidencial y dirigido
unicamente a su
destinatario. Para acceder a su clausula de privacidad
consulte
http://www.barce
loviajes.com/privacy
LEGAL ADVISORY
This message is confidential and intended only for the
person or entity to
which it is addressed. In order to read its privacy policy
consult it at
http://www.barce
loviajes.com/privacy
--
ADVERTENCIA LEGAL
El contenido de este correo es confidencial y dirigido
unicamente a su destinatario. Para acceder a su clausula de
privacidad consulte http://www.barce
loviajes.com/privacy
LEGAL ADVISORY
This message is confidential and intended only for the
person or entity to which it is addressed. In order to read
its privacy policy consult it at http://www.barce
loviajes.com/privacy
|
