I had strange looking DHCP packets in my network as I tested around with DHCP relays on the Juniper SSG firewall. Some packets were blocked and I didn’t know why. After some troubleshooting it was clear that the checkmark “Use xy Zone Interface as Source IP for VPN” has a big impact in all environments even without the usage of a VPN!
I thought that a DHCP relay sends all its packets from its own IP address. Well, this was not true on the SSG firewall: By default the Juniper sends its DHCP relay agent packets with a source IP address from the interface that “looks” (routes) to the DHCP server and NOT from the real DHCP relay interface. Hmpf! Since I have another firewall between the Juniper and the DHCP server in place, I needed two unidirectional rules on that firewall. Not good.
After playing around with the “Use xy Zone Interface as Source IP for VPN” option inside the DHCP relay agent configuration on the GUI, I got the right configuration: This checkmark configures that the DHCP relay messages are sent from this interface IP address and not from any other address. This is how I thought it would be the default.
Lesson learned: Always check this option when configuring DHCP relays on the SSG!
Correct Configuration
(Note: Do not forget the “permit” security policy from the whole DHCP-enabled network zone to the DHCP server with service “DHCP-Relay”.)
Inside the GUI (Use xy Zone Interface as Source IP for VPN):
Through the CLI (note the second command):
set interface ethernet0/5.10 dhcp relay server-name "192.168.120.10" set interface ethernet0/5.10 dhcp relay vpn set interface ethernet0/5.10 dhcp relay service
And centralized through NSM. Here it is called “Enable VPN Encryption“. (Oh oh, what an unclear description!):
Screenshots without the correct Checkmark Setting
This is how the DHCP request packet looks like when it is sent from the interface that points to the DHCP server. It has an DHCP value “Relay agent ip address” with its real DHCP relay interface IP address:
That is: The intermediate firewall needed two security rules since the answer packet was sent in a new session from the DHCP server to the real DHCP relay interface IP address.
This is the DHCP server log (isc-dhcp-server) which reveals that the Relay agent was the real DHCP relay interface (first line “via 192.168.110.1″) though the packet arrived from a different layer 3 IP address:
Aug 1 13:47:10 jw-nb10 dhcpd: DHCPDISCOVER from 00:0c:29:8f:15:d3 via 192.168.110.1 Aug 1 13:47:11 jw-nb10 dhcpd: DHCPOFFER on 192.168.110.65 to 00:0c:29:8f:15:d3 (jw-vm04) via 192.168.110.1 Aug 1 13:47:11 jw-nb10 dhcpd: DHCPREQUEST for 192.168.110.65 (192.168.120.10) from 00:0c:29:8f:15:d3 (jw-vm04) via 192.168.110.1 Aug 1 13:47:11 jw-nb10 dhcpd: DHCPACK on 192.168.110.65 to 00:0c:29:8f:15:d3 (jw-vm04) via 192.168.110.1