pfSense

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.

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.

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.

Can you be more specific on qwhat does not work?

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.

That is how 6to4 works in general that is why they are not so common nowdays afaik.

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.