Re: [Kea-users] Using DHCP Relays
Am 23.01.23 um 09:43 schrieb Stefan G. Weichinger: I currently wait for the admin there to call me back, then we will try to test drive the relay setup. Currently ~85 leases in 4 subnets active, we'll see. Unsure how the active leases will be handled, looking forward to see the behavior. Either it works or ... not. It works ;-) It was rather unspectacular, but looks great so far. Both nodes reconfigured already, no more asymmetric routing, group policies work ... nice! Thanks all for your help! -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Using DHCP Relays
Am 23.01.23 um 07:52 schrieb Klaus Steden:
This is what we added to our Kea configs to deal with the encapsulated
requests:
...
"option-def": [
{
"name": "link",
"code": 150,
"space": "relay-cisco",
"type": "ipv4-address",
"record-types": "",
"array": false,
"encapsulate": ""
},
{
"name": "server-id",
"code": 152,
"space": "relay-cisco",
"type": "ipv4-address",
"record-types": "",
"array": false,
"encapsulate": ""
}
],
...
"""
We're using UDP sockets and the shared-networks option, with the relays
in a separate file (as a JSON-formatted list):
"""
...
"shared-networks": [
{
"name": "my-site-relays",
"relay": {
"ip-addresses":
},
"subnet4": [
]
}
],
...
"""
Hopefully this is useful to you ...
cheers,
Klaus
Thanks @Klaus for these snippets. I hope I don't need them ;-)
I think I don't need "shared subnets" in my case, for example.
I currently wait for the admin there to call me back, then we will try
to test drive the relay setup. Currently ~85 leases in 4 subnets active,
we'll see.
Unsure how the active leases will be handled, looking forward to see the
behavior. Either it works or ... not.
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Using DHCP Relays
This is what we added to our Kea configs to deal with the encapsulated
requests:
...
"option-def": [
{
"name": "link",
"code": 150,
"space": "relay-cisco",
"type": "ipv4-address",
"record-types": "",
"array": false,
"encapsulate": ""
},
{
"name": "server-id",
"code": 152,
"space": "relay-cisco",
"type": "ipv4-address",
"record-types": "",
"array": false,
"encapsulate": ""
}
],
...
"""
We're using UDP sockets and the shared-networks option, with the relays in
a separate file (as a JSON-formatted list):
"""
...
"shared-networks": [
{
"name": "my-site-relays",
"relay": {
"ip-addresses":
},
"subnet4": [
]
}
],
...
"""
Hopefully this is useful to you ...
cheers,
Klaus
On Sat, Jan 21, 2023 at 7:53 AM Simon wrote:
> Stefan G. Weichinger wrote:
>
> >> I will start by stopping one of my 2 kea-nodes, and then remove the
> VLAN interfaces on the remaining one. Plus enable the DHCP-relay, plus
> adding that fw-rule.
> >> In kea I have to remove the various vlan-interfaces and edit the
> subnets to all listen on the same and only LAN-interface.
> >
> > Did my changes but today there are no more workers on site there so it's
> a bit hard to test for me from remote.
> >
> > Went back to the old setup for now.
> >
> > questions around config:
> >
> > Could I remove the separate interface lines from the subnets:
> >
> >
> > {
> > "interface": "enp0s31f6", # THIS LINE
> > "id": 3,
> > "subnet": "192.168.103.0/24",
> >
> >
> > In the first lines I already have:
> >
> >
> > {
> >"Dhcp4": {
> >"interfaces-config": {
> >"interfaces": [ "enp0s31f6" ],
> >"dhcp-socket-type": "raw",
> > "service-sockets-require-all": false,
> > "service-sockets-max-retries": 1000,
> > "service-sockets-retry-wait-time": 1
> >},
> >
> >
> > That defines the interface anyway, right?
>
> I think so, but I’m not a Kea user and have only had a fairly quick look
> at the documentation - most of the previous advice is based on relaying
> being generic and not really affecting server config much/at all.
> With dhcpd (where my experience is for about 25 years !), the only config
> for interfaces is to specify which ones to listen on.
>
> > "dhcp-socket-type" is ok? "raw" seems to be the default anyway.
>
>
> The manual at
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#interface-configuration
> says :
> > Kea supports responding to directly connected clients which do not have
> an address configured. This requires the server to inject the hardware
> address of the destination into the data-link layer of the packet being
> sent to the client. The DHCPv4 server uses raw sockets to achieve this, and
> builds the entire IP/UDP stack for the outgoing packets. The downside of
> raw socket use, however, is that incoming and outgoing packets bypass the
> firewalls (e.g. iptables).
>
>
> > Using UDP sockets automatically disables the reception of broadcast
> packets from directly connected clients. This effectively means that UDP
> sockets can be used for relayed traffic only. When using raw sockets, both
> the traffic from the directly connected clients and the relayed traffic are
> handled.
>
>
> So it’s clear that you want to keep raw sockets (default, no need to
> specify it) if you have any locally connected clients - but if you have no
> locally connected clients and want packets to pass through a firewall then
> use UDP.
>
>
> Also, looking at
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#dhcp4-subnet-selection
> it seems fairly clear that you don’t need to tie subnets to interfaces in
> the config - simply defining the interfaces to listen on, and the subnets
> to be served, is sufficient for the server to automagically associate
> clients with the right subnet.
>
>
> Simon
>
>
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
>
> Kea-users mailing list
> Kea-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users
>
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Using DHCP Relays
Stefan G. Weichinger wrote:
>> I will start by stopping one of my 2 kea-nodes, and then remove the VLAN
>> interfaces on the remaining one. Plus enable the DHCP-relay, plus adding
>> that fw-rule.
>> In kea I have to remove the various vlan-interfaces and edit the subnets to
>> all listen on the same and only LAN-interface.
>
> Did my changes but today there are no more workers on site there so it's a
> bit hard to test for me from remote.
>
> Went back to the old setup for now.
>
> questions around config:
>
> Could I remove the separate interface lines from the subnets:
>
>
> {
> "interface": "enp0s31f6", # THIS LINE
> "id": 3,
> "subnet": "192.168.103.0/24",
>
>
> In the first lines I already have:
>
>
> {
>"Dhcp4": {
>"interfaces-config": {
>"interfaces": [ "enp0s31f6" ],
>"dhcp-socket-type": "raw",
> "service-sockets-require-all": false,
> "service-sockets-max-retries": 1000,
> "service-sockets-retry-wait-time": 1
>},
>
>
> That defines the interface anyway, right?
I think so, but I’m not a Kea user and have only had a fairly quick look at the
documentation - most of the previous advice is based on relaying being generic
and not really affecting server config much/at all.
With dhcpd (where my experience is for about 25 years !), the only config for
interfaces is to specify which ones to listen on.
> "dhcp-socket-type" is ok? "raw" seems to be the default anyway.
The manual at
https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#interface-configuration
says :
> Kea supports responding to directly connected clients which do not have an
> address configured. This requires the server to inject the hardware address
> of the destination into the data-link layer of the packet being sent to the
> client. The DHCPv4 server uses raw sockets to achieve this, and builds the
> entire IP/UDP stack for the outgoing packets. The downside of raw socket use,
> however, is that incoming and outgoing packets bypass the firewalls (e.g.
> iptables).
> Using UDP sockets automatically disables the reception of broadcast packets
> from directly connected clients. This effectively means that UDP sockets can
> be used for relayed traffic only. When using raw sockets, both the traffic
> from the directly connected clients and the relayed traffic are handled.
So it’s clear that you want to keep raw sockets (default, no need to specify
it) if you have any locally connected clients - but if you have no locally
connected clients and want packets to pass through a firewall then use UDP.
Also, looking at
https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#dhcp4-subnet-selection
it seems fairly clear that you don’t need to tie subnets to interfaces in the
config - simply defining the interfaces to listen on, and the subnets to be
served, is sufficient for the server to automagically associate clients with
the right subnet.
Simon
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Using DHCP Relays
Hi, I'm just using dnsmasq to create a dhcp relay on my router, and my machine running Kea just have one interface but many IP ranges to cover all subnets in Kea. dnsmasq is easy to configure, this is a complete setup: dhcp-relay=gateway_ip,dhcp_server_ip # Disable the DNS server in dnsmasq port=0 Just repeat dhcp-relay for each subnet in your setup. I've setup an Ansible role for this purpose, looping over the interfaces defined on my router. Regards, Oscar "Stefan G. Weichinger" writes: > It seems I have to rebuild my DHCP setup. > > Currently I have vlan interfaces on the kea-servers to provide DHCP to > each defined VLAN. > > This leads to problems: the VLAN interfaces also set routes to the > various VLANs, this breaks routing for the Samba DCs also running on > the same hardware. > > (I skip the details, off topic here) > > So it seems I have to remove the VLAN interfaces and somehow use a > DHCP relay (on the existing pfsense) for each of the VLANs. > > What I don't yet understand: how to assign requests coming from VLAN X > to the matching subnet X on Kea? > > I read something around "circuit ID" and "agent ID" here: > > https://docs.netgate.com/pfsense/en/latest/services/dhcp/relay.html > > Could someone share an example how to set that up with kea? > > thanks! -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Using DHCP Relays
Am 21.01.23 um 08:03 schrieb Stefan G. Weichinger:
I will start by stopping one of my 2 kea-nodes, and then remove the VLAN
interfaces on the remaining one. Plus enable the DHCP-relay, plus adding
that fw-rule.
In kea I have to remove the various vlan-interfaces and edit the subnets
to all listen on the same and only LAN-interface.
Did my changes but today there are no more workers on site there so it's
a bit hard to test for me from remote.
Went back to the old setup for now.
questions around config:
Could I remove the separate interface lines from the subnets:
{
"interface": "enp0s31f6", # THIS LINE
"id": 3,
"subnet": "192.168.103.0/24",
In the first lines I already have:
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "enp0s31f6" ],
"dhcp-socket-type": "raw",
"service-sockets-require-all": false,
"service-sockets-max-retries": 1000,
"service-sockets-retry-wait-time": 1
},
That defines the interface anyway, right?
"dhcp-socket-type" is ok? "raw" seems to be the default anyway.
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Using DHCP Relays
Am 20.01.23 um 15:44 schrieb Simon: Stefan G. Weichinger wrote: It seems I have to rebuild my DHCP setup. I suggest “rebuild” is a strong word - modify would be more appropriate. You are right, yes ;-) Ignore circuit-id and agent-id, they are a fairly advanced configuration relating to identifying individual ports on a switch, or subscribers on a WAN system. They are not required at all for what you want. ok You will simply need to configure a relay agent on each network (technically, collision domain) to be served. These are typically configured on routers for convenience, but that is not required and it can be any device as long as it’s in the same broadcast domain as the clients to be served. If KEA is not explicitly configured with a subnet (or shared-network) to local interface mapping, then the config will not need modifying. How it works is : When the relay agent identifies a broadcast DHCP packet on the remote network, it captures it, modifies it by adding “Agent-ID” (typically it's interface IP address on the remote network), and then forwards it to the server(s) configured (typically as unicast packet(s). When the server gets the packet, it sees that the Agent-ID field is filled in and uses this to identify the network to which the client is connected - the logic is basically the same as using the IP address of the local interface in the case of locally connected clients. When the server has assembled the reply packet (offer or acknowledge), it sends it to the address in the Agent-ID field of the incoming packet. The relay agent picks it up, and broadcasts it on the client's network. The client receives it just as though it was from a local server. For renewals, the client will unicast it’s renewal request to the IP of the server, and the server will reply directly - the relay agent is not involved with this. For this reason, the clients and server(s) must be able to address IP packets between them. Good to know. So there has to be a specific firewall rule for that in each VLAN. TL;DR Change nothing on your DHCP server config. Configure DHCP relay agent for each remote network - ensuring that the relay agent uses the correct IP address for the Agent-ID for each network. This should be automagic but I have heard of some systems with “interesting” issues in this area. It should “just work”. You answered my open questions, thank you very much. I didn't yet know how the requests would be matched with the configured subnets etc ... I was *assuming* that the relay IP might play a role. Now I know that, this gives me confidence to start modifying things. One issue I can think of ... Is pfsense (I assume it’s doing your routing) running on this box or a different one ? If it’s on a different box then all you’ll need to do is configure the relay agent and remove the interface from the DHCP server. If it’s on the same box, then things get a bit more “interesting”. Can you answer this ? different box I will start by stopping one of my 2 kea-nodes, and then remove the VLAN interfaces on the remaining one. Plus enable the DHCP-relay, plus adding that fw-rule. In kea I have to remove the various vlan-interfaces and edit the subnets to all listen on the same and only LAN-interface. That should do it ... looking forward to try that. thanks! -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Using DHCP Relays
Stefan G. Weichinger wrote: > It seems I have to rebuild my DHCP setup. I suggest “rebuild” is a strong word - modify would be more appropriate. > So it seems I have to remove the VLAN interfaces and somehow use a DHCP relay > (on the existing pfsense) for each of the VLANs. > > What I don't yet understand: how to assign requests coming from VLAN X to the > matching subnet X on Kea? > > I read something around "circuit ID" and "agent ID" here: > > https://docs.netgate.com/pfsense/en/latest/services/dhcp/relay.html Ignore circuit-id and agent-id, they are a fairly advanced configuration relating to identifying individual ports on a switch, or subscribers on a WAN system. They are not required at all for what you want. You will simply need to configure a relay agent on each network (technically, collision domain) to be served. These are typically configured on routers for convenience, but that is not required and it can be any device as long as it’s in the same broadcast domain as the clients to be served. If KEA is not explicitly configured with a subnet (or shared-network) to local interface mapping, then the config will not need modifying. How it works is : When the relay agent identifies a broadcast DHCP packet on the remote network, it captures it, modifies it by adding “Agent-ID” (typically it's interface IP address on the remote network), and then forwards it to the server(s) configured (typically as unicast packet(s). When the server gets the packet, it sees that the Agent-ID field is filled in and uses this to identify the network to which the client is connected - the logic is basically the same as using the IP address of the local interface in the case of locally connected clients. When the server has assembled the reply packet (offer or acknowledge), it sends it to the address in the Agent-ID field of the incoming packet. The relay agent picks it up, and broadcasts it on the client's network. The client receives it just as though it was from a local server. For renewals, the client will unicast it’s renewal request to the IP of the server, and the server will reply directly - the relay agent is not involved with this. For this reason, the clients and server(s) must be able to address IP packets between them. TL;DR Change nothing on your DHCP server config. Configure DHCP relay agent for each remote network - ensuring that the relay agent uses the correct IP address for the Agent-ID for each network. This should be automagic but I have heard of some systems with “interesting” issues in this area. It should “just work”. One issue I can think of ... Is pfsense (I assume it’s doing your routing) running on this box or a different one ? If it’s on a different box then all you’ll need to do is configure the relay agent and remove the interface from the DHCP server. If it’s on the same box, then things get a bit more “interesting”. Can you answer this ? Simon -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Using DHCP Relays
On Fri, Jan 20, 2023, at 03:17, Stefan G. Weichinger wrote: > What I don't yet understand: how to assign requests coming from VLAN X > to the matching subnet X on Kea? > > I read something around "circuit ID" and "agent ID" here: > > https://docs.netgate.com/pfsense/en/latest/services/dhcp/relay.html > > Could someone share an example how to set that up with kea? There isn't anything to do in Kea; it's done in the DHCP relay. The relay adds the necessary information when it forwards the DISCOVER requests so that the DHCP server can map the request to a subnet. If you're using pfSense, you'll need to consult its documentation to learn how to setup a DHCP relay there. -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
