Menu

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.

Show posts Menu

Messages - Ramalama

#1
24.1, 24.4 Legacy Series / Re: Kea DHCP IPv6?
March 14, 2025, 11:28:37 PM
After working on another Projects with Kea, i do agree with franco.
Most features that are mandatory are paid features, a lot is not supported and the raw and the udp socket is pure crap on linux.
The one doesnt work with vlans the other works with vlans but has issues with dhcp forwarders from the switch.
We got it working with rewriting dhcp packetheaders on our Core-Switches.

However its a shitmess with Kea, isc-dhcp worked absolutely perfect in every constellation, dhcp registration worked flawlessly and it was super easy to add dhcp options.

On Kea even dhcp registration in combination with powerdns is a mess, it works 99% but sometimes clients doesnt get registred or removed.

However we had no choice.
The ONLY nice feature of Kea is actually HA, nothing else.

Kea writes a lot of "Performance" on their Pages, but the real Performance of Kea is the worst ive seen. Even isc-dhcp is delivering clients an ip-address faster.
And dnsmasq is compared to Kea, lightspeed.

The Development of Kea is utterly slow either, nothing changes, no new features, its even impossible so search for leases with wildcards etc in stork.
Basically you have to know the exact ip or mac-address to search though leases. You cant even list all leases.
So its completely senseless.

The paid plugins are horribly expensive either and without them kea is almost useless tbh.

However, the only nice feature is HA, otherwise Kea is basically crap in my opinion that we are forced to use for the moment.

Cheers
#2
Kea is the last crap, like stork, stork is even worse. (Stork is the useless dhcp gui for kea, where you cant even see leases)

Whatever isc is doing, is just money oriented now, the good old days of isc-dhcp are gone.
I would recommend you to stick with the old isc-dhcp.

In short, Kea is not stable and a half working solution.
You cannot do with Kea duplicate ip reservations. But thats a very minor issue if you ask me.

Much worse, is that Kea Raw socket is broken, cause it cannot destinquish from which network the IP address comes from, that means that you cannot use Kea if you have multiple vlans/multiple subnets, unless you have an udp-relay/ip helper/dhcp relay

The UDP-Socket on other hand, is broken either, cause it cannot listen for broadcast dhcp requests.

Thats all a no issue with the old isc-dhcp server, so stick with it as long as possible. At this time, kea has no benefits, not even performance benefits.

Cheers
#3
Hey, 3.8.4 is the last one that works, just fyi
#4
Was für ein Schwachsinn.
Es ist absolut egal wo mann das vlan Tag setzt.

Eher ein Vorteil auf dem vigor direkt zu setzen, da das erlaubt das mann die pppoe Verbindung zum vigor selbst über ein vlan tunnelt.

Outbound nat braucht mann sowieso in jedem fall, wenn mann beim Gerät (aka vigor) keine routen setzen kann oder will.

Hat jemand schon ne Lösung zum 3.8.4+ Firmware Problem gefunden?

- Seltsamerweise funktioniert der vigor 167 mit neuester FW+opnsense
- vigor 130 (3.8.5.1) funkt auch mit unifi hier... Funkt mit allem außer opnsense 😂

Irgendwas ist da echt komisch 😂
#5
This is pretty old, but you need to disable spoofchk simply in the driver.

I don't know how to do this in freebsd, but on Linux it's simply "ip link set enp35s0f0 vf 0 vlan 0 spoofchk off"
vlan=0 disables vlan filtering on the vf device, which you need if you use one vf with multiple vlans. And disabling spoofchk is probably not needed if you disable vlan filtering, but i would do it anyway.

But if you split anyway your pf to multiple vf devices, why not making simply 5 vf devices for example, one for each vlan?
Then you won't need to diable spoofchk or vlan filtering, but you need to tell the driver which vf uses what vlan.
In linux that would be:
ip link set enp35s0f0 vf 0 vlan 25
ip link set enp35s0f0 vf 1 vlan 26
ip link set enp35s0f0 vf 2 vlan 27
and so on...

However, i don't know the freebsd commands for that, but at least that's hopefully a step forward to a solution.
And yes this thread is very old, but in case someone needs that info, then there is at least a solution and not just an useless thread.

Cheers
#6
Super old post, just seen 😂

However, im running opnsense as vm on Proxmox with an VF passed through.
The card is an X550-T2 which is onboard (asrock rack x570d4i-2t)

- A year ago, i had to use own compiled VF drivers from intel for Freebsd, because of some errors/performance/functionality i needed.

- Since opnsense 23?, im sorry i don't know exactly when it started to work flawlessly without my drivers or any modifications, but it's running absolutely flawless and everything works!
Vlans on top of the vf device works either without issues, even all hardware acceleration.
You just need spoochk=off and trust=on and in some cases set vlan=0 for the vf device in proxmox.
Basically vlan=0 deactivates vlan filtering, trust=on allows mac address changes and promiscuous and spoofchk=off is needed if you don't disable vlan filtering with vlan=0 and you use multiple vlans on the vf device not just one.

You can set only one vlan for an vf device, not multiple trunk vlans etc...
If you want spoofchk and hardware vlan filtering working, you need to passthrough multiple vf devices to opnsense, one for each vlan and assign all the vlans to vf devices accordingly with "ip link set enp35s0f0 vf 1 vlan 25" for example... And so on...

But anyway keep in mind, if you use the same primary function where you passthrough your vf and on the same primary function is a linux bridge "vmbrX" bound, you'll need to modify fdb tables.

For that reason i switched lately to passthrough the whole primary function to opnsense, because i have anyway 2 of them and if i use one 10gbe cable or 2 to the switch, doesn't matter for me.

The fdb table modification is easy tho, there are even automated scripts in proxmox forum for that...
It works good, but in my opinion it's easier for my specific situation to simply pass the pf.

However, the point is, VF works perfectly fine in opnsense nowadays.
So if you need it, do it!
#7
Hi, IPv6 nervt und ist auch irgendwie undurchdacht, oder ich komme einfach nicht klar damit.
Folgendes ist mit IP4 gar kein problem:
- Server Vlan: 25 -> 192.168.25.0/24
- User Vlan: 27 -> 192.168.27.0/24
Jetzt sind im "User Vlan" die clients, die bekommen auch alle über dhcp gesagt, die sollen den dns server (192.168.25.254) von "Server Vlan" benutzen...

Alles easy, gar kein problem, ip adresse ändert sich ja nicht, funkt halt alles 1a...

Jetzt aber IPv6...
Wegen PPPoe Prefix delegation, bekomme ich in beiden Vlans richtige ipv6 adressen, sprich z.b.
- Server Vlan: 25 -> 2003:e900...../64
- User Vlan: 27 -> 2003:e901...../64

Ich kann auch zwischen beiden Vlans alles pingen und alles funkt etc...
Aber diese kak adressen ändern sich halt, weil der provider (Telekom), je nach laune mir andere adressen zuweist...
Somit sind die IPv6 adressen halt nicht fest...
Die fe80 adressen sind zwar fest, aber die sind nur local, sprich nicht netzwerkübergreifend, von daher geht vlan routing mit denen sowieso nicht.

Also wie zum teufel definiert mann seinen eigenen dns server über dhcp (ipv6 technisch)?
Alles was mir bleibt ist unbound in opnsense zu benutzen als forwarder zum dns server. Da link-local natürlich von opnsense von jedem netz erreichbar ist (da opnsense in jedem netz halt ein interface hat)

Kann mir das jemand bitte erklären, wie ihr das macht?

Danke und LG!