I opened a case with HP concerning this issue. After escalating past the useless Level 1 tech, the Level 2 tech very alertly spotted something that I had not.

The SRX is sending its DHCPDISCOVER packet with a TTL of 1. The Procurve's apparently will decrement the TTL and use the resulting TTL in the relay'ed packet to the DHCP server. In this case, the decrement leaves the TTL at 0 meaning the packet gets dropped on the floor.

This is actually in spec for DHCP/BOOTP relay, though clearly it causes reduced interoperability. I have asked HPNetworking to treat this as a bug/RFE and change the behavior. No immediate response to that request in the case.

The SRX sending the DHCPDISCOVER with a TTL of 1 is also probably within spec, but, again, a choice of reduced interoperability, so I plan to open a case with JTAC on the same basis.

I'll add more info on the response of Juniper and HP as it becomes available.

Incidentally, I have tested the relay behavior of a Cisco 4506 (firmware version not immediately available), and a Brocade/Foundry FastIron Edge X (7.2 or 7.3 firmware, I believe, don't have immediate access to confirm) and they both handle relaying the request with TTL 1 without issue.

UPDATE There is a way to change the TTL value that the SRX uses on its DHCP requests, but its not from within the JunOS cli...its done from the underlying Unix OS.

root@% sysctl -w net.inet.ip.mcast_ttl=64

I have opened an RFE with HP to make their relaying function more resilient, but not response from them yet on if/when that will be worked on.

This issue occurs with your Quad Zero route. You have routes bound to interfaces and if you are fulfilling requests from a priv or dmz interface and you have a 0.0.0.0 route offered on that interface that is the path the return traffic will take to get back to the requesting source. If you need the traffic to return from the interface it was received from your will need to redo your routing on the device.

Suggestion

If you have a service window you can schedule.

Research how you would like your 0.0.0.0 routing to work per interface. I would imagine you might have some end user requests for Internet passing through the device too and that would need to be taken into consideration.

Modify your txt config file to what you believe is functional and load it up during your service window.

Have your testing regiment planned out and try and hit every item. If you fall into an abyss, load your config that you know is functional and return to a steady state and revisit the issue during your next window. Plan it, test it, nail it. Good luck.