Opened 22 months ago

Last modified 18 months ago

#5501 new defect

Kea DHCP destination unreachable (port unreachable)

Reported by: ernandia Owned by:
Priority: high Milestone: Outstanding Tasks
Component: dhcp4 Version: git
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DHCP Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

we have kea dhcp version 1.3.0 installed on centos 7. we are monitoring the packects via wireshark and the dhcp is not able to give a client IP address. the error after dhcp discover is: destination unreachable (port unreachable). can you help us to find the root of this problem? Thank you.

Subtickets

Attachments (2)

kea_port_unreachable_prints.docx (862.2 KB) - added by ernandia 22 months ago.
port_unreachable.pcapng (9.4 KB) - added by ernandia 22 months ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 22 months ago by fdupont

Which side, i.e., the client gets an unreachable from the server kernel, or the server gets an unreachable when it tries to send a response back?
Note usually this kind of problems comes from firewalls but lsof can be used to list sockets and verify addresses and ports...

comment:2 follow-up: Changed 22 months ago by ernandia

Hello,

from the server side, when the server gets an unreachable when it tries to send a response back.

this problem occur even with firewall off.

Any help will be appreciate.

comment:3 in reply to: ↑ 2 Changed 22 months ago by fdupont

Replying to ernandia:

from the server side, when the server gets an unreachable when it tries to send a response back.

=> argh! I am afraid the problem is on the client side (even if clients do not use a socket to read responses they usually open and bound one for many reasons including not leaving the kernel the port is not used...).

this problem occur even with firewall off.

=> the client punched a hole in the firewall sending the discover. Problems with firewalls are on the server side...

Any help will be appreciate.

=> what is the client? And if it runs on Unix, Linux or macOS lsof should help.

comment:4 follow-up: Changed 22 months ago by ernandia

The client is a modem TP-Link behind a DSLAN and Mikrotik router

comment:5 in reply to: ↑ 4 Changed 22 months ago by fdupont

Replying to ernandia:

The client is a modem TP-Link behind a DSLAN and Mikrotik router

=> hum, if you have a giaddr in packets on the server side the router is a relay. There are common problems with ports used by relays, BTW this is why there is a new spec (not yet a RFC) allowing relays to choose the port they use. Anyway the standard says what ports should be used so again the problem is not in the server...
It should be interesting to check what ports are used in packets on the network and if you have to patch the port in the response the pkt4 send hook is called after the port is set with both the query and the response.

comment:6 Changed 22 months ago by ernandia

Please find attached some wireshark capture and screen shots.

Changed 22 months ago by ernandia

Changed 22 months ago by ernandia

comment:7 Changed 22 months ago by fdupont

There is something wrong in your setup: the capture shows each discover sent twice: the first time in broadcast, the second relayed by 10.0.5.1 to 10.0.5.2. This is the first incorrect point: it should not be relayed on the same link. Now the first discover is not answered and the second is rejected by 10.0.5.2.
Some things to check:

  • network setup: the mikrotik router between the DSLAM and the Kea server should be either a bridge (layer 2 gateway) or a router + DHCP relay (layer 3 gateway).
  • what is the 10.0.5.2 box? It does not seem to be the Kea server. BTW I assume the capture was done on the Kea server box
  • what is the mikrotik config? Usually DHCP relays add a RAI option, here it just sets the giaddr and forwards discovers to 10.0.5.2
  • what is the Kea server config? What are the sockets used by the kea-dhcp4 process? What is the OS?

comment:8 Changed 18 months ago by fdupont

  • Milestone changed from ISC DHCP migration to Outstanding Tasks
Note: See TracTickets for help on using tickets.