Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 27 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 3196 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RED behind a Fritzbox does not set up a VPN

Nomics Klinikum

Hello,

we support our customer with the following installation.

Two XGS 2100 are installed central inside the DMZ as HA clusters.  An external location shall be connected via a RED device. The configuration from the SD 20 RED device is transparent/split because the RED muste be integrated in an exiting network.

The RED device is connect to the internet via DSL-Router from AVM (Fritzbox). DHCP is provided in this external network from the Fritzbox. The ports TCP/UDP 3400 and TCP/UDP 3410 are open on the firewall at the central side. The RED device connect to the XGS-Cluster out of our test-Lab without any problems. In the test-lab the RED device was located behind a linux firewall. After successfully testing, the RED device is deployed at the external locatioon. But there the RED does not start the tunnel. The LEDs internet and router are green, the system LED is red.

After this failure, we also installed a Fritzbox in front of the RED in the test lab. The tunnel didn't come up here either. We changed the configuration from the Fritzbox several times, but the RED don'start the tunnel. As I understand it, the Fritzbox does only NAT and the tunnel must therefore start without any problems.

I open a case and on the same day we received the question if Telnet against red.astaro.com 3400 was possible. We answered with yes, but since this mail we received no other reaction from the sophos support. 

So we did some debbugging on the fritzbox and we see some packets with "bad certificate" and we see this also on the XGS inside the red.log

Thu Oct 20 10:17:25 2022Z REDD ERROR: server: Can not do SSL handshake on Socket accept from '88.68.185.204': SSL accept attempt failed
Thu Oct 20 10:17:27 2022Z REDD ERROR: server: Can not do SSL handshake on Socket accept from '88.68.185.204': SSL accept attempt failed error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate

We have communicated the new findings to Sophos Support, but unfortunately no reaction. I have read a lot of articels, but I does not found a practical solutiuon regarding the above failure. Since there is no response from Sophos support since some days, I would like to ask here what we can do to solve the problem.

regards

Rolf



This thread was automatically locked due to age.
Parents
  • 0

    Hi,

    i think you try "telnet to red.astaro.com 3400" from network behind FB?

    The destination is reachable for RED Services? Are there RED devices connected already?  Try testtls.com  with "your_destination:3400"

    A short network sketch would be helpful.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 0 in reply to dirkkotte

    Hello Dirk,

    yes, Telnet on red.astaro.com 3400 was one of the first checks.

    Enclosed the overview from the installation. The image is from the Sophos Support.

    On Friday we have a longer debugging session with the Sophos Support, but no result. The only point which is verified, is that the Fritzbox generated the failure..

    I have tried out several other positions from the RED Device. For example:

    Is the RED is behind a Linux Firewall (with the DSL), the tunnel comes up or is the RED behind a Speedport (German Telekom), the tunnel also comes up.

    Is the RED behind the Fritzbox, the tunnel dos not come up.

    I didn't make any configuration changes during testing on the XGS. So every time the same configuration.

    Currently my only finding is, that we see a ssl handshake problem between the RED and the XGS (in the red.log logfile)  if the RED is behind the Fritzbox.

    Sat Oct 29 09:48:08 2022Z REDD ERROR: server: Can not do SSL handshake on Socket accept from '87.133.110.206': SSL accept attempt failed
    Sat Oct 29 09:48:14 2022Z REDD ERROR: server: Can not do SSL handshake on Socket accept from '87.133.110.206': SSL accept attempt failed error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate
    Sat Oct 29 09:48:23 2022Z REDD ERROR: server: Can not do SSL handshake on Socket accept from '87.133.110.206': SSL accept attempt failed
    Sat Oct 29 09:48:25 2022Z REDD ERROR: server: Can not do SSL handshake on Socket accept from '87.133.110.206': SSL accept attempt failed error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate

    From The Sophos Support I received the proposal to download the certificate from the XGS and install it on the Fritzbox. I tried it out today, but same result.

    Any idea is welcome.

    Regards

    Rolf

  • 0 in reply to Nomics Klinikum

    Hallo,

    schon mal drüber nachgedacht, die FB zu tauschen?

    ... oder eine Aktualisierung / Factory-Reset zu machen?

    Ich habe diverse RED Devices hinter FritzBoxen ... und (fast) nie Probleme. Was für ein Modell ist es denn?

    Sind irgendwelche Schutzmechanismen/Prüfungen aktiviert ... mir fällt aber spontan nichts auf der FB ein, was das verursachen könnte.


    Dirk

    Systema Gesellschaft für angewandte Datentechnik mbH  // Sophos Platinum Partner
    Sophos Solution Partner since 2003
    If a post solves your question, click the 'Verify Answer' link at this post.

  • 0 in reply to dirkkotte

    Bad certificate could be potentially a problem with a decryption. But as far as i know, FB is not decrypting anything. 

    You could do following: Create a tcpdump on the firewall: Advanced shell: tcpdump -ni any port 3400 or port 3410 -b -w /tmp/red.pcap 

    Then reboot the RED. After reboot and waiting, download the file: https://support.sophos.com/support/s/article/KB-000035842?language=en_US

    In wireshark, check the used certificate of the TLS handshake (should be the packet 4). 

    __________________________________________________________________________________________________________________

Reply Children
  • 0 in reply to LuCar Toni

    Hi Toni,

    I will do this on Tuesday. Monday is a public holiday in Germany.

    I can't work on the XGS on weekends and public holidays.

    Many thanks for the hint.

    Regards

    Rolf

  • 0 in reply to LuCar Toni

    Hello Toni,

    I checked this out. The packet 4 is the packet with the failure "bad certificate".

    The first TLSv1.2 packet is "client hello"

    The second is "server hello" with the certifcate from teh XGS inside

    The third is "certificate request" and

    The fourth packet is "Alert", with the bad certificate message inside

    The red.log shows also the "bad certificate" failure.

    Tue Nov  1 07:02:57 2022Z REDD ERROR: server: Can not do SSL handshake on Socket accept from '80.128.69.97': SSL accept attempt failed
    Tue Nov  1 07:03:04 2022Z REDD ERROR: server: Can not do SSL handshake on Socket accept from '80.128.69.97': SSL accept attempt failed error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate

    After this trace I put the REd behind a Speedport DSL-Router (from German Telekom) and make the same trace. The tunnel from the RED comes up.

    The first three TLSv1.2 packet are more or less the same and the fourth packet is "certificate" with the certificate from the XGS inside.

    The red.log shows

    Tue Nov  1 07:10:31 2022Z REDD ERROR: server: Can not do SSL handshake on Socket accept from '93.242.78.166': SSL accept attempt failed
    Tue Nov  1 07:10:33 2022Z REDD INFO: server: New connection from 93.242.78.166 with ID R20002G2VRJBPD6 (cipher ECDHE-RSA-AES256-GCM-SHA384), rev1
    Reading REDv2 key from STDIN:
    Reading REDv2 key from STDIN:
    Reading REDv2 key from STDIN:
    Reading REDv2 key from STDIN

    Interesting is, that we see the ssl handshake problem, but the tunnel comes nonetheless up.

    What does this mean?

    Regards

    Rolf

     
Unfiltered HTML