GELÖST - VPN via UDP geht, via TCP nicht

Started by Luma, April 18, 2019, 09:18:45 AM

Previous topic - Next topic
... wenn ich nur wüsste was???

Das komische ist ja eben: Mit UDP get alles, es kann eine Verbindung hergestellet werden. Die restliche Konfiguration bleibt absolut identisch nur das Protokoll ändere ich von UDP nach TCP! Dann läuft es nicht mehr.

ich hätte gerne noch das du mal das bild web gui von deiner openvpn server config
Internet: Willy.tel Down: 1Gbit/s, UP: 250Mbit/s Glasfaser  |
Router/Firewall: pfSense+ 23.09  |
Hardware: Netgate 6100

Guten Morgen micneu

erst mal vielen Dank, dass du mit versuchst zu helfen, das schätze ich sehr!

Hier noch die Server-Konfigurations-GUI:




Noch eine Bemerkung:

Ich habe im GUI der Server- und der Client-Konfiguration alles eingestellt. Auch Protocol TCP. Dann bekomme ich die Fehlermeldung, wie im ersten Post beschrieben.

Dann habe ich lediglich im GUI der Server-Konfiguration das Protocol auf UDP umgestellt und im Client-Konfigurationsfile (nicht im OPNsense-GUI) von tcp auf udp umgestellt. Dann läuft alles!

Ist doch sehr merkwürdig!

Nochmals: Ziel ist es VPN mit Protocol TCP zum laufen zu bringen...

> Da ich aber UDP Ports nicht vorwarden kann, brauche ich einen TCP VPN Server.

Darf ich mal dazwischenfragen, was das heißen oder bedeuten mag?
"It doesn't work!" is no valid error description! - Don't forget to [applaud] those offering time & brainpower to help you!
Better have some *sense as no(n)sense! ;)

If you're interested in german-speaking business support, feel free to reach out via PM.

Hi JeGr

Der Grund ist, dass ich von meinem Provider auf meinem LTE-Router eine private IP bekomme. TCP-Ports kann ich via einen externen Host (Amazon) vorwarden, das geht leider mit UDP nicht.

Ich habe schon versucht auf dem Amazon Rechner mit socat UDP in TCP zu wandeln und das dann zu forwarden und bei mit socat wieder zurück nach UDP. Aber das klappt leider nicht richtig. Daher schien mit die einfachste Möglichkeit ein TCP VPN-Server zu konfigurieren.

Gruss Luma

Inzwischen habe ich auf einem andern Rechner OPNsense installiert. Dort habe ich keine grossen Einstellungen vorgenommen und einen VPN-Server definiert.

