Update to 2.5.0 broke DHCP relay

thesurf

@thesurf In reply to my last log. I logged into the systme and notices clog ist missing.

[2.5.0-RELEASE][root@fwint3]/var/log: clog -f /var/log/relayd.log
clog: Command not found.

In the logfile from the gui I can not see anything related to relayd. And hints?

thesurf

On the passiv cluster member I see the following error:

Feb 19 10:14:43 php-fpm 31035 /services_dhcp_relay.php: No suitable upstream interfaces found for running dhcrelay!

on the active one the service will not start

But there are no log entries what so ever if you click on start and then take look into the syslog

viktor_g

@thesurf Please provide more info about your configuration -
interfaces, IP addresses, DHCP Relay configuration

Gertjan

@thesurf A of 2.5.0 there is no more 'circular logging'.
pfSense 2.5.0 uses the more universal clear text line 'syslog' logging. The log files should be readabale with a simple 'cat' command.

Btw : I'm not using 'relayd' myself, and the pfSense in front of me is still on 2.4.5-p1 (update tomorrow), so can't detail more.

A program or service (process, daemon) can use whatever it want as a log file. Its not mandatory to use the system's syslog capabilities.

This file :
/var/log/relayd.log
dates from before the upgrade ?
Note the owner and group of the fiile.

That is, if you wipe it, and then

touch /var/log/relayd.log

A zero byte file will get created.
Adapt the owner / group if needed.

Start relayd.
The file changes - grows in size ?
Binary ? plain text ?

thesurf

Next Update...
if you enable the dhcp relay service like this:

Then click on the disable checkbox and save

and then reenable the service. The destionation services are missing.

thesurf

This post is deleted!

thesurf

@gertjan

Thanks for the reply. Did what you suggest.

[2.5.0-RELEASE][root@fwint3]/var/log: touch relayd.log
[2.5.0-RELEASE][root@fwint3]/var/log: ls -l relayd.log
-rw-r--r--  1 root  wheel  0 Feb 19 10:35 relayd.log

The service was once again configured. No file size change. Then it was started in the services section, one again no file size incread

thesurf

@viktor_g

Hi,

I have a Dell R610 with Intel X520 NIC. On this nic I have about 5 VLANs.

On 3 of this VLAN (as Interface in pfSense) I have activated relayd to forward the dhcp request to my dhcp Servers (Active directory controller).

Local net 192.168.8.0/24

DHCP: 192.168.1.27 and 192.168.1.28

Since this is another office Building. The pfSense on the client Network routes to the network 192.168.1.0/24 via a lwl Kabel.

This setup was up an running with 2.4.5_p1 for about 1 year. After the upgrade the service relayd would not start anymore.

viktor_g

@thesurf said in Update to 2.5.0 broke DHCP relay:

This setup was up an running with 2.4.5_p1 for about 1 year. After the upgrade the service relayd would not start anymore.

relayd or DHCP relay?..

https://docs.netgate.com/pfsense/en/latest/releases/2-5-0.html#security-errata:

Deprecated the built-in relayd Load Balancer #9386

relayd does not function with OpenSSL 1.1.x
The relayd FreeBSD port has been changed to require libressl – There is no apparent sign of work to make it compatible with OpenSSL 1.1.x
The HAProxy package may be used in its place; It is a much more robust and more feature-complete load balancer and reverse proxy

thesurf

@viktor_g

I I thought the relayd was the dhcp relay.
I'm working on the dhcp relay / forwarder.

For loadbalancing I'm using ha proxy on other pfsense.

fwcheck

I can confirm your findings. The DHCP-Relay setup was/is broken on update.

I used

/usr/local/sbin/dhcrelay -id vmx1 -iu vmx0 -a -m replace IP_dhcp-server1 IP_dhcpsever2

as a quick fix. (one WAN (vmx0), one LAN-Interface (vmx1))

