VLAN won't pick up IP via DHCP



  • Hi,

    Im trying to get my VLAN config working on my homecennection with no luck. Will use 1 NIC with 2 vlans to my 2 WAN's.

    My switch is a HP ProCurve 1800-8G which is configured like this:


    NIC is Intel PRO/1000 GT, connected to port6.

    OPT1 is enabled and type is set to DHCP, but isn't assigned an IP.

    What am I doing wrong here?



  • omg.. been trubleshooting for 2 hours and i forgot to add port1 to vlan10,20,30.. :D

    EDIT: Hm, still won't assign an IP via dhcp from isp :/



  • Did you set a 'pass' firewall rule on the VLAN interface?



  • @Kevin:

    Did you set a 'pass' firewall rule on the VLAN interface?

    Pass on what..?



  • Alright. I reconfigured some stuff and the image's in first post is wrong from the very beginning..

    im getting really frustrated about this, why isn't this working? Please read the first post, but don't mind about the pictures, then back to this post. This is my test-setup;

    D-Link switch Port1 -> WAN (5x IP-addresses via DHCP)

    D-Link switch Port2 -> To HP switch Port1 (VLAN10)
    D-Link switch Port3 -> To HP switch Port2 (VLAN20)
    D-Link switch Port4 -> To HP switch Port3 (VLAN30)

    HP switch Port5 (VLAN10+20+30) -> pfSense WAN-NIC.

    (HP switch Port4 is VLAN40, and Port6,7,8 is VLAN1 -> Cable in Port8 is for switchconfiguration).

    Switchconfiguration:

    WAN-NIC is now a Intel PRO 1000/MT dual Gbit.

    em0 is setup with em0_VLAN10 as WAN and em1 as LAN. It does not get assigned an IP (just getting 0.0.0.0). When reconfiguring WAN to 'em0' instead of em0_VLAN10 it instantly gets an IP.

    Anyone?



  • Because you did not set the default PVID on the HP switch to tag on ingress with the respective VLAN IDs.

    OR:  you did not untag on egress since the Dlink and the WAN connection presumably doesn't support VLANs.





  • @Perry:

    Might help http://pfsense.site88.net/mysetup/index.html

    Superb, don't think i could find a better guide ;) However, my lab-setup died right before I was about to assign interfaces, dead sectors on harddrive :D great timing.



  • Alright. Half way working :)

    vlan_10 is getting IP,  when adding vlan_20 via the webgui (vlan 10 and 20 is configured exatcly the same) it fails.

    EDIT: Did some research. Did a factory reset and added vlan_20 as WAN instead of vlan_10 to find out if the vlan_config was wrong. vlan_20 instantly got an IP. When adding a second interface (based on another vlan) it wont get an IP.

    Jan 20 20:35:56	dhclient[14685]: DHCPREQUEST on em0_vlan20 to 255.255.255.255 port 67
    Jan 20 20:35:56	dhclient: ifconfig em0_vlan20 inet 85.XXX.XXX.111 netmask 255.255.240.0 broadcast 85.XXX.XXX.255
    Jan 20 20:35:56	dhclient: New IP Address (em0_vlan20): 85.XXX.XXX.111
    Jan 20 20:35:56	dhclient: New Subnet Mask (em0_vlan20): 255.255.240.0
    Jan 20 20:35:56	dhclient: New Broadcast Address (em0_vlan20): 85.XXX.XXX.255
    Jan 20 20:35:56	dhclient: New Routers (em0_vlan20): 85.XXX.XXX.1
    Jan 20 20:35:56	dhclient: Adding new routes to interface: em0_vlan20
    Jan 20 21:36:04	dhclient[39567]: DHCPREQUEST on em0_vlan20 to 255.255.255.255 port 67
    Jan 20 21:36:04	dhclient: ifconfig em0_vlan20 inet 85.XXX.XXX.111 netmask 255.255.240.0 broadcast 85.XXX.XXX.255
    Jan 20 21:36:04	dhclient: New IP Address (em0_vlan20): 85.XXX.XXX.111
    Jan 20 21:36:04	dhclient: New Subnet Mask (em0_vlan20): 255.255.240.0
    Jan 20 21:36:04	dhclient: New Broadcast Address (em0_vlan20): 85.XXX.XXX.255
    Jan 20 21:36:04	dhclient: New Routers (em0_vlan20): 85.XXX.XXX.1
    Jan 20 21:36:04	dhclient: Adding new routes to interface: em0_vlan20
    
    Jan 20 21:46:27	dhclient[36369]: DHCPDISCOVER on em0_vlan10 to 255.255.255.255 port 67 interval 1
    Jan 20 21:46:28	dhclient[36369]: DHCPDISCOVER on em0_vlan10 to 255.255.255.255 port 67 interval 1
    Jan 20 21:46:29	dhclient[36369]: DHCPDISCOVER on em0_vlan10 to 255.255.255.255 port 67 interval 2
    Jan 20 21:46:31	dhclient[36369]: DHCPDISCOVER on em0_vlan10 to 255.255.255.255 port 67 interval 2
    Jan 20 21:46:33	dhclient[36369]: DHCPDISCOVER on em0_vlan10 to 255.255.255.255 port 67 interval 2
    Jan 20 21:46:35	dhclient[36369]: DHCPDISCOVER on em0_vlan10 to 255.255.255.255 port 67 interval 5
    Jan 20 21:46:40	dhclient[36369]: DHCPDISCOVER on em0_vlan10 to 255.255.255.255 port 67 interval 6
    Jan 20 21:46:46	dhclient[36369]: DHCPDISCOVER on em0_vlan10 to 255.255.255.255 port 67 interval 9
    Jan 20 21:46:55	dhclient[36369]: DHCPDISCOVER on em0_vlan10 to 255.255.255.255 port 67 interval 16
    Jan 20 21:47:11	dhclient[36369]: DHCPDISCOVER on em0_vlan10 to 255.255.255.255 port 67 interval 7
    Jan 20 21:47:18	dhclient[36369]: DHCPDISCOVER on em0_vlan10 to 255.255.255.255 port 67 interval 10
    Jan 20 21:47:28	dhclient[36369]: No DHCPOFFERS received.
    Jan 20 21:47:28	dhclient[36369]: No working leases in persistent database - sleeping.
    Jan 20 21:47:28	dhclient: FAIL
    

    As described, I got 5 IP's from my ISP. "NO DHCPOFFERS received" is strange, the second I put another computer right in the switch connected to ISP, it gets assigned an IP..

    Any clue?



  • Maybe your pfSense VLAN interfaces have the same MAC address and the ISP DHCP server is ignoring what appears to be a duplicate request. What is the output of the pfSense shell command ifconfig -a ?

    MAC addresses of VLANs can be configured through the web GUI. You could try leaving VLAN10 with default MAC address (MAC address of parent physical interface) and assigning VLAN20 the MAC address of another physical interface on the system (say the LAN interface).



  • @wallabybob:

    Maybe your pfSense VLAN interfaces have the same MAC address and the ISP DHCP server is ignoring what appears to be a duplicate request. What is the output of the pfSense shell command ifconfig -a ?

    MAC addresses of VLANs can be configured through the web GUI. You could try leaving VLAN10 with default MAC address (MAC address of parent physical interface) and assigning VLAN20 the MAC address of another physical interface on the system (say the LAN interface).

    Yes, that was my first thought. What I did was that I borrowed the MAC from "em0" which is 00:04:23:bd:97:2c. Then via the interface-settings I used this MAC but chaged the last digit. Still no luck :(



  • Did you restart pfSense after saving the configuration? I've found some pfSense configuration changes don't seem to take effect until a restart.

    Have you done a packet capture to verify the configuration changes?

    Have you called your ISP's technical support to see why they are (apparently) not responding to the DHCP request on the second VLAN?



  • @wallabybob:

    Did you restart pfSense after saving the configuration? I've found some pfSense configuration changes don't seem to take effect until a restart.

    Have you done a packet capture to verify the configuration changes?

    Have you called your ISP's technical support to see why they are (apparently) not responding to the DHCP request on the second VLAN?

    Yes I have restarted several times :) There is nothing wrong with my ISP since the second after a configure the not used internal NIC(re0) with no vlan it works right away.

    As said, after "reset to defaults", when choosing interfaces for wan and lan, any vlan will work but adding a second one it fails. :o



  • @w00t:

    There is nothing wrong with my ISP.

    I wasn't intending to suggest there was something wrong with your ISP. I was suggesting that if you have a conversation with technical support at your ISP someone might be prepared to tell you what they are seeing at their end and why the ISP equipment is behaving the way it is.

    I am suspicious that the DHCP requests from the two VLANs get sent with the same source MAC address despite your efforts to configure different addresses. If you are prepared to test that theory then your ISP might help or you might be able to setup an external packet capture system to see what actually goes out over the wire. It might also be worthwhile to try the VLANs on the re0 physical interface to see if you get a different outcome with a different device driver involved.

    I have assumed your two WAN links are to the same ISP. Is that assumption correct?



  • @wallabybob:

    @w00t:

    There is nothing wrong with my ISP.

    I wasn't intending to suggest there was something wrong with your ISP. I was suggesting that if you have a conversation with technical support at your ISP someone might be prepared to tell you what they are seeing at their end and why the ISP equipment is behaving the way it is.

    I am suspicious that the DHCP requests from the two VLANs get sent with the same source MAC address despite your efforts to configure different addresses. If you are prepared to test that theory then your ISP might help or you might be able to setup an external packet capture system to see what actually goes out over the wire. It might also be worthwhile to try the VLANs on the re0 physical interface to see if you get a different outcome with a different device driver involved.

    I have assumed your two WAN links are to the same ISP. Is that assumption correct?

    Ah, my bad. Missunderstood :) Sorry for late answer, havn't had the time to investigate, maybe today or later this week I will try again. I will try to make some VLAN interfaces with different mac via ssh instead of via webUI. Tho im quite the newbie regarding *bsd, anyone who could assist with the commands? ~new vlan interface -> vlan10 -> MAC.

    I will also try assign em0 vlan10 and re0 vlan20, totally forgot that. That will probably tell if I having problems with spoofed MAC-addresses. I'm not that familiar with for example wireshark, not sure exaclty what to look for (probably dhcp-traffic on port 67 :)), will try to sort things out before putting up an extra machine.

    Yes, at the moment I only trying with 2 WAN's. I got 5 "WAN"'s from the same ISP with the same Gateway (5 IP-addresses assigned via DHCP).

    Offtopic: Anyone with a nano version of 1.2.3 with vga+keyboard support? :) Found a version made by Hacom but the links are dead.



  • Found this thread: http://forum.pfsense.org/index.php/topic,44719.0.html

    Might be the same "problem" then.



  • If you get a way of having your public IP addresses assigned to distinct pfSense (WAN?) interfaces what will you do with them? It hasn't yet occurred to me how that would be useful.

    Some challenges to getting multiple VLAN interfaces assigned an IP address by DHCP from the same server.

    1. If this succeeds all interfaces will probably be on the same network. Is that useful?

    2. The VLAN interfaces default to having the MAC address of the parent physical interfaces. If there are multiple VLANs on the same physical interface then DHCP requests from multiple VLANs will have the same source MAC address and be indistinguishable to the server.

    3. The pfSense VLANs can be configured with specific MAC addresses which would allow DHCP requests from different VLANs on the same physical interface to have different source MAC addresses and so distinguishable by the DHCP server.

    4. I don't know if all FreeBSD NIC drivers and the VLAN support code correctly conspire to insert the VLAN specific MAC address in traffic from a VLAN.

    5. Anecdotal evidence suggests that at least some NIC drivers DO NOT configure the hardware to accept frames destined to ALL configured VLANs on the device. In this case a DHCP response sent to the MAC address configured in a VLAN will be ignored (because it isn't sent to the physical MAC address of the NIC). A workaround is to set the NIC into promiscuous mode (accept all incoming frames, regardless of the destination MAC address). Promiscuous mode can be set by the shell command ifconfig <interface>promisc</interface> or by running a packet capture on the interface (e.g. shell command tcpdump). These methods won't survive a system restart. A longer lived method (which I haven't tried) might be to (in the pfSense GUI) configure a bridge with a single member, the appropriate physical interface, and enable the bridge interface.



  • @wallabybob:

    If you get a way of having your public IP addresses assigned to distinct pfSense (WAN?) interfaces what will you do with them? It hasn't yet occurred to me how that would be useful.

    1. If this succeeds all interfaces will probably be on the same network. Is that useful?

    Oh, I didn't describe why in this thread.

    What I got to my home-connection,

    • Fiber-converter to switch.

    • 5x external IP'addresses assign via DHCP from ISP.

    • Same gateway.

    • 100Mbit download.

    • 10Mbit upload per IP (in other words, 5x10Mbit upload simultaneously).

    With pf1.2.3 what I did was to create a pool of all 5x IP-addresses and then loadbalance, monitoring only WAN0's gateway. Resulting in a shared 100Mbit download and 50Mbit upload with say torrents and other things using multiple connections.

    The only purpose is to boost my upload, no failover and such.

    I will try configure the NIC in promiscuous mode, based on your answer and the thread I linked. I will be reporting back on thursday if it works or not, from then figure out a sustainable configuration.



  • @wallabybob:

    5. Anecdotal evidence suggests that at least some NIC drivers DO NOT configure the hardware to accept frames destined to ALL configured VLANs on the device. In this case a DHCP response sent to the MAC address configured in a VLAN will be ignored (because it isn't sent to the physical MAC address of the NIC). A workaround is to set the NIC into promiscuous mode (accept all incoming frames, regardless of the destination MAC address). Promiscuous mode can be set by the shell command ifconfig <interface>promisc</interface> or by running a packet capture on the interface (e.g. shell command tcpdump). These methods won't survive a system restart. A longer lived method (which I haven't tried) might be to (in the pfSense GUI) configure a bridge with a single member, the appropriate physical interface, and enable the bridge interface.

    Sorry for late answer, havn't had the time :(

    Confirmed working with configure the interface in promisuous mode. Havn't tried the second method. However, wouldn't it be possible to write a startupscript that put the interface in promisc mode on startup? :) My BSD/programming is quite narrow, have no idea how to do it.



  • @w00t:

    However, wouldn't it be possible to write a startupscript that put the interface in promisc mode on startup? :)

    Yes. However I expect it would be rather quicker for me to configure a bridge as suggested, check the interface is in promiscuous mode, reboot, check the interface is in promiscuous mode than it would be to write the script, work out how to invoke it safely, reboot, check it gets invoked correctly and not too early in the startup, check it won't get overwritten by a firmware upgrade etc.  Hence I would try the bridge idea first and have the startup script as a fall back. Also the bridge idea gets backed up with the configuration file, the startup script probably doesn't.



  • @wallabybob:

    @w00t:

    However, wouldn't it be possible to write a startupscript that put the interface in promisc mode on startup? :)

    Yes. However I expect it would be rather quicker for me to configure a bridge as suggested, check the interface is in promiscuous mode, reboot, check the interface is in promiscuous mode than it would be to write the script, work out how to invoke it safely, reboot, check it gets invoked correctly and not too early in the startup, check it won't get overwritten by a firmware upgrade etc.  Hence I would try the bridge idea first and have the startup script as a fall back. Also the bridge idea gets backed up with the configuration file, the startup script probably doesn't.

    Good point.


Log in to reply