Leider bekomme ich TCP auch nicht zum laufen. Wie schon zuvor: UDP läuft perfekt. Dann stelle ich lediglich UDP auf TCP um und exportiere den Client nochmals. Dieselbe Fehlermeldung:
Sat Apr 27 13:25:41 2019 us=231485 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Sat Apr 27 13:25:41 2019 us=231485 Windows version 6.2 (Windows 8 or greater) 64bit
Sat Apr 27 13:25:41 2019 us=231485 library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
Enter Management Password:
Sat Apr 27 13:25:41 2019 us=232477 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25343
Sat Apr 27 13:25:41 2019 us=232477 Need hold release from management interface, waiting...
Sat Apr 27 13:25:41 2019 us=691023 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25343
Sat Apr 27 13:25:41 2019 us=798483 MANAGEMENT: CMD 'state on'
Sat Apr 27 13:25:41 2019 us=799376 MANAGEMENT: CMD 'log all on'
Sat Apr 27 13:25:41 2019 us=998770 MANAGEMENT: CMD 'echo all on'
Sat Apr 27 13:25:42 2019 us=784 MANAGEMENT: CMD 'bytecount 5'
Sat Apr 27 13:25:42 2019 us=4226 MANAGEMENT: CMD 'hold off'
Sat Apr 27 13:25:42 2019 us=5742 MANAGEMENT: CMD 'hold release'
Sat Apr 27 13:25:44 2019 us=195607 MANAGEMENT: CMD 'username "Auth" "Luma"'
Sat Apr 27 13:25:44 2019 us=206022 MANAGEMENT: CMD 'password [...]'
Sat Apr 27 13:25:44 2019 us=208998 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat Apr 27 13:25:44 2019 us=208998 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat Apr 27 13:25:44 2019 us=209493 Control Channel MTU parms [ L:1623 D:1138 EF:112 EB:0 ET:0 EL:3 ]
Sat Apr 27 13:25:44 2019 us=209989 Data Channel MTU parms [ L:1623 D:1450 EF:123 EB:406 ET:0 EL:3 ]
Sat Apr 27 13:25:44 2019 us=209989 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1603,tun-mtu 1500,proto TCPv4_CLIENT,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client'
Sat Apr 27 13:25:44 2019 us=209989 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1603,tun-mtu 1500,proto TCPv4_SERVER,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-server'
Sat Apr 27 13:25:44 2019 us=209989 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.231.5:1194
Sat Apr 27 13:25:44 2019 us=209989 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sat Apr 27 13:25:44 2019 us=209989 Attempting to establish TCP connection with [AF_INET]192.168.231.5:1194 [nonblock]
Sat Apr 27 13:25:44 2019 us=209989 MANAGEMENT: >STATE:1556364344,TCP_CONNECT,,,,,,
Sat Apr 27 13:27:45 2019 us=603663 TCP: connect to [AF_INET]192.168.231.5:1194 failed: Unknown error
Sat Apr 27 13:27:45 2019 us=604560 SIGUSR1[connection failed(soft),init_instance] received, process restarting
Sat Apr 27 13:27:45 2019 us=604560 MANAGEMENT: >STATE:1556364465,RECONNECTING,init_instance,,,,,
Sat Apr 27 13:27:45 2019 us=604560 Restart pause, 5 second(s)
Sat Apr 27 13:27:47 2019 us=605828 SIGTERM[hard,init_instance] received, process exiting
Sat Apr 27 13:27:47 2019 us=605828 MANAGEMENT: >STATE:1556364467,EXITING,init_instance,,,,,


Jemand eine Idee? Ich bin ratlos...

Wenn Du UDP nutzt, was steht da bei Link-MTU? Weil 1603 erscheint mir etwas groß und gerade wenn ich MTU ud LTE google, dann sind die Werte eher noch kleiner als bei Ethernet (1500)
Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz (24 cores)
256 GB RAM, 300GB RAID1, 3x4 10G Chelsio T540-CO-SR

Hi hbc

Bei UDP ist die Link-MTU 1601. Hier findest du den Log mit der erfolgreichen UDP-Verbindung:

