Guest User!

You are not Sophos Staff.

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

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
  • 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.

  • 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

  • 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.

Reply
  • 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.

Children
  • 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). 

    __________________________________________________________________________________________________________________

  • 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

  • Hallo Dirk,

    ja, Factory reset und neues Release habe ich auch schon gemacht. Auch eine minimal Konfiguration auf der
    Fritzbox hat nichts gebracht.

    Die Fritzbox ist eine 7490 und FritzOS ist 7.29. Vor dem Update ware es FritzOS irgend etwas bei 6.80.

    Das ist eigentlich schon die zweite Fritzbox. Bei der Installation der SD-20 RED beim Kunden steht auf eine Fritzbox 7490. FritzOS irgend etwas mit 6.30. Als wir dort vor Ort nicht weiter kamen, habe ich das RED wieder mitgenommen und die zweite 7490 ins Testlab mit eingebaut. Allerdings bisher ohne Erfolg.

    Soweit ich die Konfiguration der Fritzbox durchgesegen habe, ist nichts aktiviert, alles default nach Factory Reset. Nur die DSL-Daten und das Heimnetzwerk entsprechend angepasst.

    Wie bekomme ich raus, ob bei der Fritzbox irgendwelche Prüfungen laufen?

    Rolf

  • Sperren in der FB kenne ich nur unter internet/Filter. Und evtl. nicht den Gast-Lan-Port nutzen... falls aktiviert.

    Ich habe auch eine FB (aber FB7530) mit aktuell 7.29. Von hier aus habe ich auch schon verschiedene RED getestet.

    Die Meldung "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" kommt immer, wenn das RED versucht sich zu verbinden? Evtl. sind das auch nur normale "port-scans". Ich hatte in der letzten Zeit wiederholt den Effekt, dass ein RED sich nicht zu einer neuen Firewall verbinden wollte und ich erst ein reset machen musste (beim Verbinden mit dem Strom für 30 sec in das Reset-loch drücken)

    Ist auf der FW evtl. SSL3 deaktiviert? Die älteren RED-Geräte (ohne SD-) wollten sich dann initial nicht verbinden.

    Kannst du mir die Firewall-IP oder den Namen aus der RED Konfiguration per PM schicken? Ich würde gern was prüfen.


    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.

  • Bad certificate could be potentially a problem may be due to 

    1. MTU size mismatch

    --> Take packet capture between working and non working scenario and verify the pcap on wireshark.

    2. NTP time 

    --> Connect FAT formateted USB on RED20 device ,Capture the logs between working and non working scenario and verify that if there is difference in time duing connection to XGS.

  • Hello Kaushal,

    one of my first thoughts was MTU, but there is only at the RED configuration the possibility to change the MTU. I changed it from 1500 to 1000, but no positive result. The tunnel from the RED do not came up.

    Currently the Fritzbox is NTP-Server and get his time from europe.pool.ntp.org. On my notebook I installed ntp client and checked the ntp server from the friotzbox. ntp was okay.

    Tomorrow I will check ntp on the XGS.

    If the RED device is not behind the Fritzbox, the tunnel comes up from the RED. So I think NTP must be okay.

    Do you have another hint for me?

    regards

    Rolf 

  • Hi Rolf,

    SD-RED uses following urls for ntp service : 

    0.sophos.pool.ntp.org
    1.sophos.pool.ntp.org
    2.sophos.pool.ntp.org
    3.sophos.pool.ntp.org

    Also MTU configuration on UI is applicable to red interface created on XG/XGS side and not applicable to MTU of WAN of SD-RED.

    Again suggesting you to take pcap of working and non working scenario as suggested before and provide the logs.

  • Hi Kaushal,

    I will check this out via pcap tomorrow. Today is a public holiday in Germany.

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

    Regards

    Rolf

  • Hi Rolf,

    Please take pcap for port 3400 on XGS for both working and non working use case. This will help to check if there is a issue with MTU.

    Also connect fat formatted USB to SD-RED to collect the logs before starting test. This will help to check if there is a issue with NTP.

  • 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