Some VLAN interfaces stay "down" all the time
Snapshot from Tue Aug 24 01:26:38 EDT 2010 i386 (sanitized config .xml attached as .txt as attach form says .xml is not allowed).
My issue is that I have 11 interfaces (the 11th is a test one I created to demonstrate that the issue was happening for more than one interface, but I want the 10th one, using VLAN 3455, to work) on my VMware-based pfSense box, and the newest two of them, assigned to VLANs, won't come up (stay in Down state and don't appear in ifconfig -a output). If I switch one to a physical NIC, it comes up fine. I've deleted and recreated the interfaces and the VLANs with no change. Both interfaces are Enabled, with static IPs set. I have four interface groups but none of the problematic interfaces are members of the groups. When I edit and save an Interface Group, I get the message "Aug 25 10:40:49 php: /interfaces_groups_edit.php: The command '/sbin/ifconfig em4 group NoWifi' returned exit code '1', the output was 'ifconfig: SIOCAIFGROUP: File exists'" in the system log (repeated for each interface that's a member of the group), but I don't know if that's normal, related, or unrelated, I just figured I'd mention it.
The output of ifconfig -a is posted at http://pastebin.com/kVAFx0gD and as you can see, the two VLANs on those interfaces (3454 and 3455) are not showing up in the ifconfig output at all, and are showing as Down per the interfacestatus_* screenshot I've attached.
jimp in IRC requested that I run "ifconfig em2 -vlanmtu -vlanhwtag" and then edit and save one of the interfaces and repost the ifconfig -a output, but it didn't change when I did so.
Any other info I'm leaving out? I attached screenshots of various config screens, as well as a sanitized config file export from the VM, just changed some IPs and removed certs/IPsec keys/users. Hopefully I caught everything really private :-)
I have packages installed but only Open-VM-Tools and phpSysInfo, my hunch is they aren't affecting anything in this case.
The system log doesn't seem to show much out of the ordinary other than what I mentioned above, except for these most recent lines:
Aug 25 11:04:17 last message repeated 19 times Aug 25 10:54:15 last message repeated 19 times Aug 25 10:44:08 last message repeated 4 times Aug 25 10:41:59 check_reload_status: Running rc.php_init_setup Aug 25 10:41:27 check_reload_status: Running rc.php_init_setup Aug 25 10:40:59 check_reload_status: syncing firewall
which are repeating on a regular basis (newest at top).
Original post attempt said attachments were too large by a hair, so I'll post the rest in a new reply. Had to change this somewhat as it said I tried to post a duplicate but I haven't seen it show up in the forum so I'm re-attempting.
Last two screenshots attached that wouldn't fit on first post by a few KB.
Out of curiosity, have you tried to do this without involving the interface groups?
That is, if you delete all of the groups and just have the interfaces themselves, do they all show up properly?
I haven't seen anyone have this problem, but I also haven't seen anyone using interfaces groups for everything like you have.
I haven't tried, but perhaps I'll clone the VM and give it a whirl as soon as I have some time. Or at least backup the config and remove the groups, then restore after testing…I have some rules set up on the IGs already but I don't think there are too many yet. I'll report back once I get a chance to test that out...only odd thing that gives me pause is that those interfaces with issues have never been a part of any interface groups, though of course that doesn't rule that out as an issue.
I updated this VM to the latest snapshot on Friday morning this week. It rebooted with all interfaces down, not just the VLAN I was having issues with. In order to get to the web GUI, I have to use the console to manually assign a LAN IP and then restart the webConfigurator, then it works, but all other interfaces are down. Rebooting takes them all back down again. Restoring my latest config backup to a new pfSense VM doesn't work either, it reboots with errors that I don't recall (though possibly due to the snapshot I was restoring to being newer by a week or so). I went ahead and rebuilt the firewall using the limited webGUI access to the old one and manually reading the config file. Took a few hours but it's close enough and a lot more stable right now than the old.
I have noticed that for the past month or two, restoring just one part of a config file fails 100%. Never does anything. I've tried just restoring the IPsec settings, the Interface settings, and this time the Alias settings, and nothing ever changes even after a reboot. It's like I never even tried to restore part of the config file. It claims to have restored stuff, but no actual changes occur. I haven't tested this exhaustively, but I've seen it happen across enough sections and enough snapshots with different installs to say it's pretty broken.
We'll probably need a copy of the config to see if it's reproduceable in a lab/test environment. You can e-mail it to me at jimp (at) pfsense (dot) org.
As for restoring sections, you can't upload a whole config and choose to restore only a section - it expects to only find the specific section in the file uploaded. Try to backup a single section, look at the file, and test if restoring that single-section backup works.
I'm not sure if that's something that is planned to change yet or what, but that's how it's always worked.