Messages

Snapshot geht aber nur, wenn das VMs sind... auf Hardwaare geht das nicht so einfach ;)

Habe zwei Kisten (HW) hier vor kurzem aktualisiert. Als Vorbereitung bin ich von ISC DHCP auf KEA DHCP (v4 only) umgestiegen. Update lief problemlos. Nur bei einer Kiste ist der Kea nach dem Update nicht gestartet. Hatte wohl irgendwie ein Interface namens usb0 in der Konfig. Habe dem dann ein Interface weggenommen, gespeichert, Interface wieder hinzugefügt, gespeichert- lief!

Beim zweiten gab es keine Probleme!

/KNEBB

Hi,

I just migrated from ISC to KEA. It was smoothless.

Configured basic things like DNS and NTP.

On the ISC top left of the static lease list (looks like a calc sheet) to export the configured static leases.
In KEA import the csv as reservations and it worked out of the box!

I had some understanding problem with the default gateway- but this is taken from the interface address on OPNSense.

/KNEBB

Ok, re-read the specs and can confirm the above offered "delete the ip on server" appears to be working. Although with a minor inconvinience:

For the server the IP is not assigned while it is still in use by the client.
So what happens when another client requests an IP address?
-client A has IP .12 and its leases got deleted on the server side
-client A still uses this IP as long as half of lease time hast not elapsed
-client B starts DHCPDISCOVER to get an IP
-server offers IP .12 to client B as it is marked as available
-client B sends an ARP request to check the IP
-client A sends ARP reply ("this is my IP")
-client B send DCHPDECLINE to server
-server marks this IP as "invalid" for further usage
-client B starts over with DHCPDISCOVER
-server offers different IP .13 to client B and client B uses this one...
-on the client A when half lease time has elapsed it'll ask for further usage of IP .12
-server declines further usage (as it is marked invalid) with DHCPNACK
-client A starts over with DHCPDISCOVER and will get a different IP .14

So indeed the protocol is fail-safe and you can delete a lease on the server side without any friction in the network.

The minor glicht I mentioned is the fact there is an IP address in use which (for the server) has not bee assigned. At least for half of lease time.
And this is not reflected in the server state...

And there is a second problem:
The IP will not be release or renewed before half of the lease time has passed. So when using a static lease for this client it will use the IP not earlier. And this is the same for both cases where I delete the lease on server side or create a static lease....

So I still do not REALLY see the advantage of such a "delete" functionality.


/KNEBB

Moin,

ich habe jetzt nur überflogen. Aber Du müsstest den Wireguard auf der zweiten Kiste ebenfalls als Server einrichten. Wenn der sich nämlich "nur" als Client betrachtet, wird er keine Pakete ins LAN weiterleiten....
Ich habe das hier genauso.
Eine Net-2-Net Verbindugn mit zwei Wireguard-Servern auf der OPNSense, die sich gegenseitig kennen udn PAkete weiterleiten. Lan1 zu Lan2 funktioniert problemlos. Zusätzlich einen zweiten Wireguard Server auf der einen OPNSense eingerichtet, die die "RoadWarrior" (z.B. Windows, Linux, Tablets etc.) evom Internet aus einbinden kann.

Funktioniert wunderbar.

I'm unclear why other DHCP products and even at least some past DNSMasq products were able to help here, but this one won't.

They faked it! @Monviech (Cedrik) has confirmed my post: there is no way a given lease can be recalled! Earliest will be half of lease time. If there were products offering a "delete lease" button they deleted the mapping but did not remove the IP from the client.

You can archive your goal but you have to re-design your setup then. Create static mappings for you known clients, reduce lease time for unknown clients. You might consider to move dynamic clients to a different (V)LAN if this option is not suitable. Or join you new client to a different net to discover the MAC (although it is mostly written somewhere), create a static mapping and move it to the target net.

However: based on technical implementation you simply can not "delete" a given lease. If other product offer this it is faked! 

Hi,

sorry to say but I guess you two do not understand how DHCP leases are designed...

DHCP leases have a lease time configured. Usually something about 7,200 seconds. This lease time will be send to the client together with the IP information.

