Messages

Hallo pmhausen,

danke Dir, die Oberfläche von dem Vigor 130 sieht etwas anders aus aber vermute mal die Einstellungen werden ähnlich sein.

Frohe Weihnachten und einen guten Rutsch!
Hovy

Allerdings lasse ich immer den Vigor das VLAN Tag setzen.

Ahh, ich denke genau daran wird es liegen, dadurch ändert sich ja einiges an den Firewall-Regeln und soweit ich weiß ist das Wireguard-Go Plugin nur Userspace, das führt natürlich zu weiteren Einschränkungen.


Ich bin seit über 20 Jahren nicht mehr bei der Telekom und die Modems die ich bisher hatte, hatten alle immer direkt PPPoE unterstützt.

Könntest du mir vllt einen Screenshot machen wie du es konfiguriert hast in deinem Vigor 130? Nur um sicher zu gehen? Ich kann da leider gerade nur remote auf die Infrastruktur zugreifen und müsste dann vllt jemanden anweisen das so einzustellen.

LG
Hovy

Klar, gerne.

Ich bin im wesentlichen diesem Tutorial gefolgt: https://www.thomas-krenn.com/de/wiki/OPNsense_WireGuard_VPN_f%C3%BCr_Road_Warrior_einrichten#

Ich habe bei mir zuhause selbst ein ähnliches Setup aber bei einem anderen Provider. In dem Fall um den es hier geht wird ein DrayTek Vigor 130 Modem zur Einwahl bei der Deutschen Telekom verwendet. Dafür musste ich leider ein VLAN für das WAN Interface anlegen das die VLAN ID 7 hat. Dadurch sind die Regel für WAN hier auf das VLAN Interface "DrayTekTKom" angewendet worden.

Netzplan
https://ibb.co/vh3LT6j

VLAN Interface für Telekom Einwahl
https://ibb.co/X32C1V8

WG Local Config
https://ibb.co/TRDbSnZ

WG Endpoint Config
https://ibb.co/6RDbqBY

Firewallregeln VLAN
https://ibb.co/cyLgBGs

Firewall Regeln WG Interface [mehr aus Verzweifelung weil ich keine Lösung finde]
https://ibb.co/NFBMqrx

Firewall Regeln WG (Group) [mehr aus Verzweifelung weil ich keine Lösung finde]
https://ibb.co/t3bSYk5

Firewall Regeln WAN [Als Test als ich keine Lösung fand]
https://ibb.co/98KGK6J

Das seltsame ist das ich noch nicht mal einen Handshake laut Wiregurad log kriege aber z.B. die ICMP Regel im WAN VLAN einwandfrei funktioniert wenn ich sie aktiviere. Ich wundere mich etwas da ich ein ziemlich ähnliches Setup hier zuhause habe und auch schon anderorts aufgesetzt habe. Aber noch nie auf einer Telekom Leitung, diese hat sogar eine statische IP und einen TLD subdomain der auf diese zeigt.

Auch die Client configs sind an sich jetzt nicht besonders.

Code Select Expand

[Interface]
Address = 10.1.0.4/32
PrivateKey = [cut]

[Peer]
PublicKey = [cut]
AllowedIPs = 10.1.0.0/24, 192.168.59.0/24, 192.168.9.0/24
Endpoint = gw.domain.de:51820

In dem Thread hier ging es ja darum das es scheinbar ein Problem mit den CRC Checks oder den MTUs gibt bei Wireguard und einem ähnlichen Setup. Frage ist halt ob das hier ein Bug ist oder ich Tomaten auf den Augen habe.  Initial hatte ich es intuitiv genau so wie in dem oben geschriebenen Tutorial gemacht. Nur eben mit dem VLAN Interface von für das WAN. Kann es sein das es ein generelles Problem mit T-Kom Setup mit Vigor 130 Modem und Wireguard gibt?

Hovy

Edit: Mit OpenVPN habe ich es noch nicht probiert ich war jetzt erstmal irritiert warum es mit Wiregurad nicht geklappt hat.

Mittlerweile habe ich noch ein WG Interface für das von dem wireguard-go plugin angelegem Interface angelegt und hier einen Zugriff zu allen Netzen erlaubt (inkl. sich selbst) aber ich kann gar nicht erst eine Verbindung aufbauen.

Hallo MenschAergereDichNicht!

Kurze Frage hast Du es noch hinbekommen? Ich habe scheinbar das gleiche oder ein ähnliches Problem.

Ich habe ein Wireguard Setup für die kleine Firma von einem Bekannten eingerichtet, ich habe es genauso gemacht wie hier in der Anleitung: https://www.thomas-krenn.com/de/wiki/OPNsense_WireGuard_VPN_f%C3%BCr_Road_Warrior_einrichten

