SRX

I have attached an overview of my network. All SRX240 devices are SRX240B.

I am sitting at a computer attached to 172.31.255.107 (on a VLAN 172.23.70/23). I am trying to access a device on 172.31.255.108 (IP 172.17.1.2).

I am able to ping this device from my desktop but I cannot access its web interface. The same is true for a computer attached to 172.31.255.104. However, a computer attached to 172.31.255.102 can access it fine.

Also, I have the exact same hardware on 172.31.255.109 and can access this fine from the machines mentioned allready.

If I do a traceroute from a machine on 172.31.255.107 to 172..31.255.108 then the traceroute gets as far as the IP for the link on 172.31.255.108-102 and then stops.

If I remove the link from 172.31.255.108 to 172.31.255.102 then everything works fine from every machine using web access and traceroutes.

This has me completly at a loss.

All links shown on the diagram and /30 links (with the exception of the VPLS cloud) running OSPF set as P2P (again, except the VPLS cloud).

All links mentioned are cost 1.

If any more detail is required please let me know. Equally if I need to draw a different diagram to remove some extra detail I will. I thought i'd include the entire network for the sake of completeness.

Any and all suggestions are greatfully received.

Hi

I'm assuming your problem is connected with asymmetric routing and statuful

firewalling. You have equal-cost paths between (for example) 172.31.255.107

and 172.31.255.108 so the HTTP (SSH) session happens to be asymmetric

and is dropped by stateful firewall of SRX device. When you remove link

108-102, no equal cost path exists anymore, only 1 way, so session is 

symmetric and everything works.

Now how to solve the problem depends on what you really want to

acheive (and wanted to do with your network design). As a quick workaround try 

set security flow tcp-session no-syn-check 

on all firewalls, which will basically allow asymmetric TCP session. This command

also decreases security of the network so I do not recommend it as a permanent

solution.

PK,

That sounds very likely, I will test first thing tomorrow.

My only question would be, why is this not an issue for 172.31.255.102 accessing 172.31.255.109?

Hi

Just the fact that you have equal-cost paths does not guarantee you will

have asymmetric routing, basically this is a random thing (every router

chooses a random path between equal-cost ones). So for the case

102-109 it probably so happened that routing became symmetric.

But if you try a "restart routing" command on some routers, that will

re-calculate the paths and you may see same issue between 102 and

109. This command however affects all transit traffic so mostly used in

lab, not a production environment.

That works spot on, thank you.

Can you either elaborate on the security implications or can you link me to some further reading please? This is all a private network so I'm hoping the security implications will be minimal.

Thanks again.

Andrew.

Here is some information for you:

With SYN checking enabled, the Juniper Networks device rejects TCP segments with non-SYN flags set unless they belong to an established session. Enabling SYN checking can help prevent attacker reconnaissance and session table floods.

http://www.juniper.net/techpubs/software/junos-security/junos-security96/junos-security-swconfig-security/id-93100.html#id-93100

This link has more detailed information. If you need more, I could look up something in an email about this I sent myself a couple years ago, if I can still find it.

Hi

As further reading I would recommend "Juniper SRX series" book.

It is hard to give recommendations without having all your network's
requirements. In short, SRX can be used either as a "firewall"
(doing perimeter security, separating zones/interfaces, etc) or
just as a "router" that doesn't care much about security and
access policies, just passing traffic between interfaces.

If you have a second case here (it looks so), then disabling SYN
checking does not look significant. But in this case you could
disable stateful firewalling altogether (using "set security flow
family mpls mode packet-based"). Again not a recommendation
until we know all your requirements.