So in order this is what happens when a client is configured to use DHCP:
1. client boots and sends a broadcast (dst address: 255.255.255.255, src address: 0.0.0.0) to DISCOVER the DHCP server
2. The DHCP server replies as broadcast including a suggestion (!) for IP configuration (called OFFER)
3. Client receives this reply and checks the provided information
4. In case the client can not accept the IP information (for some reason) it waits and re-starts with 1.
5. If the information is fine it will send a REQUEST packet asking the DHCP to use the requested IP
6. DHCP server confirms the use of the address and provides additional information (lease time, ntp server, ...) with an ACK
7. client is working with the provided information
8. when half (!) of the lease time has been passed, the client sends a renewal request for further usage of the IP
9a. DHCP server confirms the usage- lease time starts again. Client does 8 again after half of the time has passed
9b. If client does not get reply, it waits until 3/4 of the lease time has passed and sends the renewal request- see 8.
9c. If DHCP server refuses the further usage, does not reply at all or the lease time has passed the client releases the IP (and has not IP configuration any more)

So for you request this means:
On behalf of the DHCP server (OPNSense) you can not force a client to release or re-request an IP! If the DHCP lease time has not passed the client is still allowed to use the IP. At least until half of the time has passed. IF you reboot your server it usually does not know about the already given leases and when a client re-request after half time it might get a new IP (because the server is not aware of the already existing lease). In the end, rebooting the server (or letting him "forget" the lease) causes more trouble....

However, I see your issue. My suggestion:
Configure your DHCP server (TBH unsure if this is possible with DNSmasq) to give unknown clients only a VERY short lease time (ie 60 seconds). And for the known clients (which means there is a static lease configured) the default lease time. Thus, your client re-requests the IP very frequently and you can easily move the dynamic lease to a static one and the client will pick it up after 30 seconds....
[EDIT]:
Just checked for the ISC DHCP server on OPNSense:
Configure default lease to 60 seconds. An overwrite this default setting in every static lease by setting it to 7,200.

/KNEBB


 

Ja es ist meine IP, wenn man aber auf diese IP einen Scan macht, geht es nicht direkt auf meine echte IP. Also habe ich einen gewissen Schutz?

Ich glaube, Du hast das Ganze nicht verstanden- also das, wovor Du Dich "schützen" willst.

Du meinst, wenn Du Dich auf einer Webseite oder einem anderen Internet-Dienst verbindest, wird direkt ein "Scan" gefahren, der Deine IP "untersucht"? Das ist eher nicht so- wenn, dann bei "bösen Buben".

Zur Klarheit: Wenn Du einen Dienst (Webserver, Mailserver, irgendein Cloud-Dienst einer App,...) kontaktierst, wird als Absender Deine IP-Adresse mitgeschickt. Über diese IP gibt es gewisse (öffentliche!) Informationen- zB welche Firma diese hat, wo sie geolokalisert ist und manches mehr. Keine dieser Informationen lassen jedoch Rückschlüsse auf Dich zu. Ausnahme: Dein Provider, der ist der einzige, der die IP Deiner Person (Vertragspartner) zuordnen kann.

Was manche Werbenetze halt nutzebn, sind oft ganz andere Informationen wie zB Browser-Versionen, OS-Versionen, Cookies etc. Das können Sie aber auch, wenn Du über Dein Wireguard-VPN gehst. Da hast Du dann zwar eine andere IP, aber das bringt Dir Schutzmäßig nicht viel.
Kurz: Das macht nicht wirklich Sinn... ja, ist machbar aber mit einem solchen fehlerbehaftetem Setup willst Du nicht wirklich "arbeiten". Die Fehlersuche ist ein Albtraum.

Ein VPN macht nur dann Sinn, wenn Du die Informationen, die Du versendest tatsächlich Schützen musst- in autoritären Staaten zB. Für Dich macht es keinen Sinn, da die Informationen so oder so nach dem VPN wieder zT unverschlüsselt übertragen werden.

Und wenn Du meinst, ein "normaler" Scan findet durch diesen Aufbau weniger Informationen, so liegst Du auch falsch. Deine IP der OPNSense ist ja dennoch weiterhin im Internet sichtbar- sonst könntest Du ja nicht kommunizieren. Die "böse Buben" Scans nehmen einfach beliebige IP (-BEreiche) und scannen durch. Ob Du Deine IP für ausgehende Anfragen vir Wireguard Verschleierst oder nicht, spielt dabei keine Rolle. Eher im Gegenteil, Du hast ja dann sogar zwei IPs, auf denen die "bösenBuben" versuchen können, einzudringen oder Informationen abzugreifen....

Also meiner bescheidenen Meinung nach ist das vollkommener Quatsch....
/KNEBB



 

