Bug 125467 - [pf] pf keep state bug while handling sessions between vlan trunk
Summary: [pf] pf keep state bug while handling sessions between vlan trunk
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-pf (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-10 09:20 UTC by randy
Modified: 2015-12-12 12:33 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description randy 2008-07-10 09:20:01 UTC 
i use 802.1q protocol to trunk 2 vlans on NIC fxp0, the sub-interface is
fxp0.100 and fxp0.200, and pf has been used to filter traffic, rules as follow

block in log all
pass in quick on fxp0.100 proto icmp from any to any icmp-type echoreq keep state
pass in quick on fxp0.200 proto icmp from any to any icmp-type echoreq keep state

the icmp packet can flow between vlans when pf disabled, but it's been
blocked when pf enabled. theres are icmp states in state table indeed,
but the icmp reply packet seems don't match the state. i've tested
freebsd 7.0 release, the same situation.

How-To-Repeat: # kldload if_vlan
# kldload pf
# sysctl net.inet.ip.forwarding=1
# ifconfig fxp0 up
# ifconfig fxp0.100 create
# ifconfig fxp0.200 create
# ifconfig fxp0.100 inet 100.100.100.1/24 up
# ifconfig fxp0.200 inet 200.200.200.1/24 up

icmp packet can flow between vlans.

load pf rules as follow :
block in log all
pass in quick on fxp0.100 proto icmp from any to any icmp-type echoreq keep state
pass in quick on fxp0.200 proto icmp from any to any icmp-type echoreq keep state

# tcpdump -ni pflog0 icmp
pf drop the icmp packets
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2008-07-10 10:22:47 UTC 
Responsible Changed
From-To: freebsd-bugs->freebsd-pf

Over to maintainer(s).
Comment 2 cmb 2015-12-12 05:10:18 UTC 
No such issues exist in currently supported FreeBSD versions, safe to close this.
Comment 3 Kristof Provost freebsd_committer freebsd_triage 2015-12-12 12:33:57 UTC 
Closing based on the report in comment #2.