Unable to get DHCP on WAN

  • Already posted this in the virtual subtread of the forum, but since my issue is actually DHCP, and I don't believe the virtualization itself to be the issue (DHCP works when requested from the LAN computers - Pfsense LAN NIC answers - which in turn makes it hard to believe switch or vmware config is wrong). So i take my chances and post it here as well as I believe this is a pfsense/isp-modem issue.

    VMware-host: HP Proliant DL585 G2

    Core-switch: D-Link DGS 1210-16 (VLAN's enabled: WAN_100, LAN_500, LAN_800, DMZ_200, iSCSI_400, MGMT_300)
    The VMware-host and the switch itself is resided in the VLAN 300 area, AKA: Management

    On the VMware-host the vswitch0 is defined with one single nic (I know this is not optimal - but I couldn't get around to drag 4 lan cables through the entire house, and out into the servere-room in the garage - one cable was enough! :-) - all VLAN's are defined as portgroups, named equal to the VLAN config on the switch)

    Btw; Im running ESXi 5.0 U1

    Pfsense 2.01 is installed on a local VM, and given 4 nics; WAN, LAN, LAN, DMZ

    LAN1 is defined as with DHCP enabled
    LAN2 is defined as with DHCP enabled
    DMZ is defined as with no DHCP
    WAN is defined as DHCP

    My ISP modem is bridged (Zyxel P2812) and connected to PORT1 (untagged member of WAN_100. Port 16 is tagged member)
    My LAPTOP is connected to PORT3 (untagged member LAN_500, PORT 16 is tagged member)
    MY PC is connected to PORT 10 (untagged member LAN_800, PORT 16 tagget member)
    My Management-pc is connected to port 15 (untagged member MGMT_300, PORT 16 tagged member)

    vSwitch0 is connected to vmnic0 which in turn is cabled to port 16

    OK, my results:

    LAPTOP gets DHCP from pfsense, and can communicate with PFsense WEBadmin
    PC gets DHCP from pfsense on the other VLAN
    Management-pc can administer both Switch and VMware-host, but ofcourse not the pfsense itself nor see the laptop or PC….

    So seems everything is working, except the KEY factor of having pfsense at all..... I have no internet..... because the WAN interface is stuck at

    So what to do? If I understand this correctly, pfsense will send a DHCP request, which eventually will hit the WAN_100 portgroup o vswitch0, get tagged with VLAN 100, and sent out on vmnic0, which in turn is connected to port 16, tagged member of WAN_100 VLAN on the switch. Untagged member here is Port1 so the request will exit here untagged and hit the Zyxel.... the response will inturn go back to the core-switch, get tagged with VLAN 100 and be routed back to VMware and the portgroup.... atleast it works this way for all the other vlans.... so why is DHCP for WAN not working?? There's nothing blocking DHCP reuests in my setup, as DHCP works from both VLAN 500 and VLAN 800....

    Seems to me the problem is either pfsense, or the Zyxel not receiving the packet, or responding correctly??

    Any ideas??

  • I actually just had this last night on a new install of 2.0.1

    Hardcoding the hostname into the client config, as well as cloning the MAC of an existing PC -> Saving -> Rebooting the modem seemed to work fine.

    I've also seen the FW drop the advertisements before where a rule was required (shouldn't be, but it did in that instance).

    Doing a tcpdump on the WAN interface should give you more details assuming the above doesn't work.


  • Just to verify the VLAN setup I've now successfully set up the Pfsense behind an old D-Link router using static IP….. Double routing is not optimal, but just in order to test the traffic-flow it works. The D-link receives DHCP from my ISP, and the pfsense is connected to this over the WAN interface with a static IP. Traffic flows and internet is reached.... So this atleast verifies that the VLAN and internal network is NOT the issue here.
    The pfsense is nevertheless not able to request DHCP directly from the ISP modem, nor directly from the D-Link.... so the problem is isolated to DHCP and just for the WAN interface (static IP works)..... Clients however connected to pfsense can request DHCP from the LAN interfaces just fine, so DHCP seems to work fine over the VLAN's and thru VMware's vswitch..... So why not for the WAN? Is TTL or anything handled differently with pfsense dhcp requests to WAN? I just cant seem to find the reason for this to not WORK, and it's pretty frustrating....

    Anyone having solved issues with WAN and DHCP, feel free to post your comments ;-)

  • I suggest you use packet capture at various interfaces along the path between pfSense WAN interface and DNCP server to verify the request and response is being passed on at each stage along the way.

    Also check the pfSense system log (Diagnostics -> System Log) for evidence of dhclient (DHCP client) activity.

  • I have now just run a couple of new tests n this system, and tcpdump shows that the WAN interface is sending DHCPRequests on the em0 interface with the virtual MAC of my WAN interface card, and Using Wireshark I have confirmed that the requests are located as traffic on PORT 16 (my trunk-port on the coreswitch, tagged with VLAN 100 - indicating that the requests are actually leaving the ESXi server and raching internal physical network - with correct source MAC and destination FF:FF:FF:FF:FF), and they are also showing in the captures from PORT 1, in untagged form (the port connected to my router). On PORT 1 i can also see DHCPOFFER packets, beeing broadcast from my router to FF:FF:FF:FF:FF, but not directly to the MAC of my pfsene WAN (em0 interface).

    The DHCPOFFER packets I can not recall seeing in the PORT16 TRUNK, and they never reach ESXi - this might be a coincidence, but I dont think so. - Seems Requests are sent all the way to port 1, but offers, are not sent back - they stay on PORT 1….. Thus, when using static IP connection works, so there is no issues with the VLAN setup - so I'm a bit confused as to why the offers are not trasfered over the VLAN to ESXi....

    Any IDeas?

  • OK, I feel i'm a little closer to success now, because I was just able to pull a DHCP from my internal D-link (it seems my switch had some default security settings that blocked the DHCP offers (broadcasts) from the dlink - turned that off, and voila), but this still gives me the same connection as running with static IP behind it, which means double NAT and double routers. - But now i KNOW DHCP works from pfsense via my switch and VLAN setup and thats a step forward.

    When trying to connect pfsense directly to my bridged modem (directly to my ISP which is my main goal), wireshark shows DHCP packets arriving, but there are no response. Since my modem is bridged, this is not dealing with DHCP, meaning that my DHCP requests from pfsense, are sent all the way to my ISP's internal network and their DHCP service. I don't know how many hops there are inbetween, but I'm a bit concerned that the short TTL=16 on pfsense's DHCP requests is getting them killed along the way…..

    Is there some way to increase the TTL of the DHCP Requests from PFsense WAN interface to something more recilient? maybe TTL=64 or TTL=128? That atleast will eliminate this as beeing the error....

    Feel the solution is right around the corner now..... almost there :-)

  • ANSWER:::::::::

    Hi had to create an account to lend a hand here!

    It's now 00:28 in the UK and after reading your 2 posts "an10bill" and hoping to find the answer when I started at about 13:00 today I thought you might want the solution:

    Carefull as you ARE going to KICK YOURSELF (I did!).

    Go to your managed switch,
    Look at the egress port to your modem/router that is supposed to be delivering your DHCP address,
    Notice the "T" (tagged packet) and change it to "U" (untagged packet),
    Now the packet can be understood and travel to all incompatible NICs.

    Our router, second in line to the satellite modem, packed in so I hadn't realised tagging was on as the old router could handle it. Only after not being able to get DHCP directly to PFSense and yet the Laptop could (like your scenario) did I eventually discover the subtle difference.

    Hope this helps anyone else so they dont end up on site after midnight!

    Midlands PC Engineers Ltd

Log in to reply