Moin,

mir ist nicht ganz klar, was Du erreichen willst?

• Werbung weg?
• IP verschleiern?
• DNS selbst hosten?

Ich denke aber, dass Du ein wenig eine fahlsche Vorstellung hast, was Dir ein solcher Cloud-Server bringen kann... Du hast doch schon im LAN eine OPNSense, damit kannst Du doch eigentlich alles machen, dann braucht es doch keinen Cloud-Server mehr zusätzlich?


/KNEBB

Öhmmm... ich verstehe hier die Problematik nicht.

Wir haben KEINE Probleme mit der TI. Der "Konnektor" läuft als normales Gerät im LAN und baut über die OPNSense den VPN Tunnel auf. Die Clients/ Server nutzen den Konnektor für die TI und gut ist.
Die OPNSense hat "nur" ein Wireguard-VPN zur privaten OPNSense.

Versucht ihr, das TI-VPN mit der OPNSense aufzubauen? Warum?

Ich lebe da eher nach dem KISS-Prinzip ("Keep it Simple and Stupid").

Und ja, ist auch Tomedo.

[BUT!]

Hi,

meanwhile I used the Shaper-rules and it is working so far.

I re-checked the Shaper documentation and the provided examples. I re-created my rules (and re-check pipes and queue settings).
Now the setup is as follows:
Pipes (low limits for testing purposes)

• Global Upload --> 70Mb/s
• Global Download --> 80MB/s

Queues

• VOIP Upload, weight 80 --> Global Upload Pipe
• VOIP Download, weight 80 --> Global Download Pipe
• LAN Uplaod, weight 15 --> Global Upload Pipe
• LAN Download, weight 15 --> Global Download Pipe

Rules (192.168.9.0/24 is the remote VPN LAN while 192.168.1.0/24, 192.168.30.0/24 are the local ones)

• Seq 3, WireguardGroup, SRC 192.168.9.0/24, DST any, IN --> LAN Download Queue
• Seq 4, WireguardGroup, SRC any, DST 192.168.9.0/24, OUT --> LAN Upload Queue
• Seq 10, WAN, SRC 192.168.30.0/24, DST any, OUT --> VOIP Upload Queue
• Seq 11, WAN, SRC 192.168.1.0/24, DST any, OUT --> LAN Upload Queue
• Seq 20, WAN, SRC any, DST 192.168.30.0/24, IN --> VOIP Download Queue
• Seq 21, WAN, SRC any, DST 192.168.1.0/24, IN --> LAN Download Queue

Now I can see the limits working fine on traffic between LAN and Internet, in both directions.

BUT!
Traffic to/ from Wireguard VPN is not limited at all. So I guess the weighting is not taken into account here. Which might interfere with the VOIP traffic beeing capped by a large VPN traffic...

Before going further (and trying to start with the FW rules) I need to know why the Wireguad traffic is not limited? Even when the interface (wireguardGroup) is wrong it should be limited by the default LAN rule, shouldn't it?

Confused,

/KNEBB

[Line Download]

Hi,

thanks for your explanations and your patience! Very kind!

I am really trying to understand. And I think I got it in theory now.

So I have currently setup in the following way:

Line Download

• Min: 750Mbit/s
• Max: 1000Mbit/s

Line Upload:

• Min: 375Mbit/s
• Max: 500Mbit/s

Configured Pipes with the WFQ scheduler and CoDel activated:

• VoIP Upload -> 10Mbit/s
• VoIP Download -> 10Mbit/s
• LAN Upload (min) -> 365Mbit/s (the min available bandwidth reduced by the 10Mbit/s for VoIP)
• LAN Upload (max) -> 500Mbit/s
• WAN Download (min) -> 750Mbit/s
• WAN Download (max) -> 1000Mbit/s

No rules in Shaper

A rule on bottom of the WAN interface as catch-all:

• Action: Allow
• Interface: WAN (which is NATed to pulic IP)
• Direction: out
• First match: active
• IPv4
• Protocol: any
• Source/ SrcPort: any
• Dest/ DstPort: any
• Traffic Shaping:
• In RuleDirection --> LAN UploadQueue (min)
• In ReverseDirection --> LAN DownloadQueue (min)

Looks pretty fine for me...but!

As soon as I activate the rule on the WAN interface my traffic to any internet host drops completely.
But my traffic through Wireguard-VPN works pretty fine, but not limited to the above 365Mbit/s....

