Bug #10381
closed
dhcrelay does not start after upgrade to 2.4.5
Added by Ivars Strazdins about 4 years ago. Updated about 4 years ago.
0%
Description
After upgrade to version 2.4.5 dhclient service does not start from GUI.
Trying to start it produces error
Mar 27 15:05:28 gw php-fpm: /status_services.php: No suitable downstream interfaces found for running dhcrelay!
However, when started manually from command line, dhcrelay continues to work as before.
It can be started with command
dhcrelay -i bce1 10.67.20.31 10.67.20.34
Files
| Screenshot 2020-03-27 at 18.11.59.png (202 KB) Screenshot 2020-03-27 at 18.11.59.png | dhcrelay configuration | Ivars Strazdins, 03/27/2020 11:15 AM | |
| Screenshot 2020-03-28 at 00.01.33.png (1.24 MB) Screenshot 2020-03-28 at 00.01.33.png | dhcrelay running in debug mode | Ivars Strazdins, 03/28/2020 08:57 AM | |
| working.1585346429.pcap (2.83 KB) working.1585346429.pcap | dhcp trace when dhcrelay is running | Ivars Strazdins, 03/28/2020 08:57 AM | |
| not_working.1585346175.pcap (3.17 KB) not_working.1585346175.pcap | dhcp trace when dhcrelay is no running | Ivars Strazdins, 03/28/2020 08:57 AM |
Updated by Ivars Strazdins about 4 years ago
Sorry, I meant dhcrelay service, NOT dhclient service.
Updated by Viktor Gurov about 4 years ago
Please post more details to reproduce:
Destination server IP,
All interfaces IPs
it seems interface/server network mismatch(?) or configuration issue
Updated by Ivars Strazdins about 4 years ago
Interface details:
[2.4.5-RELEASE][admin@gw]/root: ifconfig
bce0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE>
ether 44:1e:a1:3e:82:f8
hwaddr 44:1e:a1:3e:82:f8
inet6 fe80::461e:a1ff:fe3e:82f8%bce0 prefixlen 64 scopeid 0x1
inet XX.YY.ZZ.34 netmask 0xfffffff0 broadcast XX.YY.ZZ.47
inet XX.YY.ZZ.35 netmask 0xfffffff0 broadcast XX.YY.ZZ.47
inet XX.YY.ZZ.36 netmask 0xfffffff0 broadcast XX.YY.ZZ.47
inet XX.YY.ZZ.37 netmask 0xfffffff0 broadcast XX.YY.ZZ.47
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect <flowcontrol> (100baseTX <full-duplex>)
status: active
bce1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE>
ether 44:1e:a1:3e:82:fa
hwaddr 44:1e:a1:3e:82:fa
inet6 fe80::461e:a1ff:fe3e:82fa%bce1 prefixlen 64 scopeid 0x2
inet6 2001:470:dd16::2 prefixlen 64
inet 10.67.20.2 netmask 0xffffff00 broadcast 10.67.20.255
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
bce2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE>
ether 44:1e:a1:3e:82:fc
hwaddr 44:1e:a1:3e:82:fc
inet6 fe80::461e:a1ff:fe3e:82fc%bce2 prefixlen 64 scopeid 0x3
inet AA.BB.CC.217 netmask 0xfffffff8 broadcast AA.BB.CC.223
inet AA.BB.CC.218 netmask 0xfffffff8 broadcast AA.BB.CC.223
inet AA.BB.CC.220 netmask 0xfffffff8 broadcast AA.BB.CC.223
inet AA.BB.CC.219 netmask 0xfffffff8 broadcast AA.BB.CC.223
inet AA.BB.CC.221 netmask 0xfffffff8 broadcast AA.BB.CC.223
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
bce3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=800bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LINKSTATE>
ether 44:1e:a1:3e:82:fe
hwaddr 44:1e:a1:3e:82:fe
inet6 fe80::461e:a1ff:fe3e:82fe%bce3 prefixlen 64 scopeid 0x4
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
enc0: flags=41<UP,RUNNING> metric 0 mtu 1536
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: enc
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo
pflog0: flags=100<PROMISC> metric 0 mtu 33160
groups: pflog
pfsync0: flags=0<> metric 0 mtu 1500
groups: pfsync
bce3.10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80003<RXCSUM,TXCSUM,LINKSTATE>
ether 44:1e:a1:3e:82:fe
inet6 fe80::461e:a1ff:fe3e:82fe%bce3.10 prefixlen 64 scopeid 0x9
inet6 2001:470:dd16:1:33::1 prefixlen 64
inet 192.168.100.14 netmask 0xffffff00 broadcast 192.168.100.255
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 10 vlanpcp: 0 parent interface: bce3
groups: vlan
bce3.15: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80003<RXCSUM,TXCSUM,LINKSTATE>
ether 44:1e:a1:3e:82:fe
inet6 fe80::461e:a1ff:fe3e:82fe%bce3.15 prefixlen 64 scopeid 0xa
inet 192.168.33.254 netmask 0xffffff00 broadcast 192.168.33.255
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 15 vlanpcp: 0 parent interface: bce3
groups: vlan
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1480
options=80000<LINKSTATE>
tunnel inet XX.YY.ZZ.34 --> TUNNEL_ENDPOINT
inet6 2001:470:27:3b5::2 --> 2001:470:27:3b5::1 prefixlen 128
inet6 fe80::461e:a1ff:fe3e:82f8%gif0 prefixlen 64 scopeid 0xb
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: gif
ovpns1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
ether 00:bd:a8:5d:f8:01
hwaddr 00:bd:a8:5d:f8:01
nd6 options=1<PERFORMNUD>
media: Ethernet autoselect
status: active
groups: tap openvpn
Opened by PID 68713
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:48:1c:e7:ed:00
inet6 fe80::48:1cff:fee7:ed00%bridge0 prefixlen 64 scopeid 0xc
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: bridge
id 00:bd:a8:5d:f8:01 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id ec:9a:74:09:a7:c0 priority 0 ifcost 20000 port 2
member: ovpns1 flags=147<LEARNING,DISCOVER,STP,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 13 priority 128 path cost 2000000 proto rstp
role designated state forwarding
member: bce1 flags=1c7<LEARNING,DISCOVER,STP,AUTOEDGE,PTP,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 20000 proto rstp
role root state forwarding
[2.4.5-RELEASE][admin@gw]/root:
Updated by Ivars Strazdins about 4 years ago
LAN interface == bce1
LAN network 10.67.20.0/24
DHCP servers are 10.67.20.31 and 10.67.20.34 - ISC DHCP servers with failover configuration.
Updated by Viktor Gurov about 4 years ago
- Status changed from New to Closed
Ivars Strazdins wrote:
LAN interface == bce1
LAN network 10.67.20.0/24
DHCP servers are 10.67.20.31 and 10.67.20.34 - ISC DHCP servers with failover configuration.
You are trying to run DHCP Relay on the same network (bce1 - 10.67.20.2/24) where your DHCP servers are located (10.67.20.31 and 10.67.20.34)
You don't need DHCP Relay in this case.
DHCP Relay will relay DHCP requests between broadcast domains:
https://docs.netgate.com/pfsense/en/latest/dhcp/dhcp-relay.html
Updated by Ivars Strazdins about 4 years ago
You're not paying attention. This setup is working and is required to OpenVPN clients to get DHCP address from internal DHCP server across the bridge. We use it for years.
I filed this bug not because I want to prove you anything or how it works.
I did it because it was working before with 2.4.4.p3 and stopped working after upgrade to 2.4.5
That is why I think you should pay attention.
Without dhcrelay, clients do not receive DHCP offer from DHCP server. I see it in network trace on LAN interface, but not on OpenVPN tap interface.
Traces are attached.
Updated by Ivars Strazdins about 4 years ago
- File working.1585346429.pcap working.1585346429.pcap added
- File not_working.1585346175.pcap not_working.1585346175.pcap added
Updated by Viktor Gurov about 4 years ago
- Status changed from Closed to New
Ivars Strazdins wrote:
You're not paying attention. This setup is working and is required to OpenVPN clients to get DHCP address from internal DHCP server across the bridge. We use it for years.
Fix:
https://github.com/pfsense/pfsense/pull/4253
you can check it using System Patches package
Commit ID: 61e6dcc3ca739f752327451ba344ff6566089ec3
Updated by Ivars Strazdins about 4 years ago
Thanks.
I applied the patch, but dhcrelay still doesn't start.
Mar 28 21:54:27 gw php-fpm: /system_patches.php: Beginning configuration backup to https://acb.netgate.com/save
Mar 28 21:54:31 gw php-fpm: /system_patches.php: End of configuration backup to https://acb.netgate.com/save (success).
Mar 28 21:54:31 gw php-fpm: System Patches: Patch fetched succesfully (ID: 5e7fab69a10ae, DESCR: DHCP Relay send/listen on same interface. Issue #10381 #4253)
Mar 28 21:54:55 gw php-fpm: System Patches: Patch applied succesfully (ID: 5e7fab69a10ae, DESCR: DHCP Relay send/listen on same interface. Issue #10381 #4253)
Mar 28 21:55:09 gw sshd48045: user admin login class [preauth]
Mar 28 21:55:09 gw sshd48045: Accepted publickey for admin from 10.33.1.1 port 53826 ssh2: RSA SHA256:XRO...J0
Mar 28 21:55:37 gw php-fpm: /status_services.php: No suitable downstream interfaces found for running dhcrelay!
Mar 28 21:56:45 gw rc.php-fpm_restart78630: >>> Restarting php-fpm
Mar 28 21:56:45 gw check_reload_status: check_reload_status is starting.
Mar 28 21:57:02 gw php-fpm79231: /status_services.php: No suitable downstream interfaces found for running dhcrelay!
Mar 28 21:57:21 gw php-fpm79181: /status_services.php: No suitable downstream interfaces found for running dhcrelay!
Updated by Viktor Gurov about 4 years ago
Ivars Strazdins wrote:
Thanks.
I applied the patch, but dhcrelay still doesn't start.
Can you provide more details about your dhcrelay configuration?
Do you select only one interface and two upstream servers from the same network?
I have successfully tested this PR on 2.4.5 with LAN IP 192.168.3.4/24 and upstream servers 192.168.3.11 and 192.168.3.12
Updated by Ivars Strazdins about 4 years ago
Do you select only one interface and two upstream servers from the same network?
Yes. I don't have anything more than what is seen in screenshot in note 3, https://redmine.pfsense.org/attachments/2990/Screenshot%202020-03-27%20at%2018.11.59.png
But if I select any other interface instead of LAN, then dhcrelay is starting.
However, after reading that DHCP is a special case on pfSense, it is allowed with hidden rules that are activated when DHCP is used on an interface. (https://forum.netgate.com/topic/90384/help-clarify-my-understanding-of-the-net-link-bridge-pfil-tunables-please/3) I added firewall rule on LAN interface, allowing UDP on port 67 and 68 to pass and now DHCP is working.
MacOS OpenVPN clients are receiving DHCP offer from servers and get IP address without dhcrelay running. So I have found "a workaround" or finally have a proper configuration, whatever.
I had no time to do traces but I don't understand why Windows OpenVPN clients were getting IP address without firewall rules, but macOS clients need the rules for UDP on ports 67,68. But this is out of scope for this case.
If you want to find the root cause why dhcrelay is not starting, I will, of course, help you with more debugging, but if you feel that this whole thing now looks too messy, then please close this issue.
Thanks.
Updated by Viktor Gurov about 4 years ago
Ivars Strazdins wrote:
However, after reading that DHCP is a special case on pfSense, it is allowed with hidden rules that are activated when DHCP is used on an interface. (https://forum.netgate.com/topic/90384/help-clarify-my-understanding-of-the-net-link-bridge-pfil-tunables-please/3) I added firewall rule on LAN interface, allowing UDP on port 67 and 68 to pass and now DHCP is working.
MacOS OpenVPN clients are receiving DHCP offer from servers and get IP address without dhcrelay running. So I have found "a workaround" or finally have a proper configuration, whatever.
Adding firewall rules is the right way,
I'll close this PR.
But what about MacOS OpenVPN clients? How they can receive DHCP offer without firewall rules?
Updated by Ivars Strazdins about 4 years ago
Thing is - windows OpenVPN clients got DHCP IP address all along, with no fw rules and no dhcrelay running.
macOS clients only got DHCP IP address if either dhcrelay was running or fw rules were put in place.
Why windows can get IP but macOS cannot, I don't understand yet.
Updated by Jim Pingle about 4 years ago
- Category set to DHCP Relay
- Status changed from New to Rejected
DHCP Relay doesn't like to run on OpenVPN (any more?) See #8443
That may depend on specific OpenVPN modes/options, however. We might need to relax that restriction. But in cases like a bridged tap setup you wouldn't need to run DHCP relay on OpenVPN directly anyhow, so it's unnecessary.
This issue is a bit of a mess of unrelated info, so I'm closing it out. If it is determined that using DHCP relay on OpenVPN is required and a more accurate problem description can be formed with sufficient detail and means to replicate, then open a new issue with the corrected information.