Re: ISP Redundancy Configuration

I apologize...you right. My problem is that the seq number doesn't
increase. So I can establish the connection and when I try from the
other place I can access the same destination.
I use the telnet on port 25 to test the communication.
Thanks
Daniel

Default User escreveu:

What I posted is directly from RFC793 describing how the TCP connection is
supposed to work. Ack sequence numbers do not and should not increment
after establishing the three-way handshake, only the packet sequence number
should increment.

Have you checked your logs for obvious problems? If the connection becomes
established and then fails on the first data packet, that suggests that
there is probably no connection being made to the SMTP server on the
backend (assuming you're using a split proxy for the SMTP traffic).


On 10 Jan 2007 05:26:39 -0800, "Daniel" <daalmeida@xxxxxxxxx> wrote:

What you describe is exactly that happen!
Do you have any idea how can I fix this problem? I'm working with
Check Point R60 on SecurePlatform I tried applied the HFA04 but
didn't work.
So if you have any suggestion I'll be very thankful.
Regards,
Daniel

Default User escreveu:

On 5 Jan 2007 04:05:13 -0800, "Daniel" <daalmeida@xxxxxxxxx> wrote:

Hi guys!!!!

I'm really need your help!!!!
I configured the ISP Redundancy and now I have problems with smtp
traffic. I get some logs and saw that the communication between the
mails server have problem to increase the ack packet, get it?
For example, when the communication start we have the treewayhandshake
after that the end points will be send an ack packet with data, so this
packets had a number to identify each other. The problem is that these
numbers of ack packets doesn't increase and the communication
doesn't happen.
Please someone can help me???
Thanks a lot!!!
Daniel

TCP A TCP B

1. CLOSED LISTEN

2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED

3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED

4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED

5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED

Basic 3-Way Handshake for Connection Synchronization

Figure 7.

In line 2 of figure 7, TCP A begins by sending a SYN segment
indicating that it will use sequence numbers starting with sequence
number 100. In line 3, TCP B sends a SYN and acknowledges the SYN it
received from TCP A. Note that the acknowledgment field indicates TCP
B is now expecting to hear sequence 101, acknowledging the SYN which
occupied sequence 100.

At line 4, TCP A responds with an empty segment containing an ACK for
TCP B's SYN; and in line 5, TCP A sends some data. Note that the
sequence number of the segment in line 5 is the same as in line 4
because the ACK does not occupy sequence number space (if it did, we
would wind up ACKing ACK's!).
http://www.rfc-editor.org/rfc/rfc793.txt

hth

.

Relevant Pages

  • Re: [PATCH] OpenBSD Networking-related randomization port
    ... did you read the existing Linux TCP ISN generation code? ... TCP is designed to work in an environment where packets are delayed. ... will have no effect on the current connection. ... how to choose the first sequence number ...
    (Linux-Kernel)
  • Re: ISP Redundancy Configuration
    ... What I posted is directly from RFC793 describing how the TCP connection is ... Ack sequence numbers do not and should not increment ...
    (comp.security.firewalls)
  • Re: ISP Redundancy Configuration
    ... after that the end points will be send an ack packet with data, ... In line 2 of figure 7, TCP A begins by sending a SYN segment ... indicating that it will use sequence numbers starting with sequence ...
    (comp.security.firewalls)
  • Re: ISP Redundancy Configuration
    ... after that the end points will be send an ack packet with data, ... In line 2 of figure 7, TCP A begins by sending a SYN segment ... indicating that it will use sequence numbers starting with sequence ...
    (comp.security.firewalls)
  • Re: question about abuse of state tables.
    ... >> The question is about TCP connection with are already in the state table. ... In general, once a TCP ... > checked for correct TCP sequence numbers. ... > reasonably good quality - the attack has been known for a few years. ...
    (comp.security.firewalls)