OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of meyergru »
  • Show Posts »
  • Messages
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

  • Messages
  • Topics
  • Attachments

Messages - meyergru

Pages: 1 ... 111 112 [113] 114 115 ... 118
1681
22.1 Legacy Series / Re: IPv6: how to have an interface track itself?
« on: May 03, 2022, 10:20:35 pm »
The IPv6 selection for outgoing connections is very simple: Use the outgoing interface's address if available, otherwise choose a "preferred" address (in OpnSense you can select that, but not with a dynamic prefix) or, as a last resort, choose the lowest routable IPv6 address in the system.

That way, you can actually use the LAN address by just choosing a "track6" prefix for the LAN address as the lowest one for all local interfaces. The lower 64 bits can be chosen via the MAC address.

That is how I do it. Also, I use a DynDNS service that only updates the /56 prefix of the entry with the dynamic prefix. I already know the lower 72 Bits set that manually. Together with dynamic IPv6 prefix aliases in OpnSense, I can reach whatever I like - even LAN clients, the only thing that is different there is the lower 72 Bits.
 

1682
German - Deutsch / Re: Betrieb OHNE PPPoE Passthrough ?? OPNSense only
« on: May 03, 2022, 10:10:46 pm »
Letztlich läuft es darauf hinaus, welche Form der Anbindung, also physisch: GPON, DSL o.ä. und logisch (z.B. PPPoE oder DHCP) der Provider anbietet.

Da in Deutschland grundsätzlich "Routerfreiheit" besteht (tatsächlich meint das so sogar das Recht auf passiven Netzwerkübergabepunkt), sind die Provider verpflichtet, eine technische Schnittstellenbeschreibung herauszugeben, aus der hervorgeht, wie Du den Anschluss machen kannst. Danach solltest Du fragen.

Andererseits ist das für den Einsatz von OpnSense letztlich egal, weil es die üblichen Anschlussarten "kann".
Eine Fritzbox benötigt man selbst bei DSL nicht, es gibt ja reine DSL-Modems. Auch muss man den GPON-ONT des Providers nicht akzeptieren, nur wüsste ich nicht, weshalb nicht, wenn der gratis zur Verfügung gestellt wird.

1683
22.1 Legacy Series / Re: Wireguard not reconnecting when remote IP change
« on: May 03, 2022, 08:35:44 pm »
Look here: https://github.com/opnsense/plugins/pull/2956

1684
German - Deutsch / Re: Firewall Inter VLAN einzelner port
« on: May 03, 2022, 01:09:40 am »
An die Geschichte mit dem Routing hatte ich noch gar nicht gedacht, mein Verdacht für den out-of-state traffic war eher eine fehlerhafte/unvollständige Implementierung des TCP-Stacks auf Embedded Hardware, so was kommt bei MQTT ja schon mal vor.

Könnte es sein, dass da eine zu weit greifende NAT-Regel feuert und die Absenderadressen vom VLAN 20 ins LAN verbiegt?

1685
German - Deutsch / Re: Firewall Inter VLAN einzelner port
« on: May 01, 2022, 05:20:04 pm »
In der Theorie könnte jemand jetzt TCP-Pakete vom VLAN 20 (vermutlich IoT-Netz?) ins LAN außer der Reihe senden, aber wie wahrscheinlich ist das schon?

Man könnte durch Paket-Traces nachvollziehen, was die MQTT-Clients genau falsch machen und nur dies zulassen, um das weiter einzugrenzen, aber das Risiko ist doch sehr begrenzt.

1686
German - Deutsch / Re: Firewall Inter VLAN einzelner port
« on: April 30, 2022, 06:41:44 pm »
Ich würde mal mit "state type" spielen...

1687
German - Deutsch / Re: Firewall Inter VLAN einzelner port
« on: April 30, 2022, 06:18:54 pm »
Schau Dir mal die Details der geloggten Pakete an, es könnte sein, dass die TCP-Flags nicht passen, speziell, wenn die MQTT-Devices fehlerhaft implementierte Stacks haben. Dann könnte man mit advanced options diese Pakete auch durchlassen (oder filtern und ohne Logging wegwerfen).

