1
22.1 Legacy Series / Re: dhcp-relay over OpenVPN-tunnel
« on: May 16, 2022, 02:17:27 pm »
I apologize for the long delay, we could not test this again on this particular firewall. Today I am having the same problem with an identical setup - unfortunately we have to ship this firewall this evening, so I am unable to debug this further. With the current shortage of firewall hardware we are not able to set up a more permanent test environment for the time being.
Anyway, I tried to gather some more information.
The DHCP request is received on the LAN interface:
# tcpdump -ni igb0 port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:03:53.391100 IP 10.0.192.2.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:c0:de:ca:fe, length 316
It is then sent on over the VPN tunnel to the DHCP-server by the relay agent, and is answered correctly:
# tcpdump -ni ovpnc2 port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpnc2, link-type NULL (BSD loopback), capture size 262144 bytes
14:03:53.391159 IP 10.0.192.1.67 > 10.8.0.64.67: BOOTP/DHCP, Request from de:ad:c0:de:ca:fe, length 324
14:03:53.415025 IP 10.8.0.64.67 > 10.0.192.1.67: BOOTP/DHCP, Reply, length 320
If I check the answer packet with wireshark, I see only correct information there (ip, dns-servers, gateway, as configured on the DHCP server).
But this answer is then never forwarded back to the requesting client by the relay agent.
I do not see any blocked packets, and can´t seem to find a relevant log. Also, the dhcprelay-binary does not seem to offer more verbose logging or a debug mode.
Our current workaround is to use DHCP directly on the opnsense, but this is not a permanent solution. Any ideas would be welcome.
Thanks
Urban
Anyway, I tried to gather some more information.
The DHCP request is received on the LAN interface:
# tcpdump -ni igb0 port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:03:53.391100 IP 10.0.192.2.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:c0:de:ca:fe, length 316
It is then sent on over the VPN tunnel to the DHCP-server by the relay agent, and is answered correctly:
# tcpdump -ni ovpnc2 port 67 or 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ovpnc2, link-type NULL (BSD loopback), capture size 262144 bytes
14:03:53.391159 IP 10.0.192.1.67 > 10.8.0.64.67: BOOTP/DHCP, Request from de:ad:c0:de:ca:fe, length 324
14:03:53.415025 IP 10.8.0.64.67 > 10.0.192.1.67: BOOTP/DHCP, Reply, length 320
If I check the answer packet with wireshark, I see only correct information there (ip, dns-servers, gateway, as configured on the DHCP server).
But this answer is then never forwarded back to the requesting client by the relay agent.
I do not see any blocked packets, and can´t seem to find a relevant log. Also, the dhcprelay-binary does not seem to offer more verbose logging or a debug mode.
Our current workaround is to use DHCP directly on the opnsense, but this is not a permanent solution. Any ideas would be welcome.
Thanks
Urban