I have a Cisco ASA 5505 that uses around 5 NICS for different networks. Currently I'm using my ASA to route traffic as it's the only Cisco device I have capable of the small amount of routing required by my network.
Keeping things separate I use 5 NICS for different networks such as outside, corp, printers, workstations, servers, and public. Each have a different subnet that I keep separate to control all the ACLs via the ASA firewall. Everything (such as DHCP with a SuperScope) works great with the exception of the WDS Server.
My question is, currently I have a new PC plugged into the workstations NIC LAN that is looking for my WDS Server which is located on the servers LAN. How can I get the requests from all the different NICs to flow to the servers NIC LAN?
I've never had much love for the ASA 5505 platform.. It's always seemed like a bit too "six of one, and half-dozen of the other" for me to find a use for it in any of my networks.
I've just spent the last half-hour reading a bunch of stuff about the possibility of "tricking it into routing".
So, it basically boils down to this.
same-security-traffic permit intra-interface
, andfixup protocol icmp
).Those last two commands hark back to the day when the ASA range was the PIX range.
If I was in your position, I'd get a separate router, and keep the ASA, or replace the whole lot with a significantly more capable firewall, which is actually able to route traffic.
As the guys on the Cisco forum have already mentioned to you, dhcp-relay should fix everything for the DHCP portion of WDS and so on.
The question remains about the rest of PXE. PXE is basically just DHCP and TFTP, which itself is a UDP-based service that runs on port 69.
Off the back of that.. have you tried setting a static NAT mapping for the WDS server on the interface in question, then point PXE at that with the
next-server
attribute?Might work, but in order to set up enough NAT zones, you'd probably need to do them as VLANs and therefore, need the Security Plus license (25 VLANS!), and then theoretically be able to just do plain-ol' inter-VLAN routing, but I suspect you might have sucky performance.
Without labbing it up (a bit of a pain, as the ASAs are a pig to emulate, and I don't have a 5505), it's difficult to come up with a more accurate answer.
More info:
next-server
is the ISC DHCPd's name for DHCP Option 66, as described here https://www.rfc-editor.org/rfc/rfc2132#page-25 as TFTP server name. It's the IP of the server where the TFTP server is located for PXE booting.Static NAT is that process which allows you to configure a translation between two IP addresses that sit on different networks, as described here.
Snap, Crackle, And Pop! Found out what it was all thanks to Tom for giving me some good ideas. I went to look into adding the DHCP option 66 to my scope options and thought to myself should I add it to the "servers" subnet scope options or the "workstations" subnet scope options... I then slapped myself in the forehead when I realized the (unrecognized) PC trying to get an IP from the DHCP server was getting an IP from the "unknown" subnet I created for well.. Unknown PCs.. :)
The way my subnets are broke up are as follows...
I have all of the address pools from each subnet locked down to NOT hand out any ips. The only subnet/scope that has available IPs is the "unknown" subnet. This way if I have a reserved IP in one of the other subnets the machine gets that one. If I don't it gets an IP on the dead/isolated/contained network (unknown). Well it just so happens I did a good job with all my ACLs and the unknown can't get to anything except the DHCP server and there is no routing/nats for the unknown network. So the PC was getting an IP but that's where it stopped.
Makes perfect sense and I would have never thought about it until Tom had me try something else. So THANKS TOM!!!
As for the answer to this question the answer should be using something like the following in your asa config would work just fine...
10.71.3.2 in this case would be my DC/WDS server. Setting "dhcprelay server 10.71.3.2 servers" allows that server to recieve the requests. "dhcprelay enable workstations" should be defined for EACH subnet/interface/scope that needs access to the DHCP server. "dhcprelay setroute workstations" as well should be defined for each (just as the enable lines are). Timeout was my preference.