Allerdings erfuhr ich dann vor Ort, dass eine Telekom DSL Leitung mit einem DrayTek Vigor 130 zum Einsatz kommt. Hier kann man sich nur per PPPoE einwählen, wenn man für das WAN Interface ein VLAN mit dem Tag 7 anlegt. Das war mir vorher so nicht bewusst und hat mir mein remote Administrations-Konzept etwas zerrissen. Ich bekomme es auf absolut nicht hin eine Wiregurad Verbindung zur OPNsense aufzubauen. Erst dachte ich es liegt an meinen Firewall-Regeln (die müssten ja analog zur Anleitung sein nur eben für das angelegte VLAN statt dem WAN Interfacce) aber daran scheint es nicht zu liegen. Mit den MTUs hatte ich jetzt wegen deinem Posting auch noch mal probiert, derzeit habe ich auf dem pppoe-vlan 1492 und für WG 1432. Ebenso mit dem Hardware CRC offloading, das ich auch deaktiviert habe.

Aber wirkt alles nicht und ich sehe das Problem jetzt nicht so ganz.

LG
Hovy

Thanks for the explanation, I  thought that this is the problem. However, this is the first time I have received this message since I started using OPNsense. Wouldn't it make sense to exclude the paths from the package or find another workaround?

I think this can be understood as a bug.

Hovy

Code Select Expand

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 22.7.7_1 (amd64/LibreSSL) at Thu Nov 10 18:48:17 CET 2022
>>> Check installed kernel version
Version 22.7.7 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 22.7.7 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense
>>> Check installed plugins
os-acme-client 3.14
os-dyndns 1.27_3
os-theme-rebellion 1.8.8
os-wireguard-devel 1.13
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: ........
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/io.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/os.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/posixpath.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/re.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/site.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/stat.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/threading.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/token.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/tokenize.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/traceback.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/types.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/typing.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/uu.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/warnings.cpython-39.pyc
python39-3.9.15: checksum mismatch for /usr/local/lib/python3.9/__pycache__/weakref.cpython-39.pyc
Checking all packages..... done
>>> Check for core packages consistency
Core package "opnsense" has 63 dependencies to check.
Checking packages: ................................................................. done
***DONE***

Maybe a good issue to report...

Hello Folks,

just had a look on the SSH service default configuration and was wondering why it supports so may outdated key, kex and mac algorithms.

Why not hardening it?

Code Select Expand


$ ssh-audit opnsense
[...]
# algorithm recommendations (for OpenSSH 8.0)
(rec) -diffie-hellman-group14-sha1          -- kex algorithm to remove
(rec) -diffie-hellman-group-exchange-sha256 -- kex algorithm to remove
(rec) -ecdh-sha2-nistp256                   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp384                   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp521                   -- kex algorithm to remove
(rec) -ecdsa-sha2-nistp256                  -- key algorithm to remove
(rec) -hmac-sha1                            -- mac algorithm to remove
(rec) -hmac-sha2-256                        -- mac algorithm to remove
(rec) -hmac-sha2-512                        -- mac algorithm to remove
(rec) -umac-64@openssh.com                  -- mac algorithm to remove
(rec) -umac-128@openssh.com                 -- mac algorithm to remove
(rec) -hmac-sha1-etm@openssh.com            -- mac algorithm to remove
(rec) -umac-64-etm@openssh.com              -- mac algorithm to remove


The argument is probably backwards compatibility, but I thought OPNsens is the firewall for the paranoid ones ;)

Maybe not like here, but in general

Best Regards,
Hover

In 19.7 still this isn't fixed... :-[

Did someone open a bug report via github?
I have around 20 OPNsense Firewalls on most common versions of ESX, HV, KVM, also Hardware. Never had such an issue.

I have the same issue here but with a PCE APU2 Board, everything vanilla expect the new coreboot 4.10.0.1 Bios.

I'm running OPNsense 19.7.4_1-amd64. But this issue only happens on the WebGUI if I use opnsense-update via ssh everything works fine!

Best Regards

Hey OPNsense forum,

Im pretty new her and new to OPNsense and pf as packet filter. I running a PC-Engines APU2 board for my OPNsense setup.
It divides my home office LAN from my private LAN like this:

https://pastebin.com/RYJbjsP0

       
I configured the OPNsense box to do NAT for my private and for Office LAN. I also installed WireGuard on OPNsense so the box can act as an VPN Endpoint.

What I want to do is to setup a second gateway on the OPNsense (10.0.2.254) on the LAN interface and an gateway (10.0.0.254) on the OpenWRT box so the clients can decide if they want to tunnel all their traffic via WireGurad by using the 0.254 gateway or direct internet connection on the 0.1 gateway.

Under Linux this is easy; add an eth0:x device give it a different IP address. The rest can be handled using ip / iprout2 to manage that the the second gateway uses 10.0.2.254 as gateway and this gateway should tunnel everything through 10.0.1.1 to the internet.

I tried to set up things but ended up in somehow breaking (web interface wasn't starting anymore, could not ping 10.0.2.1 anymore)  the configuration of the LAN interface on the OPNsense box, by adding a VLAN to the igb0 interface and giving that VLAN interface a different mac address.

I'm not sure how to achieve what I want on the OPNsense (Hardnend BSD) using the web interface or if there is a problem with my NIC drivers (Intel i210AT)  I have to admit.

I'm running the 19.7 version of OPNsense, because I want to run a WireGuard instance

Can some here help me on fixing my problem.

Best regards,
Hover