VLAN won't pick up IP via DHCP
-
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).
-
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?
-
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
-
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?
-
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.
-
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.
-
-
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.
-
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.
-
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.