Project

General

Profile

Actions

Bug #9585

open

6RD: Unable to reach hosts on within same 6rd-domain

Added by Kewin Christensen over 5 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Interfaces
Target version:
-
Start date:
06/14/2019
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.4-p3
Affected Architecture:

Description

There seem to be a bug in the implementation of 6RD on pfSense as it is unable to pass traffic to hosts within the same 6RD domain.

It appears to convert the receiving IPv4 address to something completely bogus.

The 6RD RFC5969 standard reads:

A 6rd domain consists of 6rd Customer Edge (CE) routers and one or
more 6rd Border Relays (BRs). IPv6 packets encapsulated by 6rd
follow the IPv4 routing topology within the SP network among CEs and
BRs. 6rd BRs are traversed only for IPv6 packets that are destined to
or are arriving from outside the SP's 6rd domain. As 6rd is
stateless, BRs may be reached using anycast for failover and
resiliency (in a similar fashion to [RFC3068]).

Please see attached network topology:

So, Host A, B and C must be able to pass traffic to eachother without ever touching the 6RD Border Relay router.

pfSense expects that all traffic originates from the 6RD Border Relay, as per the predefined firewall rules:

From rules.debug:
  1. allow our proto 41 traffic from the 6RD border relay in
    pass in on $WAN proto 41 from 158.248.255.254 to any tracker 1000001601 label "Allow 6in4 traffic in for 6rd on WAN"
    pass out on $WAN proto 41 from any to 158.248.255.254 tracker 1000001602 label "Allow 6in4 traffic out for 6rd on WAN"

This can be easily fixed by adding a simple firewall rule allowing all IPv6 traffic from within the same 6rd domain:
pass in log quick on $WAN reply-to ( igb1.102 158.248.160.1 ) inet proto ipv6 from 158.248.128.0/17 to 158.248.168.137 tracker 1560433953 keep state label "USER_RULE"

However, when pfSense replies to traffic from other hosts, it converts the receiving IPv4 address to something that frankly makes no sence :)

This is a ping from pfSense to www.google.com that is working as designed. Traffic forwarded to my 6RD-BR:
09:00:53.860138 IP 158.248.168.137 > 158.248.255.254: IP6 2a00:fd00:fff4:a224:: > 2a00:1450:4001:825::2004: ICMP6, echo request, seq 1, length 16
09:00:53.892530 IP 158.248.255.254 > 158.248.168.137: IP6 2a00:1450:4001:825::2004 > 2a00:fd00:fff4:a224::: ICMP6, echo reply, seq 1, length 16

This is a ping from Host B to host C (pfSense) within the same 6rd domain. IPv4 address header in receiving packet shows the correct IPv4 source IP:
16:08:27.876648 IP 158.248.170.165 > 158.248.168.137: IP6 2a00:fd00:fff4:aa94:4e5e:cff:fe0e:4fa7 > 2a00:fd00:fff4:a224::: ICMP6, echo request, seq 24534, length 16
16:08:27.876774 IP 158.248.168.137 > 158.248.0.156: IP6 2a00:fd00:fff4:a224:: > 2a00:fd00:fff4:aa94:4e5e:cff:fe0e:4fa7: ICMP6, echo reply, seq 24534, length 16

But notice when pfSense replies to the packet, the destination IPv4 IP is different?!

It is the same when pinging from host C (pfSense) towards Host A and C:

@Ping from pfSense towards 2a00:fd00:fff5:ab5c::1
10:21:25.088407 IP 158.248.168.137 > 158.248.0.0: IP6 2a00:fd00:fff4:a224:: > 2a00:fd00:fff5:ab5c::1: ICMP6, echo request, seq 138, length 16

Ping from pfSense towards 2a00:fd00:fff4:aa94:4e5e:cff:fe0e:4fa7
10:22:48.594700 IP 158.248.168.137 > 158.248.0.156: IP6 2a00:fd00:fff4:a224:: > 2a00:fd00:fff4:aa94:4e5e:cff:fe0e:4fa7: ICMP6, echo request, seq 3, length 16@

I can't figure out how pfSense calculates destination addresses 158.248.0.0 / 158.248.0.156. They're not even within the 158.248.128.0/17 scope my ISP has. :)


Files

pfSense same 6rd domain problem.png (48.7 KB) pfSense same 6rd domain problem.png Network Topology Kewin Christensen, 06/14/2019 03:35 AM
Interfaces_ WAN (igb1.102).png (20.7 KB) Interfaces_ WAN (igb1.102).png 6RD WAN configuration Kewin Christensen, 06/14/2019 06:13 AM
Actions #1

Updated by Kewin Christensen over 5 years ago

Arghh.. Unable to correct my typos :O

Actions #2

Updated by Kewin Christensen over 5 years ago

Added the WAN configuration

Actions #3

Updated by Jim Pingle over 5 years ago

  • Category set to Interfaces
Actions

Also available in: Atom PDF