SRX

HI All,

 

We replace the SSG-5 to SRX220H2, then we found that our mail server cannot receive some of the email with a simple TIMEOUT error. But we can normally receive email from other senders with or without attachements (so the problem may not due to email size).

 

After asking the sender for their evaulation, they reply us the problem seems to be as SPAM. But I just swap back to our old SSG-5, haven't change any settings on the mail server and those email can receive successfully.

 

Can anyone suggest which part should I check for the issues. I just through of the security part of our SRX220 as attached.

 

ids-option untrust-screen {
  icmp {
    ping-death;
  }
  ip {
      source-route-option;
      tear-drop;
   }
   tcp {
        syn-flood {
          alarm-threshold 1024;
          attack-threshold 200;
          source-threshold 1024;
          destination-threshold 2048;
          timeout 20;
    }
    land;
  }
}

 

I have try to change those value of syn-flood but still cannot solve the issues. Any suggestion?

Hi,

Do you implement AV on the SRX ?
Can you provide the traceoptions for the traffic flow?
Have you tried changing the order of the relevant policies ?

Hi,

 

1) NO AV enable in SRX.

 

3) I have already put the zone policy at the top of the security session but still with the same issues.

 

2) Here' the traceoption log for our the sessions. I have external IP 202.181.xxx.yyy static NAT to 192.168.1.3 and the sender's email server address as 210.6.a.bbb.

 

Nov 18 08:59:01 08:59:00.718268:CID-0:RT:<210.6.a.bbb/60155->202.181.yyy.xxx/25;6> matched filter faxrecx:
Nov 18 08:59:01 08:59:00.718268:CID-0:RT:packet [52] ipid = 62982, @0x4350a626
Nov 18 08:59:01 08:59:00.718268:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x4350a400, rtbl_idx = 10
Nov 18 08:59:01 08:59:00.718268:CID-0:RT: flow process pak fast ifl 72 in_ifp pp0.0
Nov 18 08:59:01 08:59:00.718268:CID-0:RT: pp0.0:210.6.a.bbb/60155->202.181.yyy.xxx/25, tcp, flag 10
Nov 18 08:59:01 08:59:00.718268:CID-0:RT: find flow: table 0x5068df18, hash 14887(0xffff), sa 210.6.a.bbb, da 202.181.yyy.xxx, sp 60155, dp 25, proto 6, tok 40971
Nov 18 08:59:01 08:59:00.718268:CID-0:RT: flow got session.
Nov 18 08:59:01 08:59:00.718268:CID-0:RT: flow session id 61734
Nov 18 08:59:01 08:59:00.718268:CID-0:RT: vector bits 0x1002 vector 0x486b25d0
Nov 18 08:59:01 08:59:00.718268:CID-0:RT: tcp seq check.
Nov 18 08:59:01 08:59:00.718268:CID-0:RT:flow_xlate_pak
Nov 18 08:59:01 08:59:00.718268:CID-0:RT: post addr xlation: 210.6.a.bbb->192.168.1.3.
Nov 18 08:59:01 08:59:00.718268:CID-0:RT: post addr xlation: 210.6.a.bbb->192.168.1.3.
Nov 18 08:59:01 08:59:00.718268:CID-0:RT:skip pre-frag: is_tunnel_if- 0, is_if_mtu_configured- 0
Nov 18 08:59:01 08:59:00.718268:CID-0:RT:mbuf 0x4350a400, exit nh 0x170010
Nov 18 08:59:01 08:59:00.718268:CID-0:RT: ----- flow_process_pkt rc 0x0 (fp rc 0)

