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

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

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

You have to configure the network behind UTM you wish to reach from RED device as split-network.

If you have 10.100.100.0/24 behind the RED and configure 10.100.100.0/24 as split-network which the RED should reach over the UTM ... these networks overlap (or be the same) and the tunnel isn't established.

Hello Dirk,

yes, you are right. I tried this also, but if I configure the split-network with 192.168.0.0/16 (these are the networks behind the UTM) the tunnel comes up. I assumed that the split network would then be routed or bridged via the RED in the direction of UTM, so that all end devices in the network 10.100.100.0/24 could reach the central network 192.168.0.0/16 if required. That doesn't work either, or there is another problem in the configuration.

Currently I have to configure static routes for the networks 192.168.0.0/16 on the end devices. Without the static routes, the end devices cannot reach the central networks 192.168.0.0/16.

Rolf

Hello Dirk,

below is a short excerpt from the transparent/split mode description.

Only traffic destined for certain networks transmits down the tunnel. In this case, the RED does not act as the gateway, but it is in-line with the gateway and can transparently redirect packets down the tunnel.

If this certain networks are the networks, which has to be configured as split-networks, it does not work.

If it's not these certain networks, I wonder where I have to configure these certain networks.

Rolf

Hello Dirk,

I build up the lab again and checked it. Now it works, the problem was the configuration of the PC.

Regards

Rolf