Problems with DHCP relay agent

[watts3000]

Guys I am having some problems getting DHCP relaying to work using PF I am using a Windows 2012 server as my DHCP server. I have 3 scopes on the DHCP server the main lan is 10.1.1.x and the tww dev networks I use are 192.180.1.x and 192.180.2.x. I have gone into the DHCP relay settings and selected both interfaces being 192.180.1.x and 192.180.2.x. The 192.180.1.x works perfectly but I can't pull DHCP to the 192.180.2.x network. So I would like to know has anyone here had problems relaying to multiple networks using PF? I have even tweaked firewall rules to all all udp still a no go.

[johnpoz]

Bit of a side note but is 192.180 a typo and you meant 192.168?  192.180 is a public IP space, or are you

OrgName: Time Warner Cable Internet LLC

That space is owned by them…

First step I would take in such an issue is sniff to see if the stuff is being relayed..  Simple enough to just sniff on the interface pfsense should be sending this on to your dhcp server on and verify the relay happens.  Without that info you don't know if its a problem on the pf side or the dhcp server side, etc.

[watts3000]

I'm running Pfsense in a virtual environment using ESXI so can you talk a little more about capturing packets. I know I can load wireshark on a laptop or a test vm and capture there. However, I'm not up to speed on what you are suggesting.

http://www.petri.co.il/using-packet-analyzer-on-virtual-network.htm

[johnpoz]

pfsense has it own packet capture under diagnostics menu.. Just pick the pfsense interface you want to capture on, or just ssh to pfsense and run tcpdump directly.  ssh to it multiple times if you want to run concurrent captures all at the same time..

What does pfsense running on esxi have to do with using 192.180?  ;)

I run my pfsense on esxi as well..  Doesn't mean I grab public IP space and use when its not mine ;)  When there is plenty of rfc1918 space to use..

But this can be done quite simple with the built in packet capture..  First I would capture on the interface your expecting the dhcp discover on..  Do you see the discover?  What else do you see if anything for dhcp?  Do you see an offer come back?  What is in the offer.  You can download the packet captures and view in wireshark for example to see all the details in the dhcp packets.

If you see the discover, but nothing else - capture on the interface that pfsense is suppose to be sending the (relay) them on to your dhcp server.  Do you see the discover get forwarded.. Do you see any offers coming back?  If not then validate that the info in the relayed packet is correct..  If so then validate on your dhcp server that it is seeing the packets with a capture on that box.. Wireshark is your friend!!  If your dhcp server is seeing the packets and they have the correct info in them - why is it not answering, etc.

If need be I can show you how this would work and how the captures look, etc. with pictures from my own network..

[watts3000]

Thanks for replying to my topic btw I'm using 192.170.x.x not 192.180.x.x. The problem was a misconfiguration with one of the virtual nics. I have a trunk that runs to my esxi box and the pf vm has 4 vnics connected to it. The nic that was serving the segment that dhcp was not working on was connected to the wrong vnic.  Actually I had two vnics connected to the same vlan.  However, I noticed something real strange and I wonder if it was because I had my 192.170.2.x network nic sharing the same vminc as my 10.1.1.x network which is my actual lan. All of a sudden wifi stopped working on my iphone I looked on my dhcp server and my ipphone actually pulled an address from the scope the 192.170.2.x scope this is the same scope that I could not get an address from due to a misconfigured vnic. The access point is using 10.1.1.x network so technically it should only pull dhcp from that subnet so I'm assuming it was because of the misconfiguration. Anyway I would like to hear your thoughts on the subject.

[johnpoz]

Again why are you using 192.170??  that is a public IP..

Are you
OrgName:        Hewlett-Packard Company

dhcp discover is a broadcast FFFF.FFFF.FFFF.FFFF any dhcp server that hears that broadcast will send an offer..  If you run multiple networks on the same physical network then yes that can happen.

[watts3000]

Thanks for all of your help I'm going to do some research on what companies have what IP blocks.

[johnpoz]

Dude you can not just pull IP addresses out of thin air and use them ;)

There are specific ranges to use on your networks..  RFC1918, this should get you started http://en.wikipedia.org/wiki/Private_network

10.0.0.0/8
192.168.0.0/16
172.16.0.0/12

There should be NO reason what so ever to be using 192.170.x.x anywhere on your network = unless your actually the owner of that network.  Even then you would think those would be used on the edge of your network, not really internally.

Here's the thing, its not going to break the internet if you happen to use public IP space on your network.. But what it can do is cause you not to get someone where on the internet that you might want to go.. For example in this case an HP site..  Since your machines think that network is local..

There are 17+ million addresses available using rfc1918 space, there is no reason to use public space on your internal networks.  And its confusing to people when trying to help you when you say your network is x.x that is public space..

[kpa]

I recommend using 10.x.y.0/24 subnets where x and y are numbers of your own choise. There are 65536 different combinations of x and y to choose from and you're not likely to collide with the subnet of someone else. This can be very important if you ever have to build a fully routed site to site VPN tunnel with someone else and you don't have control over what the other guy's addresses are. Also you'll be avoiding the more commonly used 192.168.x.0/24 networks where there are only 256 different subnets.