05-23-2011 04:30 AM
Has anyone successfully implemented this?
I've used NSMXpress to configure an Autokey VPN between an SRX210 branch firewall and an SRX240 cluster as the hub device. The VPN establishes ok across a layer 3 routed and I can successfully ping between the two 'protected resources' networks.
I now want to deploy a central dhcp server for easier management of dhcp but I can't get dhcp allocation to work over the VPN. I have added the DHCP Relay agent to the LAN interface of the Branch SRX210 but when I monitor the traffic on the WAN interface of the Branch device I can see 'bootps' requested being passed from the WAN side mac address to the mac address of the next upstream device (a router). I wouldn't expect to see these if the dhcp request was encapsulated inside the VPN tunnel.
I found an article on the Juniper KB called "DHCP Overview - JUNOS Software Administration Guide for Security Devices" (see link http://www.juniper.net/techpubs/software/junos-sec
In the DHCP Relay agent section this article says "A J Series or SRX Series device operating as a DHCP relay agent forwards incoming requests from BOOTP and DHCP clients to a specified BOOTP or DHCP server. Client requests can pass through virtual private network (VPN) tunnels."
But in the Interface Restriction section it says "The device supports DHCP client requests received on any Ethernet interface. DHCP requests received from a relay agent are supported on all interface types.
DHCP is not supported on interfaces that are part of a virtual private network (VPN)."
The document seems to contradict itself but if the very last line is true it would explain why my dhcp setup doesn't work.
If I set up a dhcp server and pool on Branch SRX210 it works as expected but it means having to administer a dhcp pool at each branch location.
05-23-2011 05:54 AM
Did you use the following option to encapsulate traffic inside the vpn?
set forwarding-options helpers bootp vpn
I'm sure it must be working. The phrase about VPNs and DHCP is misleading, I think they have meant L2/L3 MPLS VPN.
05-23-2011 06:55 AM
Thanks for the response.
I was already using that option but it doesn't fix the problem.
When you edit the device configuration within NSMXpress (Forwarding Options > Helpers > Bootp) there's a tick box for Vpn and also for the Relay Agent Option. I tried with both of these boxes ticked and then ticked individually but without success.
Then under the Bootp option there's an Interface tab. When you add the interface that is handling the dhcp relay there's yet another tick box for 'Vpn' as a option at the interface level. I've tried ticking that box also but it didn't help and I don't know what that one translates into as a CLI level command/option.
By the way, I'm using Junos 10.2R3.10 which was the latest version recommended by Juniper.
05-23-2011 07:07 AM
This is the correct config for dhcp relay that sends traffic to a tunnel (btw, 192.168.100.1 is
resolved via route-based vpn, do you have the same in your case?):
lab@jsrx# show forwarding-options
Note that interface ge-0/0/1.201 is an interface on which client DHCP requests are received,
is it what you call "interface that is handling the dhcp relay"?
I think you should check your config using CLI. As far as I can see, "vpn" option is only available
in one place of the config, not sure why there are multiple in NSM. I'm also using 10.2R3, btw.
05-23-2011 09:17 AM
I'm using a policy-based vpn rather than a route-based one. I went for this option because there is only one subnet at each site.
From KB4124 ...
Common Reasons to use a Policy-based VPN:
- Need to access only one subnet or one network at the remote site, across the VPN
Also, when I configure the vpn in NSMXpress it automatically chooses the termination points as the interfaces where the protected resources subnets connect (or the "LAN" side) on each site. When this happens the vpn tunnel fails to establish and to get around this I have to manually edit the vpn termination points and specify the "WAN" sides of the SRX devices. I'm beginning to wonder if that's part of the problem.
My config from the Branch device is:
The second 'vpn' statement appears if I tick the vpn box within the interface (as mentioned earlier) but dhcp allocation fails both with and without it.
In the config above I have specified the "LAN" side interface (ge-0/0/1.0) as the dhcp helper interface and dhcp allocation fails but it also fails if I move the helper to the "WAN" side interface (ge-0/0/0.0) where the vpn terminates.
I've tried various combinations and nothing seems to work. When I monitor the interfaces it seems that the dhcp request is always outside the tunnel (because I can see the L2 request and associated mac addresses).
This makes me think that Juniper's statement "DHCP is not supported on interfaces that are part of a virtual private network (VPN)." is valid!
05-23-2011 11:08 AM
No, you are not right - dhcp relay over vpn is generally a working feauture, and it works in my lab.
I posted the relay config before, and server config has no tricks at all.
The only difference from your setup is that I use route-based vpn and dhcp traffic to the server is forwarded to the tunnel with no problems in this case. I am not sure if it can be done with policy-based setup, but the problem is just to direct the dhcp request to the tunnel...