No connection to OpenVPN

NethServer Version: 7.7.1908
Module: VPN RoadWarrior

Hi Community,
I’ve tried to setup an OpenVPN on several NethServer installations. My router is a fritzbox and the internet connection is a ds lite with an ipv6 address. The fritzbox is connected to myfritz. Following settings I do at the VPN-Server:

  • I take the myfritz address of my box as FQDN for the VPN.
  • The users at the server are only vpn-users.
  • Authentication is set to certificate
  • Port is UDP 1194 for the first and 1195 for the second server
  • Compression is tried with LZO and without compression

At the fritzbox I activated portforwarding for 1194 UDP to the first and 1195 UDP to the second server.

If I try to connect I get an TLS handshake error, I think the server is not found.

2020-03-10 22:55:53.608709 *Tunnelblick: macOS 10.15.2 (19C57); Tunnelblick 3.8.1 (build 5400); prior version 3.4beta20 (build 3727)
2020-03-10 22:55:53.905779 *Tunnelblick: Attempting connection with mtraeumner using shadow copy; Set nameserver = 769; monitoring connection
2020-03-10 22:55:53.906712 *Tunnelblick: openvpnstart start mtraeumner.tblk 61949 769 0 1 0 1098032 -ptADGNWradsgnw 2.4.7-openssl-1.0.2t
2020-03-10 22:55:53.930169 *Tunnelblick: openvpnstart starting OpenVPN
2020-03-10 22:55:54.261540 OpenVPN 2.4.7 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [MH/RECVDA] [AEAD] built on Sep 11 2019
2020-03-10 22:55:54.261626 library versions: OpenSSL 1.0.2t  10 Sep 2019, LZO 2.10
2020-03-10 22:55:54.263056 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:61949
2020-03-10 22:55:54.263127 Need hold release from management interface, waiting...
2020-03-10 22:55:54.531445 *Tunnelblick: openvpnstart log:
     OpenVPN started successfully.
     Command used to start OpenVPN (one argument per displayed line):
          /Applications/Tunnelblick.app/Contents/Resources/openvpn/openvpn-2.4.7-openssl-1.0.2t/openvpn
          --daemon
          --log /Library/Application Support/Tunnelblick/Logs/-SUsers-SMichael-SLibrary-SApplication Support-STunnelblick-SConfigurations-Smtraeumner.tblk-SContents-SResources-Sconfig.ovpn.769_0_1_0_1098032.61949.openvpn.log
          --cd /Library/Application Support/Tunnelblick/Users/Michael/mtraeumner.tblk/Contents/Resources
          --machine-readable-output
          --setenv IV_GUI_VER "net.tunnelblick.tunnelblick 5400 3.8.1 (build 5400)"
          --verb 3
          --config /Library/Application Support/Tunnelblick/Users/Michael/mtraeumner.tblk/Contents/Resources/config.ovpn
          --setenv TUNNELBLICK_CONFIG_FOLDER /Library/Application Support/Tunnelblick/Users/Michael/mtraeumner.tblk/Contents/Resources
          --verb 3
          --cd /Library/Application Support/Tunnelblick/Users/Michael/mtraeumner.tblk/Contents/Resources
          --management 127.0.0.1 61949 /Library/Application Support/Tunnelblick/jdihebmnnoboagckenbeclhhhfbmdfggafdghkcd.mip
          --management-query-passwords
          --management-hold
          --script-security 2
          --route-up /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
          --down /Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw
