ISP Redundancy Configuration

ISP Redundancy Configuration

am 05.01.2007 13:05:13 von daniel

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

Re: ISP Redundancy Configuration

am 05.01.2007 15:39:00 von Default User

On 5 Jan 2007 04:05:13 -0800, "Daniel" 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 --> --> SYN-RECEIVED

3. ESTABLISHED <-- <-- SYN-RECEIVED

4. ESTABLISHED --> --> ESTABLISHED

5. 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!).
http://www.rfc-editor.org/rfc/rfc793.txt

hth

Re: ISP Redundancy Configuration

am 10.01.2007 14:26:39 von daniel

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" 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 --> --> SYN-RECEIVED
>
> 3. ESTABLISHED <-- <-- SYN-RECEIVED
>
> 4. ESTABLISHED --> --> ESTABLISHED
>
> 5. 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!).
> http://www.rfc-editor.org/rfc/rfc793.txt
>
> hth

Re: ISP Redundancy Configuration

am 11.01.2007 20:05:51 von Default User

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" 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" 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 --> --> SYN-RECEIVED
>>
>> 3. ESTABLISHED <-- <-- SYN-RECEIVED
>>
>> 4. ESTABLISHED --> --> ESTABLISHED
>>
>> 5. 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!).
>> http://www.rfc-editor.org/rfc/rfc793.txt
>>
>> hth

Re: ISP Redundancy Configuration

am 12.01.2007 16:28:08 von daniel

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" 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" 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 --> --> SYN-RECEIVED
> >>
> >> 3. ESTABLISHED <-- <-- SYN-RECEIVED
> >>
> >> 4. ESTABLISHED --> --> ESTABLISHED
> >>
> >> 5. 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!).
> >> http://www.rfc-editor.org/rfc/rfc793.txt
> >>
> >> hth