0

We do have a problem; we setup a used Juniper SRX3400 Cluster hoping to move our configuration from old SRX3400 Cluster to new one (for some reason), however everything works but we cannot make HTTPS traffic with "some" websites.

  • Google, Amazon with https works but we cannot make traffic with StackExchange
  • When we make traffic on flow sessions I can seee Junos:SSL and Junos:Amazin however when visiting StackExchange it says: Junos:SSL/INCONCLUSIVE
  • Can make ssh connection to server behind firewall
  • Can make http connection to server behind firewall
  • Cannot make https connection in both directions
  • Can ping firewall
  • Can ping server behind firewall

We are planning to work on long term with the network administrator as we have lots of issues like this. This task is basicly a test task that.

2
  • Please add more information about your environment. Is "SSL Deep Inspection" being done, in other words: is the SRX is generating/faking certificates (signed by its on-device PKI/CA) for external servers, and the clients see this faked certificate? If yes, which (local) CA certificate is the SRX it using to sign/fake these server certificates? Are there any whitelists or exemption rules for SSL Deep Inspection, like for amazon or google, but not for other sites? The SRX's local CA Certificate (or it's parent), has it been imported to the client's trust stores? Aug 6 '20 at 6:42
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin
    Dec 17 '20 at 20:25
2

Juniper has a good Tech Library page for troubleshooting SSL proxy issues. It's a complex subject -- especially if you're not very familiar with PKI concepts -- and they've done a nice job of aggregating some common commands into a cheat-sheet. There's also information on related logging.

https://www.juniper.net/documentation/en_US/junos/topics/task/troubleshooting/security-ssl-proxy-troubleshooting.html#id-ssl-proxy-counters-errors

2

I know this is an old question, but for anyone else with a similar issue, it sounds like TCP-MSS clamping is not configured on the new SRX.

Inevitably you'll be blocking ICMP on the SRX, which in turn breaks PMTUD and causes problems for TCP when MTU sizes change.

This plays havoc during SSL key exchange where the payload is almost always larger than 1500 bytes.

To resolve this, use the following command on the SRX:

set security flow tcp-mss all-tcp mss 1380 

where the mss size is something less than 1400 bytes.

The lower you set the number, the more TCP packets will be required to transmit the same amount of data, so aim high ;)

1
  • Good point. Generally blocking ICMP isn't a really bright idea, especially when it comes to v6...
    – Zac67
    Nov 24 at 12:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.