2020-03-10 22:55:54.546705 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:61949
2020-03-10 22:55:54.575914 MANAGEMENT: CMD 'pid'
2020-03-10 22:55:54.576030 MANAGEMENT: CMD 'auth-retry interact'
2020-03-10 22:55:54.576098 MANAGEMENT: CMD 'state on'
2020-03-10 22:55:54.576261 MANAGEMENT: CMD 'state'
2020-03-10 22:55:54.576344 MANAGEMENT: CMD 'bytecount 1'
2020-03-10 22:55:54.576865 *Tunnelblick: Established communication with OpenVPN
2020-03-10 22:55:54.579538 *Tunnelblick: >INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
2020-03-10 22:55:54.582868 MANAGEMENT: CMD 'hold release'
2020-03-10 22:55:54.594802 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2020-03-10 22:55:54.594891 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2020-03-10 22:55:54.597137 TCP/UDP: Preserving recently used remote address: [AF_INET6]2001:16b8:b03:fbc4:464e:6dff:fe49:4ac4:1194
2020-03-10 22:55:54.597265 Socket Buffers: R=[786896->786896] S=[9216->9216]
2020-03-10 22:55:54.597303 UDP link local: (not bound)
2020-03-10 22:55:54.597336 UDP link remote: [AF_INET6]2001:16b8:b03:fbc4:464e:6dff:fe49:4ac4:1194
2020-03-10 22:55:54.597391 MANAGEMENT: >STATE:1583877354,WAIT,,,,,,
2020-03-10 22:56:54.343871 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2020-03-10 22:56:54.344188 TLS Error: TLS handshake failed
2020-03-10 22:56:54.344602 SIGUSR1[soft,tls-error] received, process restarting
2020-03-10 22:56:54.344698 MANAGEMENT: >STATE:1583877414,RECONNECTING,tls-error,,,,,
2020-03-10 22:56:54.358690 MANAGEMENT: CMD 'hold release'
2020-03-10 22:56:54.358845 MANAGEMENT: CMD 'hold release'
2020-03-10 22:56:54.361117 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
2020-03-10 22:56:54.361235 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2020-03-10 22:56:54.361455 TCP/UDP: Preserving recently used remote address: [AF_INET6]2001:16b8:b03:fbc4:464e:6dff:fe49:4ac4:1194
2020-03-10 22:56:54.361538 Socket Buffers: R=[786896->786896] S=[9216->9216]
2020-03-10 22:56:54.361574 UDP link local: (not bound)
2020-03-10 22:56:54.361844 UDP link remote: [AF_INET6]2001:16b8:b03:fbc4:464e:6dff:fe49:4ac4:1194
2020-03-10 22:56:54.361900 MANAGEMENT: >STATE:1583877414,WAIT,,,,,,
2020-03-10 22:56:56.747402 *Tunnelblick: Disconnecting; VPN Details… window disconnect button pressed
2020-03-10 22:56:56.893511 *Tunnelblick: Disconnecting using 'kill'
2020-03-10 22:56:57.065071 event_wait : Interrupted system call (code=4)
2020-03-10 22:56:57.065239 SIGTERM received, sending exit notification to peer
2020-03-10 22:56:58.229679 SIGTERM[soft,exit-with-notification] received, process exiting
2020-03-10 22:56:58.229749 MANAGEMENT: >STATE:1583877418,EXITING,exit-with-notification,,,,,
2020-03-10 22:56:58.598561 *Tunnelblick: Expected disconnection occurred.

Tried this with different clients and different hotspots. Hotspots where both Vodafone, also with an IPv6 address.

Thanks for your help in advance

Michael

Can you manually modify the Tunnelblick configuration?
I would suggest you to connect to FritzBox, edit the destination IP address setting the one of NethServer into FritzBox LAN and try to connect.

2 Likes

Hi @pike,
thanks for your answer.

Yes I can, I imported the vpn-file downloaded from Nethserver VPN and this file I can edit.

Can you explain what you mean, please? The Nethserver has an internal IPv4 and the portforwarding at my fritzbox is set to this ip.
I can post the client config file this evening.

You can connect via OpenVPN through a LAN connection, contacting the private ip address of the RED of NethServer, if your lan cable (of the client) is connected to one port of the FritzBox router.

1 Like

Thanks for explanation, I’ll try it this evening.

A local connection works, so I think I have a problem with the routing through the fritzbox. Does anybody has it work with an IPv6 address and myfritz?