I have no clue what I am doing wrong...anyone an idea?
I think the bug is not related- as far as I understand it the bandwidth calculation is wrong and offers only half of configured values. But through Wireshark I do not have any limits (why not???) and to Internet all is blocked....
Thanks again!
/KNEBB

[NOT]

Hi,

thanks for the hints. I am currently configuring it. Still not understanding how it all works together, especially the two rule types and the issue with the reported bug...


Created a FW-rule on the (NATed) WAN interface (outgoing, src: VoIP VLAN) to assign traffic to the VoIP Shaper Queue (which is bound to the VoIP pipe, limited to 10Mb/s). Queue weight is 90.
 
Then created a schedule for "office times" and used a FW-rule to assign any other traffic (excluding the VoIP) to the "default office time upload queue" which is assigned to a pipe and by this limited to 365Mb/s (guaranteed value of 375Mb/s less the 10Mb/s for VoIP). This sheduled rule is ordered before the above one. Weight of the queue is 10.

So I have:

• Pipe VoIP - Limit 20
• Pipe LAN daytime - Limit 365
• Pipe LAN nighttime - Limit 500

Queues:

• Queue VoIP - weight 90
• Queue LAN daytime - weight 50
• Queue LAN nighttime - weight 50

The queues and pipes are assigned as the names tell.

Disabled all Shapoer rules.
Created a FW rule on the WAN interface:

• Outgoing, src: LAN, DST: any, protocol: any, schedule: daytime, traffic shaping in rule direction: Queue LAN daytime

No other rule before this FW rule for outgoing traffic, acting as a "catch all".
(Tried to assign the reverse traffic to the same queue, same result)
 
My expection:
Outgoing traffic should be limited to 365Mb/sec.

My observation:
Outgoing traffic is NOT limited.


I even see in the FW-protocol the traffic is assigned to the queue.

Any idea?

Time based rules are not possible with the ipfw ruleset (FW > shaper > Rules) but they are possible when using the pf rules + Traffic shaping feature (FW > Rules (option Traffic Shaping)). However there is a BUG in regards of that feature for reverse-direction if NAT is involved see:
https://forum.opnsense.org/index.php?topic=47716.msg254051

Hmmm.. can you help me a little bit how this works all together?

I got it so far the pipes limit the bandwidth (upper limit) while the queues weight the traffic according to the rules. Queues can get oignoredd when a rule sends the traffic to a pipe immediately ( I do not know how any weight is then calculated). Got this so far.

But how are the (firewall-)rules coming into the game you mentioned above? Do I overwrite everything and directly assign traffic to pipes/queues? How are they different (except scheduling possibility) from the shaper rules?

Thanks a lot!

/KNEBB

Moin,

klingt für mich eher NICHT nach Softwareproblem. Wenn wirklich ein HArd-Reset notwendig ist, hängt irgendwo in der Hardware etwas.

Ich würde mal sicherstellen, dass jeweils die aktuellste Firmware installiert ist. Und natürlich auch die SW-Update, aber das hast Du ja wohl).

In den Logfiles mal auf alles achten, was kurz vor dem Zusammenbruch war... vielleicht gibt es da einige Hinweise....

Aber ist schwer, so aus der Ferne....
/KNEBB
 

Ich habe Queues und Rules eingerichtet, die das Ganze zuordnen. Lt. Shaper --> Status funktioniert das Ganze auch wunderbar.

Über die Pipes richtet man maximale Obergrenzen ein. D.h. mehr geht nicht über diese Pipe. DAs ist auch alles super, das "Problem" tritt ja nur auf, wenn der Provider die maximale Uplink-Bandbreite nicht abdecken kann (also 375 anstatt 500). Dann werden Pakete ggf. verworfen u.ä. Und zwar ohne auch irgendwelche Priorisierungen (von mir) zu achten. Und damit geht die ganze Konfiguration flöten...

Stelle ich es aber auf die minimale Rate ein, dann weiß ich, dass der Provider diese auch annimmt und ordnungsgemäß weiterleitet und meine Priorisierung greift. Auf Ksoten der maximal verfügbaren Bandbreite.

Und deshalb wäre da eine zeitabhängige Regelung sinnvoll. Tagsüber Limit auf min --> VoIP kriegt sicher Prio. Nachts auf max --> Nutzung voller Bandbreite, wenn die Prio flöten geht, ist das egal, da telefoniert hier eh keiner mehr.

/KNEBB