Nov 18 08:59:01 08:59:00.719019:CID-0:RT:<210.6.a.bbb/60155->202.181.yyy.xxx/25;6> matched filter faxrecx:
Nov 18 08:59:01 08:59:00.719019:CID-0:RT:packet [102] ipid = 62983, @0x434a4626
Nov 18 08:59:01 08:59:00.719019:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x434a4400, rtbl_idx = 10
Nov 18 08:59:01 08:59:00.719019:CID-0:RT: flow process pak fast ifl 72 in_ifp pp0.0
Nov 18 08:59:01 08:59:00.719019:CID-0:RT: pp0.0:210.6.a.bbb/60155->202.181.yyy.xxx/25, tcp, flag 18
Nov 18 08:59:01 08:59:00.719019:CID-0:RT: find flow: table 0x5068df18, hash 14887(0xffff), sa 210.6.a.bbb, da 202.181.yyy.xxx, sp 60155, dp 25, proto 6, tok 40971
Nov 18 08:59:01 08:59:00.719019:CID-0:RT: flow got session.
Nov 18 08:59:01 08:59:00.719019:CID-0:RT: flow session id 61734
Nov 18 08:59:01 08:59:00.719019:CID-0:RT: vector bits 0x1002 vector 0x486b25d0
Nov 18 08:59:01 08:59:00.719019:CID-0:RT: tcp seq check.
Nov 18 08:59:01 08:59:00.719019:CID-0:RT:flow_xlate_pak
Nov 18 08:59:01 08:59:00.719019:CID-0:RT: post addr xlation: 210.6.a.bbb->192.168.1.3.
Nov 18 08:59:01 08:59:00.719019:CID-0:RT: post addr xlation: 210.6.a.bbb->192.168.1.3.
Nov 18 08:59:01 08:59:00.719019:CID-0:RT:skip pre-frag: is_tunnel_if- 0, is_if_mtu_configured- 0
Nov 18 08:59:01 08:59:00.719019:CID-0:RT:mbuf 0x434a4400, exit nh 0x170010
Nov 18 08:59:01 08:59:00.719019:CID-0:RT: ----- flow_process_pkt rc 0x0 (fp rc 0)

Nov 18 08:59:01 08:59:00.916968:CID-0:RT:<192.168.1.3/25->210.6.a.bbb/60155;6> matched filter faxrecr:
Nov 18 08:59:01 08:59:00.916968:CID-0:RT:packet [52] ipid = 31258, @0x435f069e
Nov 18 08:59:01 08:59:00.916968:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x435f0480, rtbl_idx = 10
Nov 18 08:59:01 08:59:00.916968:CID-0:RT: flow process pak fast ifl 77 in_ifp ge-0/0/6.0
Nov 18 08:59:01 08:59:00.916968:CID-0:RT: ge-0/0/6.0:192.168.1.3/25->210.6.a.bbb/60155, tcp, flag 10
Nov 18 08:59:01 08:59:00.916968:CID-0:RT: find flow: table 0x5068df18, hash 50232(0xffff), sa 192.168.1.3, da 210.6.a.bbb, sp 25, dp 60155, proto 6, tok 6
Nov 18 08:59:01 08:59:00.916968:CID-0:RT: flow got session.
Nov 18 08:59:01 08:59:00.916968:CID-0:RT: flow session id 61734
Nov 18 08:59:01 08:59:00.916968:CID-0:RT: vector bits 0x1002 vector 0x486b25d0
Nov 18 08:59:01 08:59:00.916968:CID-0:RT: tcp seq check.
Nov 18 08:59:01 08:59:00.916968:CID-0:RT:flow_xlate_pak
Nov 18 08:59:01 08:59:00.916968:CID-0:RT: post addr xlation: 202.181.yyy.xxx->210.6.a.bbb.
Nov 18 08:59:01 08:59:00.916968:CID-0:RT: post addr xlation: 202.181.yyy.xxx->210.6.a.bbb.
Nov 18 08:59:01 08:59:00.916968:CID-0:RT:skip pre-frag: is_tunnel_if- 0, is_if_mtu_configured- 0
Nov 18 08:59:01 08:59:00.916968:CID-0:RT:mbuf 0x435f0480, exit nh 0x490010
Nov 18 08:59:01 08:59:00.916968:CID-0:RT: ----- flow_process_pkt rc 0x0 (fp rc 0)

