Intrusion Prevention
Intrusion Prevention

SRX blocks session but leaves no trace?

‎11-24-2017 11:57 PM

Hi,

 

I've got a curious problem. After few days of testing IPS I've found, that there is at least one target that my SRX blocks my access to, but it leaves no trace anywhere:

  • it's a simple HTTP session (TCP80)
  • the target is accessible from any other host (91.213.107.195) incl. our edge routers (so it's not our ISP's fault)
  • the connection is not blocked by firewall (valid session registered at show security flow session)
  • the connection is not blocked by ip-action (no entry in show security flow ip-action and no corresponding event in log)
  • no other device influences the result (session fails even when tested/started directly from SRX)

The system is comprised of a chassis cluster of two SRX1400 @ 12.3X48-D40.5.

Do you have any idea where else to look for a possible cause for this blocking?

3 REPLIES 3
Intrusion Prevention

Re: SRX blocks session but leaves no trace?

‎11-25-2017 02:37 AM

Can you enable  IDP and flow traceoptions and check  for any inputs?

 

-CK

Intrusion Prevention

Re: SRX blocks session but leaves no trace?

‎11-25-2017 04:10 AM

Does the session data show bi-directional flow or only one direction?

 

I have seen this type of behavior when there is asymetrical path routing so the return traffic from the server does not hit the SRX.

 

Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP)
http://puluka.com/home
Intrusion Prevention

Re: SRX blocks session but leaves no trace?

[ Edited ]
‎11-25-2017 04:41 AM

It seems that the thorough testing has lead me to a most surprising result...

 

The edge routers (between SRX and ISP) use the ISP-assigned IP and in my tests, these IP were the source of our successful connection attempts.

I've assigned some of our PI addresses to them and, with them as source, I was unable to connect to target (but were able to connect to other webservers in the network).

 

It suggests that the problem lays outside the SRX and, most likely, either our whole AS was blocked on the target's network or there is some other issue affecting them. Huh...