pfSense

there is a typo on line 324 gwlb.inc, but I fixed it by hand (locahost instead of localhost).

function return_gateways_array($disabled = false, $locahost = false) {

Now the gui complains:

The following input errors were detected:

The gateway '127.0.0.1' is a different Address Family as network '195.XXX.XXX.0'.

or

The gateway '::1' is a different Address Family as network '2001:XXX:XXX::'.

This fixes the "different address family" problem

--- gwlb.inc.orig       2012-06-05 09:24:27.000000000 +0300
+++ gwlb.inc    2012-06-05 09:54:42.000000000 +0300
@@ -811,7 +811,7 @@

 function lookup_gateway_ip_by_name($name) {

-       $gateways_arr = return_gateways_array();
+       $gateways_arr = return_gateways_array(false, true);
         foreach ($gateways_arr as $gname => $gw) {
                 if ($gw['name'] == $name || $gname == $name)
                         return $gw['gateway'];

applied that change to the other gateway lookup functions as well.

this one works, but it's a bit ugly. the -reject or -blackhole might be nicer.

traceroute and ping loop at the pfsense box with unnused addresses below. Well, at least it's not between us and the isp.

:~$ traceroute n -6 XXXX:XXX:XXX:eeee::1
traceroute to XXXX:XXX:XXX:eeee::1 (XXXX:XXX:XXX:eeee::1), 30 hops max, 80 byte packets
1 XXXX:XXX:XXX:332::2 0.211 ms 0.223 ms 0.257 ms
2 XXXX:XXX:XXX:332::2 0.341 ms 0.375 ms 0.367 ms
3 XXXX:XXX:XXX:332::2 0.562 ms 0.623 ms 0.689 ms
4 XXXX:XXX:XXX:332::2 0.917 ms 0.910 ms 0.994 ms
5 XXXX:XXX:XXX:332::2 1.154 ms 1.146 ms 1.178 ms
6 XXXX:XXX:XXX:332::2 1.262 ms 1.242 ms 1.275 ms
7 XXXX:XXX:XXX:332::2 1.480 ms 1.451 ms 1.391 ms
8 XXXX:XXX:XXX:332::2 1.507 ms 1.332 ms 1.422 ms
9 XXXX:XXX:XXX:332::2 1.545 ms 1.458 ms 1.448 ms
10 XXXX:XXX:XXX:332::2 1.554 ms 1.515 ms 1.572 ms
11 XXXX:XXX:XXX:332::2 1.634 ms 1.637 ms 1.600 ms
12 XXXX:XXX:XXX:332::2 1.826 ms 1.656 ms 1.698 ms
13 XXXX:XXX:XXX:332::2 1.769 ms 1.736 ms 1.776 ms
14 XXXX:XXX:XXX:332::2 1.943 ms 1.829 ms 1.858 ms
15 XXXX:XXX:XXX:332::2 1.970 ms 1.947 ms 1.931 ms
16 XXXX:XXX:XXX:332::2 2.052 ms 2.034 ms 2.004 ms
17 XXXX:XXX:XXX:332::2 2.088 ms 1.997 ms 1.918 ms
18 XXXX:XXX:XXX:332::2 1.959 ms 1.924 ms 2.134 ms
19 XXXX:XXX:XXX:332::2 2.207 ms 2.185 ms 2.239 ms
20 XXXX:XXX:XXX:332::2 2.289 ms 2.292 ms 2.298 ms
21 XXXX:XXX:XXX:332::2 2.380 ms 2.500 ms 2.491 ms
22 XXXX:XXX:XXX:332::2 2.557 ms 2.579 ms 2.551 ms
23 XXXX:XXX:XXX:332::2 2.723 ms 2.651 ms 2.696 ms
24 XXXX:XXX:XXX:332::2 2.611 ms 2.568 ms 2.449 ms
25 XXXX:XXX:XXX:332::2 2.394 ms 2.302 ms 2.242 ms
26 XXXX:XXX:XXX:332::2 2.430 ms 2.503 ms 2.303 ms
27 XXXX:XXX:XXX:332::2 2.396 ms 2.404 ms 2.212 ms
28 XXXX:XXX:XXX:332::2 2.285 ms 2.347 ms 2.342 ms
29 XXXX:XXX:XXX:332::2 2.402 ms 2.395 ms 2.385 ms
30 XXXX:XXX:XXX:332::2 2.389 ms 2.380 ms 2.345 ms
:~$ ping6 XXXX:XXX:XXX:eeee::1
PING XXXX:XXX:XXX:eeee::1(XXXX:XXX:XXX:eeee::1) 56 data bytes
From XXXX:XXX:XXX:332::2 icmp_seq=1 Time exceeded: Hop limit
From XXXX:XXX:XXX:332::2 icmp_seq=2 Time exceeded: Hop limit
From XXXX:XXX:XXX:332::2 icmp_seq=3 Time exceeded: Hop limit
From XXXX:XXX:XXX:332::2 icmp_seq=4 Time exceeded: Hop limit
^C
-- XXXX:XXX:XXX:eeee::1 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3023ms

I can probably add that flag if a Null route is involved. Let me check

Try now.

Sorry for the late reply!

the -blackhole seems not to do anything. still loops at the pfbox with ipv6. tested a bit further and these are my findings:

pfsense2.0/ipv4:
nullroute, -blackhole and -reject work as they should.

pfsense2.1/ipv6
there is no difference between nullroute, -blackhole and -reject

tested these directly in the command shell and I believe the problem is in freebsd ipv6 routing.

maybe you shuld leave the gui as is, because it resolves the original problem with unused addresses looping between us and the isp. if the -blackhole starts working properly with a future freebsd version; then the code is there already.

Thank you! Keep up the good work.

I found that the ordering of -blackhole is required to be on the end of the command, or was that the opposite? I changed it in the backend code in the sequence where it worked atleast.

I did have a blackhole route for 2001:db8:: at home that appears to take.