RED behind a Fritzbox does not set up a VPN

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.

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.

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.

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.

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 Kaushal,

I did both pcaps. But I do not see any problem with mtu or ntp.

To be sure I have configured the XGS to the Sophos ntp servers and take the captures files after this.

The tunnel do not come up if the RED is behind the Frotzbox. The tunnel comes up, if the RED is behind a Speedport.

Do you have some futŕther hints for me?

Regards

Rolf

Können wir mal einen Screenshot der Portfreigaben auf der Fritzbox sehen, bitte?

Hallo Herr Rusch,

ich habe es mit und ohne Portfreigaben probiert.

Soweit ich die Fritzbox verstanden habe, sollte sie ausgehend nur NAT machen.

Bei der Portfreigaben hatte ich für beide RED-IPs (WAN und LAN) TCP/3400 und UDP/3410 frei gegeben. 

Haben Sie einen Vorschlag dazu? Ich bin wirklich für alles offen.

Viele Grüße

Rolf Dobrig 

Hello Rolf,

SD-RED20 is not able to reach to NTP urls via FritzBox and because of which correct time is not set on SD-RED20.

Working Logs (Just look at the time stamp of logs : 

Thu Jun 23 09:54:35 2022 kern.err kernel: [ 50.556282] no peer (tx)
Thu Jun 23 09:54:35 2022 user.info lua syslog: [/usr/lib/lua/redd/service.lua]:81 Restarting sysntpd
Thu Jun 23 09:54:35 2022 kern.err kernel: [ 50.777115] no peer (tx)
Thu Jun 23 09:54:35 2022 kern.err kernel: [ 51.120508] no peer (tx)
Tue Nov 1 11:48:56 2022 daemon.info procd: Instance red-switch::red-switch-reset.sh s in a crash loop 6 crashes, 0 seconds since last crash
Tue Nov 1 11:48:56 2022 local1.notice red-sfpd[4438]: [MAIN][red-sfpd.cpp:112][main] --------------------------------
Tue Nov 1 11:48:56 2022 local1.notice red-sfpd[4438]: [MAIN][red-sfpd.cpp:113][main] RED SFP daemon
Tue Nov 1 11:48:56 2022 local1.notice red-sfpd[4438]: [MAIN][red-sfpd.cpp:114][main] Sophos
Tue Nov 1 11:48:56 2022 local1.notice red-sfpd[4438]: [MAIN][red-sfpd.cpp:115][main] --------------------------------
Tue Nov 1 11:48:56 2022 local1.notice red-sfpd[4438]: [MAIN][red-sfpd.cpp:117][main] SFP daemon start
Tue Nov 1 11:48:56 2022 local1.debug red-sfpd[4438]: [TOOLS][tools.cpp:68][get_board] board_name: sophos,red20

Non Working Logs : 

Thu Jun 23 09:55:20 2022 user.err lua syslog: [/usr/lib/lua/redd/state_machine.lua]:399 Failed to find ntp path: Failed to find connection path: Could not find any connection path using all configurations
Thu Jun 23 09:55:20 2022 user.err lua syslog: stack traceback: /usr/lib/lua/redd/utils/logger.lua:52: in function </usr/lib/lua/redd/utils/logger.lua:35> (tail call): ? /usr/lib/lua/redd/state_machine.lua:399: in function 'action' /usr/lib/lua/redd/redd.lua:156: in function </usr/lib/lua/redd/redd.lua:155> [C]: in function 'run' /usr/lib/lua/redd/redd.lua:170: in main chunk [C]: ?

Please allow following urls to work via Fritzbox for SD-RED20.

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

Hello Kaushal,

Below I summarize the current status. We have seen that the NTP path is missing on the RED in the event that the tunnel does not come up. A notebook connected behind the Fritzbox can reach the Sophos ntp server without any problems and received also the ntp time. A capture on the Fritzbox at the port of the RED has shown that not one single NTP packet from the RED device arrives on the Fritzbox.

So much for the current status

Thank you very much for your support so far. Without your support, we do not have this result.

I have forwarded the current result, including the various log files and pacap files to Sophos Support and I hope that Sophos Support will support us with further debugging activities on the RED. For example, to find out which packets are going from the RED to the Fritzbox via the WAN interface.

Regards

Rolf

I have found the problem.

It was a configuration problem inside the RED configuration with the split-network. After some tryouts I delete the configured split-network and after that the tunnel from the RED comes up. Meantime I have done some checks coldstart, warmstart and so on and it seemed to be stable.

The RED brings up the tunnel if the RED is behind the Fritzbox.

There are currently some open question inside. For example: Why come the tunnel up, if the RED was not behind the Fritzbox???

But I have no time to dig deeper.

many thanks for the support inside the Sophos community

Regards

Rolf

Hi Rolf,
great to see you solved the problem.
Only a last question ... are the IP-Ranges unique or do they overlap?

Greetings

Hello Dirk,

which ip-range do you mean? In front of the RED we have the network 10.100.100.0/24. The Fritzbox is the dhcp server in this network and so the RED received his IP-addresses from the Fritzbox. One ip-address for the WAN-Interface, one for the LAN-Interface and also one ip-address for the tunnel ip-address.

The RED has Operatoion mode transparent/split and if I configure this network as split-network, the tunnel does not come up. If i do not configure any split-network the tunnel comes up.

As I say, there are some open questions inside this case.

Do you have an idea regarding the split-network?

Rolf

What do you put in "split networks"? What do you mean by "this network"?

Hello Phillip,

currently I have nothing configured for the split-network. I I configure the network 10.100.100.0/24 as split-network, the tunnel does not come up.

Rolf