ISP Redundancy Configuration

TCP A TCP B

1. CLOSED LISTEN
2. SYN-SENT --> --> SYN-RECEIVED
3. ESTABLISHED ESTABLISHED
4. ESTABLISHED --> --> 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!).

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:

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).

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: