Hi,
I'm struggling with a pix 501 here that i would like to provide dhcp information to its clients but set the default gateway to a different router on the inside subnet.
It seems the pix automatically inserts its own address and also ignores attempts to manually alter this behaviour with a "dhcpd option 3 ip ..." statement.
Anyone here who knows a way around that limitation? (OS is 6.2(2)).
Many thanks in advance
-Chris
In article , Christian Winter wrote: :Christian Winter wrote: :> I'm struggling with a pix 501 here that i would like to provide :> dhcp information to its clients but set the default gateway :> to a different router on the inside subnet.
: (OS is 6.2(2)).
:But when I try to do the same for a bigger net the dhcpd :behaves out of line: :PIX1(config): dhcpd option 249 ip 7.192.0.0 172.20.1.254 :results in dhcpd no longer providing a default gateway to :the client and setting client netmask to 255.0.0.0.
:Is that normal/expected/buggy behaviour?
On PIX 6.2 and 6.3, there is no defined behaviour for dhcpd option 249, so being able to enter it at all should be considered a bug.
The only defined options are 66 and 150, both of which have to do with TFTP, and are designed for use with IP Phones.
:> I'm struggling with a pix 501 here that i would like to provide :> dhcp information to its clients but set the default gateway :> to a different router on the inside subnet.
I suggest you have that "different router" handle the DHCP instead of the PIX. The PIX is not intended to be a sophisticated DHCP server.
Trying to work around that i encountered something strange: When i add a static route (Class C) for the clients it works fine: PIX1(config): dhcpd option 249 ip 24.192.168.21 172.20.1.254
But when I try to do the same for a bigger net the dhcpd behaves out of line: PIX1(config): dhcpd option 249 ip 7.192.0.0 172.20.1.254 results in dhcpd no longer providing a default gateway to the client and setting client netmask to 255.0.0.0.
Is that normal/expected/buggy behaviour?
TIA
-Chris
IMHO it would also not be too much to ask to let the user override the default behaviour by setting option 3...
The problem is this router is not under our control, so the only simple solution (without changing or adding hardware) would be to use a dhcp server on the "outside" interface. Seems we'll have to bite into the sour apple and buy an upgrade to 6.3 to get dhcprelay functionality.
Thanks very much for taking your time
-Chris
In article , Christian Winter wrote: :Yes, seems Cisco is behaving like all the other manufacturers :here, trying to keep functionality low to urge users to step up. :If the implementation was clean the pix would allow to set "private" :dhcp option values and not try to be smart and interfere with it.
Then the PIX would have to be able to parse all of the possible DHCP option formats, including knowing which ones were strings, which were IPs, which are a mix, which are lists of values...
Even if you look at IOS you will find that Cisco does not implement sophisticated DHCP services: by the time you need those additions then you would generally put a different device on the net to act as the server.
:> I suggest you have that "different router" handle the DHCP instead of :> the PIX. The PIX is not intended to be a sophisticated DHCP server.
:The problem is this router is not under our control, so the only :simple solution (without changing or adding hardware) would be to :use a dhcp server on the "outside" interface.
So add hardware? You can probably find someone willing to literally
-give- you a Pentium 2 133 or 266 MHz; that and linux or BSD would give you full control.
:Seems we'll have to :bite into the sour apple and buy an upgrade to 6.3 to get dhcprelay :functionality.
I suggest you review the PIX Security Advisories. Your 6.2(2) is quite out of date, and you are entitled to a free upgrade to at least
6.2(5). If I recall correctly, someone mentioned that they had been able to get a free upgrade from 6.2 to 6.3 by pointing to a documented security problem that had not been fixed in 6.2. Once you are in 6.3, you are entitled to free upgrades to 6.3(4) due to security problems. The latest 6.3 is 6.3(5), which is a bugfix release, not a security release, so you might only be able to get to 6.3(4) for free.
I don't think so, as the type of value is given with the option command. That should be enough for the pix to know.
[...]I considered that, the point for using a pix is hardware reliability. I've had to deal with far too many old PC systems crashing already, and I certainly don't want to explain to the users why the newly built network segment went down after just a few days :-)
Maybe i could if the cisco pix licensing website worked. At least for the last two days i only got error messages (that "we are moving over to a new website" thing) when trying to browse there. But the security issue is a good point. I'll look into that and try to push my reseller a little.
Again many thanks
-Chris
:I suggest you review the PIX Security Advisories. Your 6.2(2) is :quite out of date, and you are entitled to a free upgrade to at least :6.2(5).
Make that 6.2(4) as the latest official release. But see
Have something to add? Share your thoughts — no account required.
Ask the community — no account required