Sat Apr 27 14:35:36 2019 us=732288 OpenVPN 2.4.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 26 2018
Sat Apr 27 14:35:36 2019 us=732288 Windows version 6.2 (Windows 8 or greater) 64bit
Sat Apr 27 14:35:36 2019 us=732288 library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
Enter Management Password:
Sat Apr 27 14:35:36 2019 us=733280 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25343
Sat Apr 27 14:35:36 2019 us=733280 Need hold release from management interface, waiting...
Sat Apr 27 14:35:37 2019 us=196511 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25343
Sat Apr 27 14:35:37 2019 us=304111 MANAGEMENT: CMD 'state on'
Sat Apr 27 14:35:37 2019 us=305101 MANAGEMENT: CMD 'log all on'
Sat Apr 27 14:35:37 2019 us=511435 MANAGEMENT: CMD 'echo all on'
Sat Apr 27 14:35:37 2019 us=512922 MANAGEMENT: CMD 'bytecount 5'
Sat Apr 27 14:35:37 2019 us=513914 MANAGEMENT: CMD 'hold off'
Sat Apr 27 14:35:37 2019 us=515402 MANAGEMENT: CMD 'hold release'
Sat Apr 27 14:35:39 2019 us=429806 MANAGEMENT: CMD 'username "Auth" "Luma"'
Sat Apr 27 14:35:39 2019 us=437341 MANAGEMENT: CMD 'password [...]'
Sat Apr 27 14:35:39 2019 us=439821 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat Apr 27 14:35:39 2019 us=439821 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Sat Apr 27 14:35:39 2019 us=439821 Control Channel MTU parms [ L:1621 D:1140 EF:110 EB:0 ET:0 EL:3 ]
Sat Apr 27 14:35:39 2019 us=440319 Data Channel MTU parms [ L:1621 D:1450 EF:121 EB:406 ET:0 EL:3 ]
Sat Apr 27 14:35:39 2019 us=440319 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client'
Sat Apr 27 14:35:39 2019 us=440319 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1601,tun-mtu 1500,proto UDPv4,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-server'
Sat Apr 27 14:35:39 2019 us=440813 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.231.5:1194
Sat Apr 27 14:35:39 2019 us=440813 Socket Buffers: R=[65536->65536] S=[65536->65536]
Sat Apr 27 14:35:39 2019 us=440813 UDP link local (bound): [AF_INET][undef]:0
Sat Apr 27 14:35:39 2019 us=440813 UDP link remote: [AF_INET]192.168.231.5:1194
Sat Apr 27 14:35:39 2019 us=440813 MANAGEMENT: >STATE:1556368539,WAIT,,,,,,
Sat Apr 27 14:35:39 2019 us=447261 MANAGEMENT: >STATE:1556368539,AUTH,,,,,,
Sat Apr 27 14:35:39 2019 us=447758 TLS: Initial packet from [AF_INET]192.168.231.5:1194, sid=e18c73a5 83345369
Sat Apr 27 14:35:39 2019 us=447758 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Apr 27 14:35:39 2019 us=849977 VERIFY OK: depth=1, C=CH, ST=Xxxx, L=Yyyy, O=OPNsense, emailAddress=spam@test.com, CN=internal-ca
Sat Apr 27 14:35:39 2019 us=851462 VERIFY KU OK
Sat Apr 27 14:35:39 2019 us=851462 Validating certificate extended key usage
Sat Apr 27 14:35:39 2019 us=851462 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Apr 27 14:35:39 2019 us=851462 VERIFY EKU OK
Sat Apr 27 14:35:39 2019 us=851462 VERIFY X509NAME OK: C=CH, ST=Xxxx, L=Yyyy, O=OPNsense, emailAddress=spam@test.com, CN=VPN Server Certificate
Sat Apr 27 14:35:39 2019 us=851462 VERIFY OK: depth=0, C=CH, ST=Xxxx, L=Yyyy, O=OPNsense, emailAddress=spam@test.com, CN=VPN Server Certificate
Sat Apr 27 14:35:40 2019 us=558293 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Sat Apr 27 14:35:40 2019 us=558293 [VPN Server Certificate] Peer Connection Initiated with [AF_INET]192.168.231.5:1194
Sat Apr 27 14:35:41 2019 us=686135 MANAGEMENT: >STATE:1556368541,GET_CONFIG,,,,,,
Sat Apr 27 14:35:41 2019 us=686524 SENT CONTROL [VPN Server Certificate]: 'PUSH_REQUEST' (status=1)
Sat Apr 27 14:35:41 2019 us=692474 PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 192.168.235.1,topology net30,ping 10,ping-restart 60,ifconfig 192.168.235.6 192.168.235.5,peer-id 0,cipher AES-256-GCM'
Sat Apr 27 14:35:41 2019 us=693466 OPTIONS IMPORT: timers and/or timeouts modified
Sat Apr 27 14:35:41 2019 us=693466 OPTIONS IMPORT: --ifconfig/up options modified
Sat Apr 27 14:35:41 2019 us=693466 OPTIONS IMPORT: route options modified
Sat Apr 27 14:35:41 2019 us=693466 OPTIONS IMPORT: peer-id set
Sat Apr 27 14:35:41 2019 us=693466 OPTIONS IMPORT: adjusting link_mtu to 1624
Sat Apr 27 14:35:41 2019 us=693466 OPTIONS IMPORT: data channel crypto options modified
Sat Apr 27 14:35:41 2019 us=693960 Data Channel: using negotiated cipher 'AES-256-GCM'
Sat Apr 27 14:35:41 2019 us=693960 Data Channel MTU parms [ L:1552 D:1450 EF:52 EB:406 ET:0 EL:3 ]
Sat Apr 27 14:35:41 2019 us=694457 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Apr 27 14:35:41 2019 us=694953 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Apr 27 14:35:41 2019 us=694953 interactive service msg_channel=828
Sat Apr 27 14:35:41 2019 us=716280 ROUTE_GATEWAY 192.168.231.2/255.255.255.0 I=18 HWADDR=54:8c:a0:ac:b2:d3
Sat Apr 27 14:35:41 2019 us=718761 open_tun
Sat Apr 27 14:35:41 2019 us=727736 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{322A20D5-0A7D-4DAE-A181-61DA82ECA223}.tap
Sat Apr 27 14:35:41 2019 us=728222 TAP-Windows Driver Version 9.21
Sat Apr 27 14:35:41 2019 us=728222 TAP-Windows MTU=1500
Sat Apr 27 14:35:41 2019 us=734134 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.235.6/255.255.255.252 on interface {322A20D5-0A7D-4DAE-A181-61DA82ECA223} [DHCP-serv: 192.168.235.5, lease-time: 31536000]
Sat Apr 27 14:35:41 2019 us=735126 Successful ARP Flush on interface [5] {322A20D5-0A7D-4DAE-A181-61DA82ECA223}
Sat Apr 27 14:35:41 2019 us=758934 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat Apr 27 14:35:41 2019 us=758934 MANAGEMENT: >STATE:1556368541,ASSIGN_IP,,192.168.235.6,,,,
Sat Apr 27 14:35:46 2019 us=894876 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Sat Apr 27 14:35:46 2019 us=894876 MANAGEMENT: >STATE:1556368546,ADD_ROUTES,,,,,,
Sat Apr 27 14:35:46 2019 us=895372 C:\Windows\system32\route.exe ADD 192.168.1.0 MASK 255.255.255.0 192.168.235.5
Sat Apr 27 14:35:46 2019 us=900331 Route addition via service succeeded
Sat Apr 27 14:35:46 2019 us=900331 C:\Windows\system32\route.exe ADD 192.168.235.1 MASK 255.255.255.255 192.168.235.5
Sat Apr 27 14:35:46 2019 us=907276 Route addition via service succeeded
Sat Apr 27 14:35:46 2019 us=907765 Initialization Sequence Completed
Sat Apr 27 14:35:46 2019 us=907765 MANAGEMENT: >STATE:1556368546,CONNECTED,SUCCESS,192.168.235.6,192.168.231.5,1194,,


