Messages

Hallo zusammen

Problem gelöst!  :)

Lösung siehe Thread: https://forum.opnsense.org/index.php?topic=12779.0

Gruss Luma

[Advanced Option "disable reply-to"]

Guten Morgen zusammen

Problem gelöst! Danke allen für die guten Tips! ;D :D ;D

Die Lösung von micneu klappt auch, (wir hatten noch privat Kontakt) Danke!  :)

Doch die Lösung, die ich eigentlich angestrebt habe fand ich durch den Tip von Ric: Ich habe nun eine Regel für das WAN-Interface erstellt, die genau auf den SSH-Port und die source IP passt und die Advanced Option "disable reply-to" aktiviert. Und siehe da, der Zugriff klappt. Auch für den Weg-Gui Zugriff geht das (mit entsprechender Regel für den Web-GUI-Port).

Mein eigentliches Problem, einen VPN-Zugriff via TCP zum laufen zu bringen (siehe Thread https://forum.opnsense.org/index.php?topic=12475.0) habe ich hiermit auch gelöst - was lange währt wird endlich gut! Danke Ric!  :D
Somit kann ich den Zugrif auf das Web-GUI sowie den SSH Zugriff auf OPNsense nun auch via VPN machen!

Die Einstellung "Firewall / Settings / Advanced / Disable force gateway" hat leider nichts gebracht, trotzdem Danke Maurice.

Nochmals Danke an alle und Gruss aus der Schweiz
Luma

Da ist noch ein Switch dazwischen, hab die Grafik aktualisiert.    :-)

Den LTE Router hab ich nur der Vollständigkeit halber erwähnt. Ich will ja vom Client 192.168.231.10 auf OPNsense zugreifen und das geht ja nicht!

Damit es verständlicher ist:

Code Select Expand


      WAN / Internet
             :
             :
      .------+------.
      | LTE Router  |
      '------+------'
     IP 192.168.231.2
             |
             |
       .-----+------.          .-----------------------.
       |   Switch   +----------+ Client 192.168.231.10 |  (von diesem Client klappt der Zugrif auf OPNsense nicht!)
       '-----+------'          '-----------------------'
             |
             |
    WAN IP 192.168.231.5
      .------+-------.
      |   OPNsense   |
      '------+-------'
     LAN 192.168.1.1/24
             |
             |
  .----------+-----------.
  | Client 192.168.1.101 |  (von diesem Client klappt der Zugrif auf OPNsense!)
  '----------------------'


Sorry, wenn ich das ungenau beschrieben habe...

Aus dem LAN (vom Client 192.168.1.101 auf OPNsense LAN-Adresse 192.168.1.1) klappt der OPNsense-Web-GUI Zugriff (Port 80) und der OPNsense-SSH-Zugriff (Port 22).

Aus dem WAN (vom Client 192.168.231.10 auf OPNsense WAN-Adresse 192.168.231.5) klappt dasselbe nicht.

Hi Ric

Ich verstehe nicht ganz, was ein Zugriff vom WAN-Interface mit einer Regel im LAN-Interface zu tun hat. Was meinst du genau? Was müsste ich definieren? Und wieso Port 443, mein Web-GUI läuft auf Port 80?

Aus dem LAN klappt Web-GUI und SSH. Nur aus dem WAN geht nichts.

Gruss Luma

Hallo zusammen

Ich habe OPNsense mit 2 Interfaces neu aufgesetzt:
- LAN: 192.168.1.1


- WAN: 192.168.231.5


Web-GUI läuft auf Port 80, SSH-Server auf Port 22. Beide hören auf allen Interfaces. Soweit klappt alles, Web-GUI und SSH-Zugriff vom LAN funtioniert.

Eigentlich sollte doch auch die Web-GUI und der SSH-Zugriff vom WAN Interface klappen. Dies geht aber leider nicht.

Folgende Regel ist definiert:


Wenn ich einen Zugriff (Web-Gui oder SSH) vom der IP 192.168.231.10 auf die WAN-Adresse (192.168.231.5) mache, sehe ich dies auch im Firewall-Log:


Aber leider bekomme ich keine Antwort.

Woran kann das liegen? Was ist hier falsch?

Danke für die Hilfe.
Gruss Lumax.

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?

Etwas weiteres ist mir noch aufgefallen:

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

Code Select Expand

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

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

Hi hbc

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

Code Select Expand

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?

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:

Code Select Expand

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

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

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