You have found one of F5's 'features'. Roughly, while the
OS handles ARP entries properly, their code maintains a
separate table for each connection and stores the MAC from
which packet came. When the F5 passes return packet, it
builds it with the physical MAC stored in it's table
rather than the one the OS has which would be virtual.

This should not be a problem as long as that cluster
member continues to handle the connection. If another
cluster member gets involved the connection will fail. We
use HA new mode so the only time we see an issue is when
it fails to other member. In load sharing I suspect the
likelihood of another member being assigned the connection
would be greater.

You should ask them if the following applies to your
situation and how it impacts the F5 balancing process.

http://tech.f5.com/home/bigip/solutions/poolsnodes/sol1358.html

L


On Wed, 18 May 2005 13:50:18 +0200 S�bastien Cantos <[EMAIL PROTECTED]> wrote:
Hi,

I've identified the problem. In fact the bigip is
answering with a
destination MAC which is the real MAC of the firewall
node from which the
paquet was coming and not the virtual one.
So I think that this is the problem. Sometimes the other
node woul like to
forward the paquet and the first node just drops it, but
as the bigip is not
sending the frame to the multicast mac, this one never
reaches the second
node :(

First problem is that Cluster XL multicast doesn't send
frames with source
mac = virtual mac but with the real one (this might be
corrected in recent
versions ...).
Second problem is that Bigip doesn't send frames to the
virtual, but to the
real mac.

I'm gonna check with F5 bigip support team to see if we
can change this
behaviour. I've noticed that when sending frames
directly from the bigip the
are sent to the virtual MAC ... But when these frames
are answers to other
ones they go to the real mac ...

In any cas, thanks for replying.


Best regards, -- Sebastien Cantos <[EMAIL PROTECTED]> Network / System Manager Neopost DIVA

-----Message d'origine-----
De : Mailing list for discussion of Firewall-1
[mailto:[EMAIL PROTECTED] De
la
part de Andrew Smaff Matthews
Envoy� : mercredi 18 mai 2005 11:53
� : [email protected]
Objet : Re: [FW-1] FW1 and BIGIP problem

On Tue, May 17, 2005 at 05:29:31PM +0200, S�bastien
Cantos wrote:
> Hi,
>
> I'm running NG FP3 and Cluster XL (multicast mode) on
Linux
platform. I've
> something setup like this :
>
> WAN    NET1                      NET2
> --- FW --- BIGIP (load balancer) --- FTPD
>
> I've a problem with active FTP. When a client connects
and do a PORT
> command, it is silently droped by the firewalls (one
time every 2
> connexions). I see the FTPD sending the Syn, nating
this
Syn. Then the Syn
> comes to the lan interface of the firewall but never
reaches the Wan
> interface of the firewall.
>
> Clients are connecting to an ip in routed to the
firewall
then nated.
> For example :
> 1/ client connects to 10.10.10.1 (Static nat on the
firewall)
> 2/ Firewall do Destination NAT and send packets to a
VIP on
the BIGIP
> (192.168.20.10)
> 3/ Bigip do Destination NAT and join the FTPD
(192.168.21.10)
>
> I don't understand why the firewall is droping the
ftp-data syn.
> Is there a way to look at this on the firewalls ? I
did
notice nothins on
> smartview tracker ....
>
This is, I suspect, because FTP is an evil protocol :>

The port command tells the ftpd to make a connection to
<client_IP> on a
given high-port. Firewall-1 picks this up and
dynamically
adds a rule that
says:

        from SvrIP:20 to client_IP:<high_port> tcp
allow.

Now, you're NATing the SvrIP twice. Is the source IP of
the
packet which
gets dropped by the firewall 192.168.21.10,
192.168.20.10 or
10.10.10.1?

If its the first, you need to get the bigIP to NAT the
outgoing connection -
note you can actually use HIDE nat here if you need to.
If its the 2nd (or you've tried the first and it still
doesn't work), then
you need to make sure their is a static map:
        org. src: 192.168.20.10 -> trans. src:
10.10.10.1
        org. dst: =             -> trans. dst: =

Beyond that, I can't say as you've not provided any
firewall logs.

                Smaff


-- You happen to be here, now.

=================================================
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] =================================================

================================================= 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] =================================================

Reply via email to