Könnte da was faul sein?

Was noch zu erwähnen ist, dass ich im Firewallog Traffic sehe, jedoch im VPN-Log des Servers absolut nichte ersichlich ist:

Etwas weiteres ist mir noch aufgefallen:

Wenn ich den UDP-Server konfiguriere und mit netstat -ln die Ports abfrage erhalte ich:

root@OPNsense:~ # netstat -ln
Active Internet connections
Proto Recv-Q Send-Q Local Address                                 Foreign Address                               (state)
tcp4       0      0 192.168.1.1.443                               192.168.1.100.62225                           ESTABLISHED
tcp4       0     64 192.168.1.1.22                                192.168.1.100.62205                           ESTABLISHED
udp4       0      0 192.168.231.5.1194                            *.*
udp4       0      0 192.168.235.1.123                             *.*
...


Hier sehe ich, dass auf Port 1194 gehört wird.

Wenn ich jedoch den TCP-Server konfiguriere, dann hört niemand auf dem Port 1194!

Das ist doch auch nicht normal, würde jedoch erklären, wieso im TCP-Fall im VPN-Log nichts zu sehen ist...

Ich weiß nicht genau, wie FreeBSD da tickt. Wäre nicht das erste Mal, das netstat -ln da nix anzeigt (zumindest bei mir). Ich mache da lieber bei tcp ein Telnet auf den Port.
Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz (24 cores)
256 GB RAM, 300GB RAID1, 3x4 10G Chelsio T540-CO-SR

Ich hab mal mit nc auf 1194 versucht zu connecten (TCP und UDP). Im Firewallog sehe ich den Traffic, kommt aber keine Antwort zurück. Ist das normal?