1688
22.1 Legacy Series / Re: IPv6: how to have an interface track itself?
« on: April 30, 2022, 05:38:51 pm »
The short answer is: You currently cannot track a WAN interface and have it assign a prefix to itself.

The way OpnSense works is that it uses dhcp6c to request an IPv6 address. Normally, the ISP will give you both an address for the WAN interface and a prefix for local interfaces, but some ISPs do not, they hand out only prefixes, such that you end up with no IPv6 assigned to the WAN interface.

The setting "track interface" and "dhcpv6" are mutually exclusive, such that you cannot use radvd to assign an IPv6 prefix to the same interface it originated from.

Franco tried to implement this in dhcp6c to make it possible, but development has stopped: https://github.com/opnsense/core/issues/5630#issuecomment-1110602631

What you can do is to use any LAN address because IPv6 addresses are arbitrary and do not have to be on the WAN interface at all (see https://forum.opnsense.org/index.php?topic=27483.0). There is a new type of alias for this: https://docs.opnsense.org/manual/aliases.html#dynamic-ipv6-host

As I see, you already did that. The assignment on the loopback interface will not work because radvd needs a MAC address on the interface where it assigns the IPv6 prefix. This was part of the reason that the fix Franco attempted did not work, either.

But why does your LAN interface go down at all? Isn't it connected to a switch? Could you use a bridge on top of it that stays up even when the physical interface is down?

1689
General Discussion / Re: Firewall blocking strange local IP on port 68
« on: April 29, 2022, 05:10:48 pm »
Seems like you have a DHCP server running on 192.168.20.1. To investigate, you could configure a machine statically to that subnet and try to scan that IP. You should be able to see the MAC and potentially more, if a web interface is offered.

1690
22.1 Legacy Series / Re: Intel i225 now supported in 22.1?
« on: April 29, 2022, 05:01:45 pm »
It runs fine here with a few caveats w/r to power draw and heat dissipation (https://www.congenio.de/infos/opnsense-hardware.html).

I did not use 2.5 GBit/s, but with 1 GBit/s, I get the expected results:

Code: [Select]
#iperf3 -c 192.168.1.9
Connecting to host 192.168.1.9, port 5201
[  5] local 192.168.10.3 port 36008 connected to 192.168.1.9 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   114 MBytes   956 Mbits/sec  837    266 KBytes
[  5]   1.00-2.00   sec   112 MBytes   944 Mbits/sec  763    269 KBytes
[  5]   2.00-3.00   sec   112 MBytes   938 Mbits/sec  674    272 KBytes
[  5]   3.00-4.00   sec   112 MBytes   938 Mbits/sec  660    249 KBytes
[  5]   4.00-5.00   sec   112 MBytes   942 Mbits/sec  717    208 KBytes
[  5]   5.00-6.00   sec   113 MBytes   949 Mbits/sec  1107    252 KBytes
[  5]   6.00-7.00   sec   111 MBytes   931 Mbits/sec  803    257 KBytes
[  5]   7.00-8.00   sec   112 MBytes   939 Mbits/sec  1126    257 KBytes
[  5]   8.00-9.00   sec   112 MBytes   941 Mbits/sec  1047    260 KBytes
[  5]   9.00-10.00  sec   112 MBytes   939 Mbits/sec  1091    255 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.10 GBytes   942 Mbits/sec  8825             sender
[  5]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec                  receiver

iperf Done.

But you said you wanted two ports for clients - I assume you are using a bridged configuration? There seem to be some issues around that with 22.1.

1691
German - Deutsch / Re: Rückfragen Netzwerkplanung
« on: April 25, 2022, 10:45:03 am »
Ja, das ist immer noch so, ich habe es inzwischen nachgesehen.

Ich habe einen Pull Request eingestellt, mit dem man zukünftig einen Cron-Job für die Aktualisierung nutzen kann:

https://github.com/opnsense/plugins/pull/2956

1692
German - Deutsch / Re: Rückfragen Netzwerkplanung
« on: April 24, 2022, 11:29:27 pm »
Quote from: Ducksoul on April 24, 2022, 09:09:39 pm
Der Tipp auf WireGuard zu setzen entspricht auch meinem bisherigen Bauchgefühl welche VPN-Lösung ich einsetzen möchte. Ich frage mich allerdings ob die Lösung via DynDNS der richtige Weg ist. Hintergrund: Neben Site-To-Site plane ich auch ein User-VPN.

Bei WireGuard habe ich diesbezüglich das Problem gehabt, dass der Host nur zum Zeitpunkt des Tunnelaufbaus aufgelöst wird. Habe ich nun bspw. von einem mobilen Endgerät aus das VPN aufgebaut und die lokale WAN-Adresse ändert sich, führt dies zu einem Abbruch im Tunnel (trotz DynDNS), welcher erst durch einen neuen manuellen Verbindungsaufbau behoben werden kann.

Ich weiß nicht, ob das Wireguard-Problem mit der DNS-Auflösung noch existiert oder ob bei Abbruch der Verbindung neu aufgelöst wird.

Beim User-VPN hast Du das Problem mit der neuen IP ja weniger, weil die Verbindung mutmaßlich nur temporär aufgebaut wird. Bei Site-2-Site wird die Verbindung ja von jeder Seite aus aufgebaut. Derjenige, der wegen Abbruch der Verbindung eine neue IP bekommt, wird ja (hoffentlich) den Wireguard neu starten, so dass es keine Rolle spielt, ob die Gegenseite bei unveränderter eigener IP neu auflöst.

VPS geht natürlich, kostet aber extra, wenn man nicht sowieso einen hat. Außerdem erhöht es die Latenz und verringert ggf. den Durchsatz.

1693
22.1 Legacy Series / Re: Clients don't get an IPv6 address
« on: April 23, 2022, 01:30:41 am »
Since the error occured in rc.bootup, I would think that at boot time, the WAN was not up, so that no IPv6 prefix was assigned at that time. I see that same message for multiple interfaces, but only at boot time.

1694
German - Deutsch / Re: Am WAN-Anschluss kein Internet (Gateway?)
« on: April 22, 2022, 12:31:17 pm »
Mit CGNAT hast Du Recht, allerdings kann ich inzwischen auf IPv6 gar nicht mehr verzichten, weil mehr und mehr Gegenstellen nur noch per IPv6 erreichbar sind (Beispiel Deutsche Glasfaser, genau wegen CGNAT). Bei den von mir verwendeten ISPs wechseln aber auch die IPv6-Präfixe maximal bei Neueinwahl (teilweise nicht mal dann).

Ein weiteres Problem ist nach meiner Beobachtung, dass die Fritzbox effektiv den Durchsatz hemmt, wenn die Leitung Gigabit-Glasfaser ist - eine potente OpnSense hilft dann dahinter auch nicht mehr. Einer meiner Gründe für Einsatz von OpnSense ist z.B. die Vermeidung von Bufferbloat, den ich mit der Fritte immer hatte.

Ich gestehe allerdings, dass ich keine Erfahrung mit doppeltem Router habe, weil ich diesen Schwierigkeiten möglichst aus dem Weg gehen wollte. Und wie gesagt, eine FB hinter der OpnSense funktioniert auch ohne Probleme, genauso wie andere SIP-Telefone, die man eventuell im WLAN betreibt, um z.B. auf Sipgate oder Fonial zuzugreifen. Und da hat man nicht so einfach die Wahl, die vor der Firewall zu betreiben.

1695
German - Deutsch / Re: Am WAN-Anschluss kein Internet (Gateway?)
« on: April 22, 2022, 11:58:30 am »
Wie gesagt, die FB hinter der OpnSense ist vglw. einfach. Bei der Variante FB vor OpnSense setzt das Öffnen von Ports voraus, dass diese auch auf dem vorgelagerten Router geöffnet werden (oder dass die OpnSense "exposed host" ist).

Ganz zu schweigen von IPv6.

Pages: 1 ... 111 112 [113] 114 115 ... 118
OPNsense is an OSS project © Deciso B.V. 2015 - 2024 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2