Problem after upgrading to PFS 2.2 "kernel: bridge0: error setting interface"
I started the upgrade to pfSense 2.2 tonight. After the upgrade restart got stuck at a problem: "kernel: bridge0: error setting interface capabilities on em1_vlan22". I had to take the firewall out of the network and had to manually from the shell restore to the last state. Somebody an idea what the problem might be?
More details of your configuration please. :)
That sort of error is usually caused by something trying to set a property that can only exist on a real interface such as connection speed/duplex or flow control. You can't set those things on a virtual interface such as a bridge or VLAN. You appear to have a VLAN as part of a bridge so could be either.
I removed the MTU and Multicast settings from the LAN interface (vlan 22) but it was the OpenVPN bridge what was the problem. I removed the OpenVPN bridge from the LAN interface and restarted the upgrade process with succes. However it takes forever to load the firewall configuration but after it does everything works again and I reconfigured the bridge on the LAN Interface again to make L2 traffic possible on the OpenVPN tunnel. I still have to test if this survives another reboot but thats for another day to test. I'm happy it runs again for now.
Thank you for your response on my question.
I just now rebooted the pfSense system and again the same error showed up "kernel: bridge0: error setting interface capabilities on em1_vlan22".
This time I didn't powered down but waited longer since after the last upgrade rebooting took a long time like ~10 minutes and yep it rebooted. Everything works so it didn't got stuck after all wen I upgraded the first time to PFS 2.2.
Still weird this error shows up about the openvpn/lan bridge after rebooting while the bridge works wen I connect to the bridged openvpn server.
I wil post my config tomorrow after I have anonymized it.
Here my config attached.
The board i'm using is a SUPERMICRO X7SPA-H-D525 with 4gb ram and a 30gb SSD.
Hmm, well nothing obviously glaring in your config. You are using VLAN1 which can cause problems and is best avoided in general but isn't related to this problem.
I think it's safe to say it's your bridged OpenVPN server that is causing this rather than the road warrior server but you could confirm that by disabling just the bridged server and rebooting.
What does the output of ifconfig look like with everything enabled? Since you don't actually have a bridge interface it's hard to know exactly how the OpenVPN setup scripts configure it.
I know I should not use vlan 1 but I have Ubiquity Unifi wifi accesspoints and to reach their config services I have to connnect to them from the default vlan 1 all other users are on other vlans. Since I need to use vlan 1 for this I now also put my switches and other devices config to vlan 1 so vlan 1 is for me the admin only there wil be no normal users on vlan 1. If i could move the config services to another vlan at those UAP's i would stop using vlan 1.
Wen I disable the bridged OpenVPN server and restart pfSense the error is gone. Still, rebooting takes 17 minutes to reboot (configuring the firewall). Could it be to many block lists? I have many lists with many cidr ranges.
Another thing that happens after the upgrade to 2.2 is that I have to click save in the Freeradius settings config or else Freeradius server wont start. It doesn't start after a reboot till I re-saved the settings without changing anything.
I attached the ifconfig result.
Might need some higher level input on this! ;)
However I'm going to suggest it may be an MTU issue. You can only bridge interfaces with the same MTU size, bridge interface itself must also have the same MTU. Since VLAN tagging requires a larger MTU for the tagging this seems like it should be a problem. Here everything (em1, em1_vlan22, bridge0 and ovpns2) has MTU 1500. However it is actually working, yes? And it was working fine under 2.1.5 :-\
You might try booting in verbose mode to see if that gives any additional error info like what interface setting is that can't be set.
Interupt the boot loader when it counts down from 4 and enter at the OK prompt:
OK set boot_verbose OK boot
Though if it takes 17mins to boot that going to be a bit tedious!
Edit: This thread seems old but relevant: https://forum.pfsense.org/index.php?topic=61170.0
Yes the bridged OpenVPN is working and worked in 2.1. I can reach my windows shares which I can't reach wen I use my other OpenVPN server without bridge.
In the post you linked suicidegybe set a rule to make traffic flow from/to the openvpn tunnel. On the bridged openvpn interface I have no rules set. Wen users login to the bridged openvpn they land in the LAN vlan (vlan22) and can do everything i just can't reach the pfsense web gui but everything else works. If i use the other openvpn server without bridge i am able to reach the pfsense web gui but then i can't reach any windows shares ofcourse.
The network is used at the moment by users.
I will later tonight test verbose reboot and let you know the result.
Here the system.log (changed to system.txt) after set "OK set boot_verbose".
Hmm, well nothing very helpful there.
I notice that the bridge doesn't have a problem when it first comes up it's only after the ovpns2 interface comes up that the error is triggered. Also it's before the ovpns2 interface is set to promiscuous mode.
I did read some list posts about stp and rstp having issues across bridges including vlans. I'm not sure if there are any settings in the OpenVPN setup to control that. There don't appear to be.
Might have to wait for help from one of the devs or someone who has experienced this.
The user in the other thread I think worked around his problem by bridging the OpenVPN interface with the parent interface instead and just allowing access to the VLAN with firewall rules. Since you haven't assigned em1 you have that option.
No there is no stp setting or anything that could relate to it afaik in de openvpn gui settings.
Hopefully some of the devs, or somebody else, have a explanation for it and can resolve it.
Thank you very much Steve for looking into it!
One last suggestion. If you're at the console during the 15minutes it's doing nothing try pressing Ctrl+T. That should show what process is running that's taking so long.
Oke thats a great tip. I'm really curious whats going on while i'm walking circles here while waiting for the firewall to come up. I'm definatly going to check that out the next time I reboot pfSense.
Thanks again Steve.