dhcprelay / EasyVPN / PIX501

[cscherb]

Hi,

does anybody know if it is possible to configure PIX 501 running as Easy VPN Client in network extension mode to relay DHCP requests to a central DHCP server which can be reached via the VPN tunnel ?

I didn't manage to get this up and running, but discovered the following:

a)

IPs behind the VPN tunnel can only be "pinged" from the inside interface of the PIX 501

b)

Configuring "dhcprelay enable inside" and "dhcprelay server w.x.y.z inside" failed as the relay agent did not do anything [no debug output]. Configuring "dhcprelay enable inside" and "dhcprelay server w.x.y.z outside" is doing somthing ("debug dhcprelay ..." is showing some action) but I am afraid of a) that the packets will not go to the DHCP server behind the vpn tunnel.

any ideas ... ?

Carsten

[gfullage]

It does work, but there's a bug with 6.3(1) and lower where it dosn't work if you have "management-access inside" configured.

The bug is detailed here:

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCea64707&Submit=Search

Upgrade to 6.3(3) and retry if this is your problem. BTW, the second way you had it configured is correct. Should look something like this:

dhcprelay server 192.168.1.1 outside

dhcprelay enable inside

dhcprelay setroute inside

vpnclient server 1.1.1.1

vpnclient mode network-extension-mode

vpnclient vpngroup password ********

vpnclient enable

[cscherb]

Hi Glenn,

thanks a lot !

After changing the configuration as mentioned the PIX 501 is relaying the DHCP packets. :-)

Unfortunatly our central firewall which is sitting behind our VPN3030 concentrator is rejecting the packets ("reverse path check failed") because PIX 501 is using the IP-addresse of the external interface as the source address for the relayed DHCP requests.

Is there any chance to "convince" the PIX501 to use the IP address of the inside interface as source address for DHCP relay ?

[gfullage]

No, you can't make it do this, sorry.

The "reverse path check failed" error means that your central firewall has a route for the outside IP of the 501 (probably just the default route) pointing out some other interface than the one it's receiving the DHCP packets on. You should be able to simply add a host specific route for the 501's outside interface to this PIX and point it out the interface towards the 3000. This means that from now on, if you try and ping/telnet/ssh to the outside of this 501 you'll get routed thru the 3000 and go over the VPN tunnel, but that should be fine.

[cscherb]

... unfortunatly the PIX501 is getting the IP on the outside interface dynamicly via PPPoE.

[thethmon]

I am facing the exact same problem. Hopefully Cisco will quickly give us the option of having the relay sourced from the Inside interfaces and pushed across the VPN tunnels.

[cscherb]

Great to know that some else is facing the same problem.

Meanwhile I talked to our Cisco SE and asked him if it is possible to place an appropriate feature request. I will post the response here.

[shifter]

I've tried this configuration in my setup which seems to be same as the original poster with no luck.

The relay agent sees the request on the inside of the PIX 501, but a packet never makes it to the specified dhcp server behind the other PIX.

Are there any other things that may prevent this from working?

I have 6.3(3) on both PIX and have tried with and without manage inside on the 501.

TIA

[hannelanesskog]

Hi !

I have never tried relaying through a VPN tunnel before, but should'nt relaying always use the IP address of the interface wich received the DHCP request ? how else would the dhcp server know to wich network it should lend an IP address ? :-)

Anyway:

Make sure there is a nat 0 statement telling the pix not to nat the relay... that would explain why itæs using the outside interface address :-)

Best regards,

Jorgen Lanesskog

Ementor

[cscherb]

Hi Jorgen,

DHCP server knows to which network it should lend an IP address by the information in the data part of the IP packet, not by the source IP addres. (see "giaddr" in RFC 2131 - ftp://ftp.rfc-editor.org/in-notes/rfc2131.txt).

Meanwhile I talked to some Cisco SEs and they confirmed this behaviour to me (IP source address = outside IP; giaddr= inside IP).

The problem in my case is a PIX firewall between the VPN-tunnel endpoint (vpn3000) and the DHCP server. As the reverse path check failed (public IP as source adress in IP-packet) the packets are discarded. There seems to be no other option as to disable the reverse path check.

Best regards

Carsten