Messages

16

General Discussion / Re: Problem with DHCP Static Mappings

« on: August 13, 2021, 09:36:34 am »

The pool is 100 addresses, no shortage there.

Also I disagree how static MAC mappings are supposed to work in DHCP pool. There would be no point in having "Add static mapping" functionality in the first place. Assigning static IPs outside of the pool is completely different use-case - that simply separates DHCP from the static address range altogether.

IMO: The problem is quite obvious on the DHCP lease list itself. Why is it having two leases that its fully aware of, for the same address?

17

General Discussion / Re: Problem with DHCP Static Mappings

« on: August 08, 2021, 11:00:35 am »

Updated to newest Business branch version (21.4.2-amd64) and it still does this:

When different MAC 00:15:5d:00:12:3d has clearly reserved 10.27.4.101 it still offers and leases it out to 00:15:5d:00:12:38. The reserving MAC is offline at the moment.

Log:

2021-08-08T11:54:14   dhcpd[48908]   DHCPACK on 10.27.4.101 to 00:15:5d:00:12:38 via igb0_vlan4   
2021-08-08T11:54:14   dhcpd[48908]   DHCPREQUEST for 10.27.4.101 (10.27.4.1) from 00:15:5d:00:12:38 via igb0_vlan4   
2021-08-08T11:54:14   dhcpd[48908]   DHCPOFFER on 10.27.4.101 to 00:15:5d:00:12:38 via igb0_vlan4   
2021-08-08T11:54:13   dhcpd[48908]   DHCPDISCOVER from 00:15:5d:00:12:38 via igb0_vlan4   
2021-08-08T11:52:45   dhcpd[48908]   Server starting service.   

Leases:

TBNET   10.27.4.101   00:15:5d:00:12:38
Microsoft Corporation         2021/08/08 08:54:14 UTC   2021/08/08 10:54:14 UTC      active   

TBNET   10.27.4.101   00:15:5d:00:12:3d
Microsoft Corporation   kubehost               static   

18

General Discussion / Re: Problem with DHCP Static Mappings

« on: July 26, 2021, 02:14:22 pm »

Yes it is. There is UI assistant on leases, that provides button for "add a static mapping for this MAC address", but that didn't seem to reserve the IP.

19

General Discussion / Problem with DHCP Static Mappings

« on: July 17, 2021, 02:48:56 pm »

For some reason my DHCP Server on OPNSense doesn't seem to respect the static mappings. Initially I didn't set the "ARP Table Static Entry" and thought that was the case, but the problem persists still:

Interface   IP address   MAC address   
Hostname   Description   Start   End   Status   Lease type
TBNET   10.27.4.101   00:15:5d:00:12:3d
kubehost               static   

TBNET   10.27.4.101   10:d5:61:7e:5c:59
2021/07/17 12:17:48 UTC   2021/07/17 14:17:48 UTC      active

The latter entry is fresh, getting the IP Address of static mapped server, that's not running right now (or hasn't been for a while, thus its lease was expired).

• DHCP Server has "Enable Static ARP" setting un-checked (= disabled).
• ARP Table Static Entry - for each entry is enabled

OPNSense version is following:

OPNsense 21.4.1-amd64
FreeBSD 12.1-RELEASE-p16-HBSD
OpenSSL 1.1.1k 25 Mar 2021

20

General Discussion / Re: Multi-WAN (3): 2+1 Failover & Priority

« on: June 16, 2021, 09:53:20 pm »

Got the Fiber now and the 2+1 WAN was set up basically as described here. Failovers work nice, DDNS is only part remaining and its trivial with the options available.

Haven't set/tested the server/port forwarding behavior on failovers, but with the well working setup up to this level, I don't expect any surprises there.

Thanks a lot for pointing me to right direction.

21

General Discussion / Re: Multi-WAN (3): 2+1 Failover & Priority

« on: June 03, 2021, 10:51:57 pm »

Thank you for that additional detail.

I managed to do the important parts 1 and 2 of the above. My fiber isn't yet setup, so the final setup is waiting to be tested (now "faked" the fiber partially in the configurations).

The traffic shaping with those bandwidths and small amount of comps in total (max 5 transferring simultaneously) would still leave ~100mbps for each just "fairly distributed", so I went with easy setup with pipes & queues to achieve just that.

I'll come back still to update the post, once the fiber finalizes and I can properly conclude the real testing. Should be somewhere next week hopefully !

22

General Discussion / Re: Multi-WAN (3): 2+1 Failover & Priority

« on: June 02, 2021, 10:49:17 pm »

Thank you for prompt and detailed reply! This pushed me indeed to proper direction and helped a lot with the initial confusion of various bits and pieces.

Traffic shaping is likely not a problem (I mean if I can't get it to work), as we have plenty of bandwidth, but I will play around if I can get traffic shaping to run on top of gateway groups.

I'll play around and update the post with results once done.

23

General Discussion / Multi-WAN (3): 2+1 Failover & Priority

« on: June 01, 2021, 09:24:44 pm »

On WAN side I have a of two wired connections (Cable and Fiber) and one 4G/LTE failover.

Let's call them:

WAN_CBL (1Gbps down, 100 mbps up)
WAN_FBR (500 Mbps down, 500 Mbps up)
WAN_FO4G (~40-50 Mbps down, ~10 Mbps up)

On LAN side I have 4 logical groups of machines/devices (separated by routing needs):

LAN_Desktops
LAN_Mobile_&_IoT
LAN_Servers
LAN_RemoteWorkClients

VLANs are used to separate (some) parts, but preferably IP/Groups can be used to "identify device group". LAN is having fully managed VLAN capable switches.

I want to dedicate certain local groups to specific WAN, but failover to other wired and eventually to 4G. So failover priority being like:

WAN_FBR => WAN_CBL => WAN_FO4G
WAN_CBL => WAN_FBR => WAN_FO4G

When everything is up and running the allocation of WANs would be as following:

WAN_FBR:
LAN_Desktops
LAN_Servers (* having priority/guaranteed minimum bandwidth over Desktops)

WAN_CBL:
LAN_Mobile_&_IoT
LAN_RemoteWorkClients (* having priority/guaranteed bandwidth over Mobile & IoT)

So to the questions:

1. Is it possible to have failover-fallback between WAN_FBR & WAN_CBL before eventually ending up to FO4G?
- So that the WAN_FBR and WAN_CBL both are under "only functional wired wan" if one is still functional

2. If the failover is possible, is it possible to allow "fallback of priority groups" also on failover
- LAN_Servers and LAN_RemoteWorkClients preferably keep their bandwidth shares/relative shares or priority

3. To keep Servers available - DDNS is to be used (on failover), but can be done outside the OPNsense
- This would be nice bonus, DDNS is on Route53, can be solved using device's own IP detection (as is now)

The OPNsense is running on DEC840 currently with all WANs having port of their own (3) and LAN having one port. In the future possibly moving to use SFP+ ports for 1Gbps+.

I think/believe/hope the above is doable, but being new to OPNsense, I don't have clear understanding what to group and how to define failovers properly.