Maybe FritzBox it’s not fully responsible.
Would you please post some screenshot (english if possible) of your Port forwarding of your Router?

Hi @pike,
I’m sorry, but english is not possible at the german version.

If I should translate something you don’t understand, let me know.

Sorry, i don’t know German, therefore asking you “translate everything” it’s simply not viable.
Consider to download a portable English browser and visit your router page, asking “English pages”.
I use Waterfox, time to time…

Anyway: Freigaben should mean port forwarding, so you setup seems to forward only port 1194 to 192.168.178.4, RED interface of NethServer.
I see few options for port forwarding… So these are the cases that i see.

  • Some of these options could be enabled for improve the connection (an english screenshot would help a lot)
  • Some firewall rules IPv6 related should be enabled via shell to improve that (configuration fragments)
  • The lack if application IPv6 support won’t let access OpenVPN server from IPv6 address.
  • Do the Tunnelblick configuration consider to use IPv6?

Anyway…
OpenVPN since 2.3.0 supports IPv6
https://community.openvpn.net/openvpn/wiki/IPv6
Maybe dev team could consider this user case as an hint to take a bit more solicitously the IPv6 concerns, because AFAIK Germany is going full IPv6 soon, and it’s not the only country.

1 Like

Ok I’ll do it this evening and post a new screenshot.

Hope this is better. Thanks in advance.

If you don’t have to forward connections to other devices, i’d suggest you to enable both
Release this device completely for internet access via IPv4
Release this device completely for internet access via IPv6
and try again from IPv6 connection.

I’m quite confident that won’t change anything but i still would give a shot.

I’ll try this, thanks again.

Hi @pike,
I tried it for IPv4 and it doesn’t change anything.
For IPv6 I can’t enable this.
I read a lot and found that the internal device also needs an IPv6 address, if the external IP is an IPv6. So I can’t route to my nethserver, because it doesn’t get an IPv6. Has anybody an idea, how to solve it?

@dev_team

I also called my service provider to ask for an external IPv4, but it isn’t possible anymore.

Kind regards
Michael

Honestly, I can’t understand the problem.
Are UDP packets reaching NethServer wan?

Run:

tcpdump -nnpi <red_if> port 1194

and try to establish the vpn. If you see no packets, you must reconfigure the fritzbox until it works.
If you see packets, they might be dropped by the Nethserver itself. You may see them in firewall.log.
Try again disabling NethServer firewall: shorewall clear
Seeing firewall.log we could find a way to reconfigure the firewall.

3 Likes

If I try an internal vpn connection it works. I think my problem is routing from an external IPv6 address to an internal IPv4. Seems this doesn’t work.

Tried yesterday evening with TCP instead of UDP. Doesn’t work also.

[root@vpn ~]# tcpdump -nnpi eth0 port 1194
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C^C^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

At this time I use the green interface, because I have only one physical card. I added a virtual one at proxmox, but that didn’t help me.
So I think the problem is that my fritzbox didn’t route the external IPv6 address to an internal IPV4 address.

I guess the Fritzbox folks haven’t considered the case of an ISP only handing out an ipv6 address to a client running an ipv4 network as (my understanding) for ipv6 is that you would normally be allocated a block, that you would be expected to use to address your internal network devices, without having to resort to NAT. But that also requires all your internal network to speak ipv6.

Cheers.

1 Like

I searched the net and it seems possible to use another machine between the fritzbox and the Nethserver. This machine (could be a raspberry) needs to be IPv6 ready and uses 6tunnel to forward to the Nethserver. You need to change the OpenVPN port to TCP to make it work.

Another possibility may be to use a portmapper service like https://www.feste-ip.net/

It seems to be a problem in Germany only, I didn’t find English tutorials covering this topic:

https://www.andysblog.de/zugriff-auf-server-oder-eingehendes-vpn-mit-ds-lite-anschluessen

1 Like

Thanks @EddieA and @mrmarkuz,
I’ll test some things next week. I’ll also will look for some protocolls of the fritzbox. It can give me wireshark output-files.