Hello, I have a service listening both on inet and inet6 sockets, so I have inet6 traffic going in to that service
Because I have trunk0 setup, a rule like: (3) pass in inet6 proto tcp to port $service_port queue services does not solves the problem, because only few packets and sometimes no packet at all is able to pass. because according to tcpdump the ipv6 client keeps sending inet6 SYN packets without the server to reply to this packets, and the handshake times out. I have to prepend these two rules to the rule set: (1) pass on trunk0 inet6 (2) pass on $ext_if proto ipv6 in order to fix the problem. Is there a control mechanism as I see that the rule (1) is matched by misterious packets in case of inet6 traffic, when the inet6 service is accessed, and rule(2) not at all, and finally rule(3) matches because is more specific than rule(1)? Without a rule like rule (3), rule (1) would match all inet6 traffic. What reprezent those misterious inet6 packets, and what is the explanation rules (1) and (2)? I only understand the fact that in case of tunnel interface(like the example in the manual), or in my case trunk interface, inet6 functionality must be enabled at the trunk pseudo-device level as well as physical interface level, although $ext_if expands to trunk0, also. If trunk0 is an aggregation of two physical interfaces bge0 and bge1, is the physical interface , bge0, automatically provisioned with ipv6 functionality, if we specify these rules? If $ext_if="bge0" and no trunk0 interface created, the rules (1) and (2) wouldn't be needed anymore because bge0 would have been automatically configured for inet6 traffic? So we need rules (1) and (2) in trunk setup to obtain the same behaviour? Please if someone could explain the importance of rule (1) and rule (2). OS: OpenBSD/5.1/amd64 Thank you in advance Bogdan
