Bug #2412
closedinbound 6to4 traffic does not work in pf
0%
Description
With the WAN configured as 6to4 it is possible to browse the internet but it is not possible to initiate traffic from the internet to the 6to4 prefix.
Bjoern performed some debugging and it appears to be a issue in pf. Even with a allow all pf rule for IPv6 it was not possible to ping any 6to4 prefix IPv6 address from the internet. The pf rule even logged that it allowed the traffic.
Disable pf with pfctl -d and the ping6 starts replying. As soon as pf is enabled again it will stop response.
Bjoern mentioned in IRC that it does see a reply being crafted, but it is never seen on the stf0 interface with tcpdump.
Here is the note from Bjoern
pfctl -d and it works pfctl -e and it stops again it's the pfil hook in ip6_output a very first pf rule to log all icmp6 does not see the packet at all; I'd say a pf issue and defer to the pf experts at pfsense;-) /bz
Updated by Lakin Lowrey almost 12 years ago
I have a problem which may be related. First, I (now) have no problems initiating traffic inbound to any of my 6to4 addresses but I had to make a few modifications to get things to work.
I'm running snapshot 2.1-BETA0 (amd64) built on Thu Nov 1 14:45:30 EDT 2012
Firstly, the rules for passing proto 41 in /etc/inc/filter.inc restrict that traffic to only to/from the 6to4 anycast address 192.88.99.1. My problem was that my remotes were sending the 6in4 (proto 41) packets directly to my router and therefore these packets were coming inbound from addresses that were not 192.88.99.1. I edited filter.inc and set the rules as follows:
pass in on \${$oc['descr']} proto 41 from any to (self) label "Allow 6in4 traffic in for 6to4 on {$oc['descr']}"
pass out on \${$oc['descr']} proto 41 from (self) to any label "Allow 6in4 traffic out for 6to4 on {$oc['descr']}"
Once I made that change I no longer had problems receiving inbound traffic.
The next hiccup was that the ipv6 firewall rules had to be applied to interface stf0 and not to the WAN interface. I had to assign stf0 to OPT1 before I could create inbound rules.
Those two changes solved all of my inbound 6to4 problems.
IMO, pfsense should NOT restrict 6in4 packets to the 192.88.99.1 anycast address.
It's a little less clear to me how to best address the stf0 firewall rules issue.
Updated by Ermal Luçi over 11 years ago
- Status changed from New to Feedback
Can you test with latest snapshots and see if it behaves better?
Updated by Irving Popovetsky over 11 years ago
I'm still seeing this issue with today's (Feb 4) snapshot. Using a comcast 6to4 tunnel.
Example test ping6 from Internet to one of my IPs.
pfSense (tcpdump -nl -i wan_stf icmp6) shows incoming, but not outgoing:
14:31:52.284810 IP6 2001:0:5ef5:79fb:207e:3990:a170:d7dd > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 46473, length 12 14:31:52.292372 IP6 2001:0:5ef5:79fd:147f:fc:4dd1:2871 > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 61394, length 12 14:31:52.833067 IP6 2001:0:5ef5:79fd:24bd:11bb:3d61:b78e > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 17908, length 12 14:31:52.959949 IP6 2001:0:5ef5:79fd:348f:9fbc:a80b:4d9b > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 28153, length 12 14:31:53.004120 IP6 2001:0:5ef5:79fb:81e:159b:3e95:3495 > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 65131, length 12 14:31:53.067017 IP6 2001:0:5ef5:79fd:1423:3282:aa11:814a > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 52250, length 12 14:31:53.163090 IP6 2001:0:5ef5:79fd:1073:2536:a0cb:edb1 > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 49772, length 12
On the Linux host on my network, tcpdump -nl -i eth0 icmp6 shows requests and replies:
14:31:42.102136 IP6 2001:0:5ef5:79fd:3401:2abb:3dd3:a258 > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 626, length 12 14:31:42.102182 IP6 2002:473b:fbe7:0:290:a9ff:feb2:c733 > 2001:0:5ef5:79fd:3401:2abb:3dd3:a258: ICMP6, echo reply, seq 626, length 12 14:31:42.109412 IP6 2001:0:5ef5:79fd:2caf:2133:b214:8883 > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 20966, length 12 14:31:42.109449 IP6 2002:473b:fbe7:0:290:a9ff:feb2:c733 > 2001:0:5ef5:79fd:2caf:2133:b214:8883: ICMP6, echo reply, seq 20966, length 12 14:31:43.858917 IP6 2001:0:5ef5:79fd:3401:2abb:3dd3:a258 > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 51208, length 12 14:31:43.858970 IP6 2002:473b:fbe7:0:290:a9ff:feb2:c733 > 2001:0:5ef5:79fd:3401:2abb:3dd3:a258: ICMP6, echo reply, seq 51208, length 12 14:31:44.112409 IP6 2001:0:5ef5:79fd:2caf:2133:b214:8883 > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 36893, length 12 14:31:44.112453 IP6 2002:473b:fbe7:0:290:a9ff:feb2:c733 > 2001:0:5ef5:79fd:2caf:2133:b214:8883: ICMP6, echo reply, seq 36893, length 12 14:31:45.358902 IP6 2001:0:5ef5:79fb:b0:e9e:4d2d:e648 > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 32159, length 12 14:31:45.358937 IP6 2002:473b:fbe7:0:290:a9ff:feb2:c733 > 2001:0:5ef5:79fb:b0:e9e:4d2d:e648: ICMP6, echo reply, seq 32159, length 12 14:31:45.568785 IP6 2001:0:5ef5:79fd:1c79:1642:a433:aa23 > 2002:473b:fbe7:0:290:a9ff:feb2:c733: ICMP6, echo request, seq 17157, length 12 14:31:45.568831 IP6 2002:473b:fbe7:0:290:a9ff:feb2:c733 > 2001:0:5ef5:79fd:1c79:1642:a433:aa23: ICMP6, echo reply, seq 17157, length 12
The same Linux host can initiate outgoing icmp6 traffic:
# ping6 ipv6.google.com PING ipv6.google.com(pd-in-x68.1e100.net) 56 data bytes 64 bytes from pd-in-x68.1e100.net: icmp_seq=1 ttl=56 time=38.4 ms 64 bytes from pd-in-x68.1e100.net: icmp_seq=2 ttl=56 time=43.3 ms 64 bytes from pd-in-x68.1e100.net: icmp_seq=3 ttl=56 time=38.5 ms ^C --- ipv6.google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 38.463/40.130/43.354/2.280 ms
I have configured floating and interface-specific rules to allow ICMP6 from any source/destination. Not sure exactly how to troubleshoot this.
Updated by Richard Adams over 11 years ago
I have tested with:
2.1-BETA1 (i386)
built on Thu Feb 21 18:19:58 EST 2013
FreeBSD 8.3-RELEASE-p6
The problem still exists.
Traffic makes it to the server, traffic is not returned.
Updated by Ermal Luçi over 11 years ago
Can you be more specific on qwhat does not work?
Updated by Irving Popovetsky over 11 years ago
Update:
Upgraded to today's (March 30) snapshot. Now inbound connections work OK.
A little bit scary, however: All IPv6 inbound connections were being allowed. I had to add an IPV6 default deny rule on my WAN interface.
Updated by Ermal Luçi over 11 years ago
That is how 6to4 works in general that is why they are not so common nowdays afaik.
Updated by Richard Adams about 11 years ago
I can confirm that this is working as intended. Thank you for fixing it. We are mainly using this to test ipv6 capability before deployment.
Updated by Ermal Luçi about 11 years ago
- Status changed from Feedback to Resolved