Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 2 subscribers
  • Views 2225 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Some packet should not be dropped! Port 25

eclipse79oldacct
Hello
I have a SMTP server in my dmz interface, so I have created this DNAT rule:

Traffic Source: ANY
Traffic Service: SMTP
Traffic Destination: External WAN Address

Destination: Our Server SMTP
Automatic packet filter rule: yes

All seems to work fine, we receive mails, but I have noticed some dropped packets that should not be dropped! Like this:


2009:11:26-02:32:16 aitecfw ulogd[3276]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="0" seq="0" initf="eth1" outitf="unknown" dstmac="XX:XX:XX:XX:XX:XX" srcmac="00:00:00:00:00:00" srcip="189.140.42.22" dstip="MY PUBLIC WAN ADDRESS" proto="6" length="40" tos="0x00" prec="0x00" ttl="240" srcport="3247" dstport="25" tcpflags="ACK RST" 
2009:11:26-02:32:24 aitecfw ulogd[3276]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="0" seq="0" initf="eth1" outitf="unknown" dstmac="XX:XX:XX:XX:XX:XX" srcmac="00:00:00:00:00:00" srcip="189.140.42.22" dstip="MY PUBLIC WAN ADDRESS" proto="6" length="40" tos="0x00" prec="0x00" ttl="240" srcport="3305" dstport="25" tcpflags="ACK RST" 
2009:11:26-02:32:36 aitecfw ulogd[3276]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="0" seq="0" initf="eth1" outitf="unknown" dstmac="XX:XX:XX:XX:XX:XX" srcmac="00:00:00:00:00:00" srcip="189.140.42.22" dstip="MY PUBLIC WAN ADDRESS" proto="6" length="40" tos="0x00" prec="0x00" ttl="240" srcport="3318" dstport="25" tcpflags="ACK RST" 


Some other dropped packets have tcpflags="ACK FIN" and tcpflags="RST" 


ETH1 is WAN interface, destination port is 25, so the packet should pass! Could anyone help me? 
Thank you


This thread was automatically locked due to age.
Parents
  • 0
    I've never seen fwrule="0" and srcmac="00:00:00:00:00:00" also seems strange in this situation.

    What does the Mail Manager SMTP Log indicate?  Was someone in your office trying to send an email to someone at prod-infinitum.com.mx?

    What about the IPS log? You didn't say what version you are running, but V7.5 has a much more robust rule set.

    Cheers  - Bob
Reply
  • 0
    I've never seen fwrule="0" and srcmac="00:00:00:00:00:00" also seems strange in this situation.

    What does the Mail Manager SMTP Log indicate?  Was someone in your office trying to send an email to someone at prod-infinitum.com.mx?

    What about the IPS log? You didn't say what version you are running, but V7.5 has a much more robust rule set.

    Cheers  - Bob
Children
  • 0 in reply to BAlfson
    I've never seen fwrule="0" and srcmac="00:00:00:00:00:00" also seems strange in this situation.

    What does the Mail Manager SMTP Log indicate?  Was someone in your office trying to send an email to someone at prod-infinitum.com.mx?

    What about the IPS log? You didn't say what version you are running, but V7.5 has a much more robust rule set.

    Cheers  - Bob

    Hello, 
    I don't use SMTP Proxy, it is disabled. IPS Log does not have any of the blocked ip on port 25. BUT I have seen these ip in my SMTP log server: they are greylisted, so MY SMTP SERVER stops the connection:

    Thu 2009-11-26 10:38:21: --> 451 Greylisting enabled, try again in 2 minutes
    Thu 2009-11-26 10:38:24: *  Winsock Error 10054 Connessione reimpostata dall'altro lato.
    Thu 2009-11-26 10:38:24: SMTP session terminated (Bytes in/out: 80/394)

    but if the connections are terminated by my server... why astaro blocks these packets?

    The version of firmware is 7.501

    Bye
    eclipse79
  • 0 in reply to eclipse79oldacct
    The alerts you see are probably due to the way your SMTP server is dropping the connection... the remote host is trying to resend packets with invalid flags (now that the connection is dropped) and the packet filter denies them on this basis.  Normal behaviour, it's doing what it's supposed to do.