Regular LAN + VLAN on same interface does not work.
-
Interfaces:
- WAN is on vr1 – DHCP
- LAN is on vr0 -- 192.168.0.254/24
- OPT1(Wireless) is on vr0_vlan2 -- 192.168.1.254/24
pfSense version
2.0-BETA1
built on Fri Feb 12 22:15:15 EST 2010When OPT1 is enabled, no traffic is passed through the router. I can get to pfSense itself from a machine on the LAN, and pfSense (from the shell) can get out the WAN, but nothing passes through. Once OPT1 is disabled, and pfSense is rebooted, normal functionality is restored (reboot is required).
In addition, the DHCP server configuration page for the LAN shows OPT1's subnet data (as shown in the screen shot). The DHCP configuration refuses to save, saying that the given DHCP range is outside of the subnet (or something equivalent).
The merits of this set up (native + 802.1q, dual-mode, whatever you want to call it) are debatable, but this configuration is common in many networks that make use of 802.1q, so I think it's worth looking at.
--- config.xml snippet ---
<lan><if>vr0</if>
<ipaddr>192.168.0.254</ipaddr>
<subnet>24</subnet>
<media><mediaopt><bandwidth>100</bandwidth>
<bandwidthtype>Mb</bandwidthtype>
<descr>LAN</descr></mediaopt></media></lan>
<opt1><descr>Wireless</descr>
<if>vr0_vlan2</if>
<spoofmac><enable><ipaddr>192.168.1.254</ipaddr>
<subnet>24</subnet></enable></spoofmac></opt1>(btw, nice work on 2.0. It's looking great)
-
Can you attach your entire config, or email it to me (cmb at pfsense dot org) referencing this thread?
-
If you could provide details of what is on the remote end of vr0, as well as how the remote interface is configured, it would be beneficial in troubleshooting.
Also, I don't doubt that you may have encountered a bug in either FreeBSD or pfSense, and how they handle this particular setup, but I would suggest that you configure LAN as VLAN 1, instead of mixing tagged and untagged traffic on an interface. Depending on how the layer-2 equipment on the other end of vr0 is configured, it will either drop the untagged traffic or insert a tag (as configured). Tagging LAN as VLAN 1 will remove one variable from the equation (how the remote end of vr0 is handling the traffic), and should have the same end result. If you have configured your layer-2 environment so that you are using a VLAN other than 1 as a "default" for non-trunked traffic, replace every previous occurrence of the number 1 with that VLAN ID.
As a side note.. in my 10 years of network administration, the only time I have had to mix tagged and untagged traffic on an interface is when having to provision a port to accept both a client PC and VoIP-endpoint (with isolated voice VLAN), with the requirement of having the client PC not speak 802.1q. I have never found a need or good reason for mixing tagged and untagged traffic between network gear (switches, routers, firewalls, etc).
-
As 'rewt' already pointed out it doesn't seem to be good practice to share tagged and untagged traffic on the same interface.
Does the described behaviour still exist when you create another VLAN for LAN and use your vr0 as parent only?But since Chris (cmb) is looking at this already I expect you to get an answer shortly anyway ;-)
-
using the parent interface along with VLANs has always been discouraged. It's not good from a security standpoint, and it also breaks other functionality such as Captive Portal.
That said, while it is discouraged, it should probably continue to work if possible, since it does on 1.2.x. It would be a POLA violation to break it unnecessarily, and it could lead to machines upgraded in this state being broken/unreachable post-upgrade.
In most (all?) situations, it's better to tag all VLANs on a trunk port and use corresponding VLAN interfaces on pfSense.
-
i have the same problem, if you fix tell me please and viceverse thanks
-
Should be ok on newer snaps.