Nov 18 08:59:01 08:59:00.939679:CID-0:RT:<192.168.1.3/25->210.6.a.bbb/60155;6> matched filter faxrecr:
Nov 18 08:59:01 08:59:00.939679:CID-0:RT:packet [103] ipid = 31260, @0x4351e91e
Nov 18 08:59:01 08:59:00.939679:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x4351e700, rtbl_idx = 10
Nov 18 08:59:01 08:59:00.939679:CID-0:RT: flow process pak fast ifl 77 in_ifp ge-0/0/6.0
Nov 18 08:59:01 08:59:00.939679:CID-0:RT: ge-0/0/6.0:192.168.1.3/25->210.6.a.bbb/60155, tcp, flag 18
Nov 18 08:59:01 08:59:00.939679:CID-0:RT: find flow: table 0x5068df18, hash 50232(0xffff), sa 192.168.1.3, da 210.6.a.bbb, sp 25, dp 60155, proto 6, tok 6
Nov 18 08:59:01 08:59:00.939679:CID-0:RT: flow got session.
Nov 18 08:59:01 08:59:00.939679:CID-0:RT: flow session id 61734
Nov 18 08:59:01 08:59:00.939679:CID-0:RT: vector bits 0x1002 vector 0x486b25d0
Nov 18 08:59:01 08:59:00.939679:CID-0:RT: tcp seq check.
Nov 18 08:59:01 08:59:00.939679:CID-0:RT:flow_xlate_pak
Nov 18 08:59:01 08:59:00.939679:CID-0:RT: post addr xlation: 202.181.yyy.xxx->210.6.a.bbb.
Nov 18 08:59:01 08:59:00.939679:CID-0:RT: post addr xlation: 202.181.yyy.xxx->210.6.a.bbb.
Nov 18 08:59:01 08:59:00.939679:CID-0:RT:skip pre-frag: is_tunnel_if- 0, is_if_mtu_configured- 0
Nov 18 08:59:01 08:59:00.939679:CID-0:RT:mbuf 0x4351e700, exit nh 0x490010
Nov 18 08:59:01 08:59:00.939679:CID-0:RT: ----- flow_process_pkt rc 0x0 (fp rc 0)

 

Thanks for the suggestions.

 

 

Thanks,

Jerald

 

Mail server i am assuming is local? If so what is the policy you have from users to this mail server? if its any Application? and you have the MSRPC ALG >show security alg status, if this is enabled i would disable it and see if this resolves your mail issue. if it doesnt then i would look and see what ports are trying to open from client to server and create a policy/application set with these ports in it to allow.

 

Thanks

 

James

HI James,

 

The mail server was at the same subnet with the users without any policy enable. So, may not due to issues regarding the policy.

 

Thanks for your advise.

 

Jerald

 

 

 

Hope someone would provide any suggestions on it. THANKS!!!!!

I wonder if there are any SMTP blocking machanism for Juniper SRX series firewall.

 

As stated by the mail server's log, the communication was well established. But when the command reqeust the sender to start transferring data, it suddenly stopped and waiting for the mail sever's TIMEOUT period and gonna be disconnected. Is there any hidden setting for SRX that allow the handshake for both our server but stopped the data transfer between us?

 

I just wonder..... 

HI All,

 

Anyone are familiar to the MTU settings between SRX220 and SSG5? As google the issues listed above, some findings saying the problem may due to the MTU settings. I wonder if this is the cause as the MTU settings variety between SRX and SSG. Thanks!!!

 

Jerald

 

Weird indeed that it is only from one customer.

 

Try lowering the MSS

 

user@srx#set security flow tcp-mss all-tcp mss 1350

Hi MMcD,

 

Many Many Many Super ThankS!!!!

The probelm just solved by adding the statement. You know, we try to find solution for 3 months include mail server re-installation testing...... it was amazing....

 

Super Thanks!!!