Prev: I need help to hook L2 packet from network.
Next: VPN with tinc.
From: Nomen Nescio on 2 Jul 2008 12:10
The ip addresses have been munged on purpose.


Our server is 536.582.721.75 and is running RH9. We have one customer who can not get email over to us.
The iptables is setup to allow everything from 364.365.364.62.
I'm not even sure who is blocking whom and how did port 113 get into the picture?

The maillog shows:
Quote:
net sendmail[21611]: k5T6rkD0021611: mail.srek.org [364.365.364.62] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

The ethereal shows:
Frame 52676 (72 bytes on wire, 72 bytes captured)
Arrival Time: Jun 27, 2008 13:38:25.450935000
Time delta from previous packet: 0.120553000 seconds
Time since reference or first frame: 2465.590010000 seconds
Frame Number: 52676
Packet Length: 72 bytes
Capture Length: 72 bytes
Protocols in frame: sll:ip:icmp:ip:tcp
Linux cooked capture
Packet type: Unicast to us (0)
Link-layer address type: 1
Link-layer address length: 6
Source: Watchgua_2e:g9:36 (00:90:7f:2e:g9:36)
Protocol: IP (0x0800)
Internet Protocol, Src: 364.365.364.62 (364.365.364.62), Dst: 536.582.721.75 (536.582.721.75)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 56
Identification: 0x1435 (5173)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 51
Protocol: ICMP (0x01)
Header checksum: 0x71e1 [correct]
Good: True
Bad : False
Source: 364.365.364.62 (364.365.364.62)
Destination: 536.582.721.75 (536.582.721.75)
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 3 (Port unreachable)
Checksum: 0x5155 [correct]
Internet Protocol, Src: 536.582.721.75 (536.582.721.75), Dst: 364.365.364.62 (364.365.364.62)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 60
Identification: 0x1aa8 (6824)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 47
Protocol: TCP (0x06)
Header checksum: 0x2f65 [correct]
Good: True
Bad : False
Source: 536.582.721.75 (536.582.721.75)
Destination: 364.365.364.62 (364.365.364.62)
Transmission Control Protocol, Src Port: 51369 (51369), Dst Port: auth (113)
Source port: 51369 (51369)
Destination port: auth (113)

From: David Schwartz on 2 Jul 2008 13:23
On Jul 2, 9:10 am, Nomen Nescio <nob...(a)dizum.com> wrote:

> The ip addresses have been munged on purpose.
>
> Our server is 536.582.721.75 and is running RH9.
> We have one customer who can not get email over to us.

I take this to mean that he sends email using his own mail agent and
you do not receive the emails? Does he get a bounce?

> The iptables is setup to allow everything from 364.365.364.62.
> I'm not even sure who is blocking whom and how did port 113 get into the picture?
>
> The maillog shows:
>     Quote:
>     net sendmail[21611]: k5T6rkD0021611: mail.srek.org [364.365.364.62] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

This means your server saw the other end close the connection without
even trying to send any mail.

> The ethereal shows:
> Frame 52676 (72 bytes on wire, 72 bytes captured)
>     Arrival Time: Jun 27, 2008 13:38:25.450935000
>     Time delta from previous packet: 0.120553000 seconds
>     Time since reference or first frame: 2465.590010000 seconds
>     Frame Number: 52676
>     Packet Length: 72 bytes
>     Capture Length: 72 bytes
>     Protocols in frame: sll:ip:icmp:ip:tcp
> Linux cooked capture
>     Packet type: Unicast to us (0)
>     Link-layer address type: 1
>     Link-layer address length: 6
>     Source: Watchgua_2e:g9:36 (00:90:7f:2e:g9:36)
>     Protocol: IP (0x0800)
> Internet Protocol, Src: 364.365.364.62 (364.365.364.62), Dst: 536.582.721..75 (536.582.721.75)
>     Version: 4
>     Header length: 20 bytes
>     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
>         0000 00.. = Differentiated Services Codepoint: Default (0x00)
>         .... ..0. = ECN-Capable Transport (ECT): 0
>         .... ...0 = ECN-CE: 0
>     Total Length: 56
>     Identification: 0x1435 (5173)
>     Flags: 0x00
>         0... = Reserved bit: Not set
>         .0.. = Don't fragment: Not set
>         ..0. = More fragments: Not set
>     Fragment offset: 0
>     Time to live: 51
>     Protocol: ICMP (0x01)
>     Header checksum: 0x71e1 [correct]
>         Good: True
>         Bad : False
>     Source: 364.365.364.62 (364.365.364.62)
>     Destination: 536.582.721.75 (536.582.721.75)
> Internet Control Message Protocol
>     Type: 3 (Destination unreachable)
>     Code: 3 (Port unreachable)
>     Checksum: 0x5155 [correct]
>     Internet Protocol, Src: 536.582.721.75 (536.582.721.75), Dst: 364..365.364.62 (364.365.364.62)
>         Version: 4
>         Header length: 20 bytes
>         Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
>             0000 00.. = Differentiated Services Codepoint: Default (0x00)
>             .... ..0. = ECN-Capable Transport (ECT): 0
>             .... ...0 = ECN-CE: 0
>         Total Length: 60
>         Identification: 0x1aa8 (6824)
>         Flags: 0x04 (Don't Fragment)
>             0... = Reserved bit: Not set
>             .1.. = Don't fragment: Set
>             ..0. = More fragments: Not set
>         Fragment offset: 0
>         Time to live: 47
>         Protocol: TCP (0x06)
>         Header checksum: 0x2f65 [correct]
>             Good: True
>             Bad : False
>         Source: 536.582.721.75 (536.582.721.75)
>         Destination: 364.365.364.62 (364.365.364.62)
>     Transmission Control Protocol, Src Port: 51369 (51369), Dst Port: auth (113)
>         Source port: 51369 (51369)
>         Destination port: auth (113)

This isn't relevant. This is an RFC1413 auth attempt. You are not
running an RFC1413 auth server.

DS
From: Per Weisteen on 3 Jul 2008 18:02
Nomen Nescio wrote:
> The ip addresses have been munged on purpose.
>
>
> Our server is 536.582.721.75 and is running RH9. We have one customer who can not get email over to us.
> The iptables is setup to allow everything from 364.365.364.62.
> I'm not even sure who is blocking whom and how did port 113 get into the picture?
>
> The maillog shows:
> Quote:
> net sendmail[21611]: k5T6rkD0021611: mail.srek.org [364.365.364.62] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
>
>

As another reader has commented, port 113 is for the Ident protocol.
This indicates that the sending party MAY have sendmail configured to
perform an Ident check before sending mail to you and that the Ident
timeout parameter has been set too high. You may either choose to start
ident daemon on your RH server and allow requests on port 113 through
your firewall or ask the sending party to change sendmail configuration
to set a lower value for ident timeout.

...then again there could be 100 other reasons why the sending party
fails... he may not even run sendmail....


 | 
Pages: 1
Prev: I need help to hook L2 packet from network.
Next: VPN with tinc.