You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The firewall inspects the ethertype and rejects anything that doesn't match IPv4, IPv6, or ARP.
In the IEEE 802.1Q VLAN tagging case, an IEEE 802.1Q header is placed between the source MAC and the ethertype containing a tag protocol identifier and tagging information. The firewall thus reads the tag protocol identifier (typically 0x8100), sees that it doesn't match IPv4, IPv6, or ARP, and rejects the packet.
Potential fix:
To fix this, I suggest that we:
Define a struct TaggedEthernetHeader that matches the Ethernet header in the IEEE 802.1Q VLAN tagging case;
If so, re-cast into a TaggedEthernetHeader before entering the Ethertype switch.
We should do that on ingress and egress.
A similar solution could be applied to support other forms of tagging such as IEEE 802.1ad double tagging, though I doubt we need support for that now.
Notes:
This should not be considered a priority, as the FreeRTOS+TCP stack does not currently support VLAN tagging. Adding support for VLAN tagging to the firewall without support in the network stack is not useful.
We will have the same problem with the incoming DNS resolver: #50
The text was updated successfully, but these errors were encountered:
The firewall inspects the ethertype and rejects anything that doesn't match IPv4, IPv6, or ARP.
In the IEEE 802.1Q VLAN tagging case, an IEEE 802.1Q header is placed between the source MAC and the ethertype containing a tag protocol identifier and tagging information. The firewall thus reads the tag protocol identifier (typically 0x8100), sees that it doesn't match IPv4, IPv6, or ARP, and rejects the packet.
Potential fix:
To fix this, I suggest that we:
struct TaggedEthernetHeader
that matches the Ethernet header in the IEEE 802.1Q VLAN tagging case;TaggedEthernetHeader
before entering the Ethertype switch.We should do that on ingress and egress.
A similar solution could be applied to support other forms of tagging such as IEEE 802.1ad double tagging, though I doubt we need support for that now.
Notes:
This should not be considered a priority, as the FreeRTOS+TCP stack does not currently support VLAN tagging. Adding support for VLAN tagging to the firewall without support in the network stack is not useful.
We will have the same problem with the incoming DNS resolver: #50
The text was updated successfully, but these errors were encountered: