Security

On the screenshot below is the IF St0.0 the remote side tunnel interface?

Session ID: 4294995713, Policy name: BRIC-Apps-Servers/6, HA State: Stand-alone, Timeout: 20, Valid
  In: 10.253.252.6/11720 --> 10.25.50.43/443;tcp, Conn Tag: 0x0, If: st0.0, Pkts: 2, Bytes: 104,
  Out: 10.25.50.43/443 --> 10.253.252.6/11720;tcp, Conn Tag: 0x0, If: ge-0/0/4.0, Pkts: 2, Bytes: 104,

The reason I ask is because I have a SRX with multiple tunnel interfaces that are unnumbered and for this client the local interface is st0.4

I migrated yesterday from a old SSG5 to a SRX300 and some traffic seems to be working and some is not working.

In this case the customer indicates they are not getting the web page back. 

Your reading is correct, the SRX is seeing st0.0 as the interface source.

Check the routing table to confirm where 10.253.252.6 is pointed, likely to the st0.0 interface.  Security policy in/out are directed based on routing table interfaces.

One possible issue is that the route that should direct 10.253.252.6 to st0.4 is pointed to st0.0 instead.  Which would also explain by the verified reply packets are not reaching the desired destination.

On the screenshot below is the IF St0.0 the remote side tunnel interface?

Session ID: 4294995713, Policy name: BRIC-Apps-Servers/6, HA State: Stand-alone, Timeout: 20, Valid
  In: 10.253.252.6/11720 --> 10.25.50.43/443;tcp, Conn Tag: 0x0, If: st0.0, Pkts: 2, Bytes: 104,
  Out: 10.25.50.43/443 --> 10.253.252.6/11720;tcp, Conn Tag: 0x0, If: ge-0/0/4.0, Pkts: 2, Bytes: 104,

The reason I ask is because I have a SRX with multiple tunnel interfaces that are unnumbered and for this client the local interface is st0.4

I migrated yesterday from a old SSG5 to a SRX300 and some traffic seems to be working and some is not working.

In this case the customer indicates they are not getting the web page back. 

I appreciate the feedback from everyone as always.  My issue is resolved at this time. This was due to unnumbered tunnel interfaces and that on the old SSG5 all the tunnels were able to terminate on st0 using a pointer to the loopback address on the old technology. On the SRX this is not possible to reference the loopback address from the tunnel interface.  The options are very simple either place a IP on your st0 unit 0 and use that or have multiple st0 unit (whaterever) to allow multiple tunnels. This option requires more specific routes to each tunnel for the remote clients.

Your reading is correct, the SRX is seeing st0.0 as the interface source.

Check the routing table to confirm where 10.253.252.6 is pointed, likely to the st0.0 interface.  Security policy in/out are directed based on routing table interfaces.

One possible issue is that the route that should direct 10.253.252.6 to st0.4 is pointed to st0.0 instead.  Which would also explain by the verified reply packets are not reaching the desired destination.

On the screenshot below is the IF St0.0 the remote side tunnel interface?

Session ID: 4294995713, Policy name: BRIC-Apps-Servers/6, HA State: Stand-alone, Timeout: 20, Valid
  In: 10.253.252.6/11720 --> 10.25.50.43/443;tcp, Conn Tag: 0x0, If: st0.0, Pkts: 2, Bytes: 104,
  Out: 10.25.50.43/443 --> 10.253.252.6/11720;tcp, Conn Tag: 0x0, If: ge-0/0/4.0, Pkts: 2, Bytes: 104,

The reason I ask is because I have a SRX with multiple tunnel interfaces that are unnumbered and for this client the local interface is st0.4

I migrated yesterday from a old SSG5 to a SRX300 and some traffic seems to be working and some is not working.

In this case the customer indicates they are not getting the web page back.