I was very delighted to see that within 2.4.5_p1 the DHCP-Handling was much better. I did not have time to look deeply into this problem, so this is a quick fix.

viktor_g

@fwcheck said in Update to 2.5.0 broke DHCP relay:

I can confirm your findings. The DHCP-Relay setup was/is broken on update.

I used

/usr/local/sbin/dhcrelay -id vmx1 -iu vmx0 -a -m replace IP_dhcp-server1 IP_dhcpsever2

as a quick fix. (one WAN (vmx0), one LAN-Interface (vmx1))

I was very delighted to see that within 2.4.5_p1 the DHCP-Handling was much better. I did not have time to look deeply into this problem, so this is a quick fix.

Could you provide vmx0 and vmx1 IP addresses and IP_dhcp-server1, IP_dhcpsever2 to check ?

fwcheck

@viktor_g
Short:
vmx0 is a private IP
vmx1 is a public IP
Both dhcp Servers are upstream (behind vmx0)

Later today i will do a clean update install (2.4.4_p3 -> 2.5.0) and can check that again. I will come back to this.

viktor_g

@fwcheck we need to know IP addresses to test
you can change the network part of address if you don't want to show it

jimp

To diagnose this we are going to need better info. You can redact some things but we need to know:

The interfaces involved, and their subnets
All of the DHCP relay settings used

If you redact anything replace them with appropriate dummy addresses but keep at least enough to uniquely identify them (e.g. 10.0.0.1/24 -> x.x.x.1/24, 10.4.1.2/24->y.y.y.2/24).

Bonus points for getting the process output from 2.4.x and 2.5.x to compare what it's trying to run in each case.

fwcheck

I am not quite sure but i think within 2.4.5_p1 the dhcp was supplying adresses to openvpn-clients via a bridge. I will look into the old configuration ans supply info on monday afternoon.
Redundant carp setup
looks basically like this:
vmx0 192.168.0.3/29
vmx1 1.1.1.1/24 (a public subnet)
dhcp-server 10.2.1.14
dhcp-server 10.2.1.13

thesurf

@jimp

lets try here to give you a quick headsup since it is alread 9pm in germany.

Building setup:

Building a  ---- LWL dark fiber ---- Head office

Some quick drawing from draw.io

Total

The Carp and pfSense cluster didn't play a role here. I disabled carp in testing.

What I have seen on fwint3 that the dhcp request arrive as usal on the clients interface. But nothing is send out to the dhcp server.

There are more vlans that have ther own interface assigned in pfSense and other components, but they can be left out.

The cluster fwint3 and fwint4 have been updated without any problems from 2.4.5p1 to 2.5.0. Routing traffic everything works but not the dhcp forwarding.

I think I do not have logs of 2.4.5p1. And on 2.5.0 the dhcp forward did not start. There is nothing in the dhcp log nor is there something in the syslog. If I disable dhcp forwarding and start dhcp server on the fwint3 I see dhcp logs and leases go out and work like they did when they where forwarded.

Hope that helps. I you need something let me know.

thesurf

@jimp
Hi forgot. All Interface are intel x520 nic. So Interfaces will be ix0 and ix1 on each firewall. On top that is the vlan so ix0.8 and so on. NO Bridge.

johnsdixon

Also occurring on VMware ESXi 6.7 hosted environment with VMXNET3 cards. Single DHCP server target, with relays from six different networks (some VLAN, some 'direct' connect). Appears that all do not pass the DHCP packets to the server (none received in the external server logs), but packets are seen by packet capture on the interfaces concerned on pfSense.
Happy to build a test 2.5.0 environment to provide further info and logs if necessary.

viktor_g

@johnsdixon said in Update to 2.5.0 broke DHCP relay:

Happy to build a test 2.5.0 environment to provide further info and logs if necessary.

very good, we need to know:

DHCP Relay configuration (screenshot or <dhcrelay> part from your config.xml);
Routing table (netstat -rn output);
Interfaces IP addresses (ifconfig output);