v6.testmyipv6.com shows the "Client Address" instead of routed address

[arader]

Hi all,

I've finally set up rtadvd on my openbsd machine so my laptop can get an IPv6 address and starting browsing IPv6 websites. My setup:

OpenBSD 5.1 Router --> Switch --> WiFi AP --> Laptop

the openbsd router is running rtadvd and provides the "routed /64" from the tunnel details page to my clients. From there, they use stateless autoconfig to generate their own IP addresses.

My laptop is able to browse ipv6 websites like ipv6.google.com and v6.testmyipv6.com. There's only one issue: these websites show my address as that of my tunnel's "client ipv6 address" (which is on the openbsd router) rather than my laptop's ipv6 address. Isn't this wrong? I thought a major point of IPv6 was that my laptop wouldn't have it's address translated anymore. As it stands now, it's almost as if my router is NATting my laptop behind itself.

Would this likely be a configuration issue? Or is this just a side effect of using a tunnel?

[kasperd]

Would this likely be a configuration issue? Or is this just a side effect of using a tunnel?

It is likely to be a configuration issue. It is definitely not a side effect of using a tunnel.

I can think of three possible reasons for you seeing what you saw.

• You somehow configured the router to do NAT66.
• You are running a proxy on the router and have your browser use that proxy (either configured or a transparent proxy)
• You ran the browser on the router and had the display forwarded back to the laptop (probably X forwarded through ssh)

If you don't already know which it is, then try to do a tcpdump of the LAN traffic while you let the laptop access a service, that can tell you, what your IP address is. If you want to minimize the traffic you have to look at, then try this command on the laptop.

Code Select Expand

telnet ipv6.test-ipv6.com 79

[arader]

well I'm definitely confused then, because I've basically done the bare minimum in getting this set up.

#2 and #3 can definitely be ruled out - I'm running a super bare bones version of openbsd that doesn't have anything besides the os installed - no X, no browsers, and no proxies.

I'm guessing then it has to be a Nat66 thing, since I'm not super familiar with pf. To make things a little more complicated, I'm using PPPoE with my DSL modem from OpenBSD, but I'd be surprised if that has anything to do with this.

When I ran tcpdump and telnet, I got:

Code Select Expand

09:01:36.690738 PPPoE-Session
        code Session, version 1, type 1, id 0xad7a, length 66
        IP: 71-212-111-178.tukw.qwest.net.59352 > google-public-dns-a.google.com.domain: 18170+ A? ipv6.test-ipv6.com. (36)
09:01:36.738884 PPPoE-Session
        code Session, version 1, type 1, id 0xad7a, length 130
        IP: google-public-dns-a.google.com.domain > 71-212-111-178.tukw.qwest.net.59352: 18170 1/1/0 CNAME aaaa.test-ipv6.com. (100)
09:01:36.750550 PPPoE-Session
        code Session, version 1, type 1, id 0xad7a, length 66
        IP: 71-212-111-178.tukw.qwest.net.58109 > google-public-dns-a.google.com.domain: 64925+ AAAA? ipv6.test-ipv6.com. (36)
09:01:36.798781 PPPoE-Session
        code Session, version 1, type 1, id 0xad7a, length 113
        IP: google-public-dns-a.google.com.domain > 71-212-111-178.tukw.qwest.net.58109: 64925 2/0/0 CNAME aaaa.test-ipv6.com., (83)
09:01:36.806165 PPPoE-Session
        code Session, version 1, type 1, id 0xad7a, length 94
        IP: arader-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.50002 > jason-fesler.f0-8.switch2a.fmt.he.net.telnet: S 2660359580:2660359580(0) win 8192 <mss 1440,nop,wscale 2,nop,nop,sackOK> (encap)

You can see here my laptop uses IPv4 to query google's public DNS server for test-ipv6.com's address - could this be a problem? I assumed not (at least until ipv4 is turned off).

Anyway, here's everything I have set up on my router. Thoughts?

Code Select Expand

# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33196
        priority: 0
        groups: lo
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
        inet 127.0.0.1 netmask 0xff000000
sis0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:24:c7:37:38
        priority: 0
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet6 fe80::200:24ff:fec7:3738%sis0 prefixlen 64 scopeid 0x1
sis1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:24:c7:37:39
        priority: 0
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
        inet6 fe80::200:24ff:fec7:3739%sis1 prefixlen 64 scopeid 0x2
        inet6 2001:470:1f05:3dd::1 prefixlen 64
sis2: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:24:c7:37:3a
        priority: 0
        media: Ethernet autoselect (none)
        status: no carrier
enc0: flags=0<>
        priority: 0
        groups: enc
        status: active
pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1492
        priority: 0
        dev: sis0 state: session
        sid: 0xad7a PADI retries: 7 PADR retries: 0 time: 17:31:12
        sppp: phase network authproto pap authname "raderandrew"
        groups: pppoe egress
        status: active
        inet6 fe80::200:24ff:fec7:3738%pppoe0 ->  prefixlen 64 scopeid 0x6
        inet 71.212.111.178 --> 63.231.10.252 netmask 0xffffffff
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
        priority: 0
        groups: gif egress
        physical address inet 71.212.111.178 --> 72.52.104.74
        inet6 fe80::200:24ff:fec7:3738%gif0 ->  prefixlen 64 scopeid 0x7
        inet6 2001:470:1f04:3dd::2 -> 2001:470:1f04:3dd::1 prefixlen 128
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33196
        priority: 0
        groups: pflog

Code Select Expand

# cat /etc/rtadvd.conf
sis1:\
        :addr="2001:470:1f05:3dd::":prefixlen#64:raflags#0:

Code Select Expand

# cat /etc/pf.conf
# Macros
int_if="sis1"
ext_if="pppoe0"

# Options
set block-policy drop
set loginterface $ext_if
set skip on lo

match on pppoe0 scrub (max-mss 1440)    # scrub MTU sizes so they fit in PPPoE

# Translation
nat on $ext_if inet from ! ($ext_if) -> ($ext_if)

# Filtering
pass in
pass out

[kasperd]

Code Select Expand

09:01:36.806165 PPPoE-Session
        code Session, version 1, type 1, id 0xad7a, length 94
        IP: arader-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.50002 > jason-fesler.f0-8.switch2a.fmt.he.net.telnet: S 2660359580:2660359580(0) win 8192 <mss 1440,nop,wscale 2,nop,nop,sackOK> (encap)

Either you forgot to include the 79 I mentioned in the telnet command, or you are using a different version of telnet, which cannot pass a port number in that way. Additionally I'd like to see the traffic on the internal interface rather than the external, and including the TCP payload, where the server will tell which IP it receives the connection from.

You can see here my laptop uses IPv4 to query google's public DNS server for test-ipv6.com's address - could this be a problem?

That shouldn't be a problem, and that is unlikely to be related to the issue you have.

Code Select Expand

match on pppoe0 scrub (max-mss 1440)    # scrub MTU sizes so they fit in PPPoE

Your MSS setting looks incorrect. I get 1412 as the proper size for you. The MTU on the PPPoE interface is 1492 from that subtract 20 bytes for IPv4 header, 40 bytes for IPv6 header, 20 bytes for TCP header and get 1412. This is unrelated to your problem, but the proper setting may help you with other problems in the future.

Code Select Expand

nat on $ext_if inet from ! ($ext_if) -> ($ext_if)

I don't know this configuration language, so I don't know exactly what is happening. However the way I read this rule, it is only applied to packets on the pppoe0 interface and specifically not to packets on the gif0 interface. And though the tunnelled packets do travel over the pppoe0 interface, it would be incorrect at that point for the rule to inspect the innermost header. It should only apply to the outermost header, which in that case would be the IPv4 header.

So I have no idea what went wrong. It may be that you have encountered a bug. But AFAIK OpenBSD has one of the most mature IPv6 stacks, so it would sound strange if nobody encountered that before. Maybe somebody with more knowledge about OpenBSD has better ideas on what to do.

[snarked]

As it should.  Your system originated the packet out the 6in4 interface, and the client address is the IPv6 address assigned to that interface.

If you want something else to show up, you need to use address selection.  The RFC is 3484.  For Unix type systems, the command is "ip addrlabel".  This manipulates the table described in section 2.1 of that RFC.

[kasperd]

Code Select Expand

09:01:36.806165 PPPoE-Session
       code Session, version 1, type 1, id 0xad7a, length 94
       IP: arader-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.50002 > jason-fesler.f0-8.switch2a.fmt.he.net.telnet: S 2660359580:2660359580(0) win 8192 <mss 1440,nop,wscale 2,nop,nop,sackOK> (encap)

I noticed something suspect here. This does not look like a tunnelled packet at all. It goes straight from PPPoE information to IPv6 information. A look on an actual pcap file could validate that this is really what happens, and that it is not due to some strange simplification of the information printed by tcpdump.

If that hypothesis is true, I think I can explain what is happening:

• Router receives packet from laptop
• Router finds default route on pppoe0 interface
• Router applies firewall rule, which does NAT on the IPv6 packet, because the packet is being send on the pppoe interface
• IPv6 packet translated by NAT66 is sent as native IPv6 over PPPoE.
• IPv6 reply packet is sent over tunnel to router
• Router finds matching NAT state and translates return traffic accordingly

If that hypothesis is true, it must mean that your ISP actually provides you with native IPv6 connectivity, which is functional enough for you to send IPv6 packets. To verify the hypothesis try to run a traceroute6 command (or maybe traceroute -6) from your laptop or router towards an IPv6 address somewhere on the Internet. If my hypothesis is correct it goes through your ISPs network, if it goes through the HE network, my hypothesis is incorrect.

If my hypothesis is correct you have a few possible options:

• Stop using the tunnel altogether and use the native IPv6 provided by your ISP
• Change your default route for IPv6 traffic to send over the tunnel instead of the pppoe0 interface
• Adjust the firewall rule such that it only applies to IPv4 packets and not to IPv6 packets send over the pppoe0 interface

Any of the above three changes should stop sites from seeing your Client IPv6 address when the laptop on the LAN access a site over IPv6.

Your system originated the packet out the 6in4 interface

What makes you think that? According to what was written, the packet wasn't even originated from the router.

[arader]

Thanks for your help so far kasperd!

Code Select Expand

match on pppoe0 scrub (max-mss 1440)    # scrub MTU sizes so they fit in PPPoE

Your MSS setting looks incorrect. I get 1412 as the proper size for you. The MTU on the PPPoE interface is 1492 from that subtract 20 bytes for IPv4 header, 40 bytes for IPv6 header, 20 bytes for TCP header and get 1412. This is unrelated to your problem, but the proper setting may help you with other problems in the future.

great catch! I had copy pasted that from another site, setting it to 1412 has fixed a few issues (I'm now able to get 10/10 passing on test-ipv6.com, and chrome doesn't timeout and hang on certain sites)

Either you forgot to include the 79 I mentioned in the telnet command, or you are using a different version of telnet, which cannot pass a port number in that way. Additionally I'd like to see the traffic on the internal interface rather than the external, and including the TCP payload, where the server will tell which IP it receives the connection from.

Yep you're right, I'm using putty as my telnet client, it apparently resets the port number when you switch between SSH and telnet so it was back to 23. Here's the updated tcpdump output:

Code Select Expand

16:43:25.495080 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 66
        IP: 71-212-116-177.tukw.qwest.net.59716 > google-public-dns-a.google.com.domain: 57522+ A? ipv6.test-ipv6.com. (36)
16:43:25.543338 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 130
        IP: google-public-dns-a.google.com.domain > 71-212-116-177.tukw.qwest.net.59716: 57522 1/1/0 CNAME aaaa.test-ipv6.com. (100)
16:43:25.547566 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 66
        IP: 71-212-116-177.tukw.qwest.net.59181 > google-public-dns-a.google.com.domain: 37130+ AAAA? ipv6.test-ipv6.com. (36)
16:43:25.596037 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 113
        IP: google-public-dns-a.google.com.domain > 71-212-116-177.tukw.qwest.net.59181: 37130 2/0/0 CNAME aaaa.test-ipv6.com., (83)
16:43:25.603513 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 94
        IP: arader-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.58167 > jason-fesler.f0-8.switch2a.fmt.he.net.finger: S 2736889506:2736889506(0) win 8192 <mss 1440,nop,wscale 2,nop,nop,sackOK> (encap)
16:43:25.663741 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 94
        IP: jason-fesler.f0-8.switch2a.fmt.he.net.finger > arader-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.58167: S 4092030152:4092030152(0) ack 2736889507 win 65535 <mss 1412,nop,wscale 6,sackOK,eol> [flowlabel 0xaec17] (encap)
16:43:25.667208 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 82
        IP: arader-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.58167 > jason-fesler.f0-8.switch2a.fmt.he.net.finger: . ack 1 win 4236 (encap)
16:43:25.667222 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 103
        IP: arader-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.58167 > jason-fesler.f0-8.switch2a.fmt.he.net.finger: P 1:22(21) ack 1 win 4236 (encap)
16:43:25.735044 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 133
        IP: jason-fesler.f0-8.switch2a.fmt.he.net.finger > arader-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.58167: P 1:52(51) ack 22 win 1036 [flowlabel 0xaec17] (encap)
16:43:25.735074 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 82
        IP: jason-fesler.f0-8.switch2a.fmt.he.net.finger > arader-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.58167: F 52:52(0) ack 22 win 1036 [flowlabel 0xaec17] (encap)
16:43:25.739209 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 82
        IP: arader-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.58167 > jason-fesler.f0-8.switch2a.fmt.he.net.finger: . ack 53 win 4223 (encap)
16:43:25.739224 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 82
        IP: arader-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.58167 > jason-fesler.f0-8.switch2a.fmt.he.net.finger: F 22:22(0) ack 53 win 4223 (encap)
16:43:25.801542 PPPoE-Session
        code Session, version 1, type 1, id 0xcfe8, length 82
        IP: jason-fesler.f0-8.switch2a.fmt.he.net.finger > arader-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.58167: . ack 23 win 1036 [flowlabel 0xaec17] (encap)

Code Select Expand

nat on $ext_if inet from ! ($ext_if) -> ($ext_if)

I don't know this configuration language, so I don't know exactly what is happening. However the way I read this rule, it is only applied to packets on the pppoe0 interface and specifically not to packets on the gif0 interface. And though the tunnelled packets do travel over the pppoe0 interface, it would be incorrect at that point for the rule to inspect the innermost header. It should only apply to the outermost header, which in that case would be the IPv4 header.

I read the pf.conf line as "apply nat on ipv4 packets on the pppoe0 interface for anything that originates on an interface other than pppoe0 that is destined for the pppoe0 interface". The inet portion means ipv4 only, inet6 is used for ipv6 traffic. Of course, this means the 6in4 packets are being natted, but since they're coming from the router itself I think that's ok, it shouldn't modify any portion of the ipv6 header.

[arader]

If that hypothesis is true, I think I can explain what is happening:
Router receives packet from laptop
Router finds default route on pppoe0 interface
Router applies firewall rule, which does NAT on the IPv6 packet, because the packet is being send on the pppoe interface
IPv6 packet translated by NAT66 is sent as native IPv6 over PPPoE.
IPv6 reply packet is sent over tunnel to router
Router finds matching NAT state and translates return traffic accordingly

If that hypothesis is true, it must mean that your ISP actually provides you with native IPv6 connectivity, which is functional enough for you to send IPv6 packets. To verify the hypothesis try to run a traceroute6 command (or maybe traceroute -6) from your laptop or router towards an IPv6 address somewhere on the Internet. If my hypothesis is correct it goes through your ISPs network, if it goes through the HE network, my hypothesis is incorrect.

I wish this was true, but I'm 95% certain my ISP doesn't provide ipv6. I'm going through century link DSL (formerly qwest) and they barely provide ipv4 internet. Before I started setting up openbsd and the tunnel I did attempt to use ipv6 with no luck. I tried traceroute6 to be sure:

Code Select Expand

# traceroute6 ipv6.google.com
traceroute6 to ipv6.l.google.com (2607:f8b0:400e:c02::68) from 2001:470:1f04:3dd::2, 64 hops max, 12 byte packets
1  arader-1.tunnel.tserv3.fmt2.ipv6.he.net  66.828 ms  67.614 ms  67.035 ms
2  gige-g5-19.core1.fmt2.he.net  61.384 ms  64.695 ms  61.301 ms
3  10gigabitethernet1-1.core1.sjc2.he.net  63.395 ms  71.079 ms  66.781 ms
4  2001:4860:1:1:0:1b1b:0:9  62.089 ms  62.275 ms  62.598 ms
5  2001:4860::1:0:21  62.401 ms  63.174 ms  63.135 ms
6  2001:4860::8:0:2cb7  62.488 ms  62.747 ms  62.806 ms
7  2001:4860::8:0:2bb7  119.254 ms  82.232 ms 2001:4860::8:0:2bb6  82.509 ms
8  2001:4860::8:0:2b5f  91.098 ms 2001:4860::8:0:2b60  92.544 ms 2001:4860::8:0:2b5f  85.645 ms
9  2001:4860::2:0:bc  85.105 ms  85.471 ms  85.432 ms
10  * * *
11  pd-in-x68.1e100.net  85.031 ms  85.582 ms  85.678 ms

and it looks like that's using my tunnel through he.net right? Also, here's the output of netstat -r, which also makes it look like ipv6 packets use the tunnel:

Code Select Expand

# netstat -r
Routing tables

Internet:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
default            tukw-dsl-gw60-252. UGS        8 19495183     -     8 pppoe0
10.0.0/24          link#2             UC         4        0     -     4 sis1
10.0.0.2           00:17:9a:43:25:8d  UHLc       0        0     -     4 sis1
10.0.0.102         00:1c:bf:ce:03:0a  UHLc       1    10418     -     4 sis1
10.0.0.105         0c:74:c2:53:86:66  UHLc       0      379     -     4 sis1
10.0.0.106         link#2             UHLc       1   135716     -     4 sis1
tukw-dsl-gw60-252. 71-212-116-177.tuk UH         0        0     -     4 pppoe0
loopback           localhost          UGRS       0        0 33196     8 lo0
localhost          localhost          UH         1      647 33196     4 lo0
base-address.mcast localhost          URS        0        0 33196     8 lo0

Internet6:
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
::/104             localhost          UGRS       0        0     -     8 lo0
::/96              localhost          UGRS       0        0     -     8 lo0
default            arader-1.tunnel.ts UGS      180      428     -     8 gif0
localhost          localhost          UH        14        0 33196     4 lo0
::127.0.0.0/104    localhost          UGRS       0        0     -     8 lo0
::224.0.0.0/100    localhost          UGRS       0        0     -     8 lo0
::255.0.0.0/104    localhost          UGRS       0        0     -     8 lo0
::ffff:0.0.0.0/96  localhost          UGRS       0        0     -     8 lo0
arader-1.tunnel.ts arader-1-pt.tunnel UH         1        2     -     4 gif0
arader-1-pt.tunnel link#7             UHL        0     8075     -     4 lo0
2001:470:1f05:3dd: link#2             UC         9        0     -     4 sis1
2001:470:1f05:3dd: 00:00:24:c7:37:39  UHL        0        0     -     4 lo0
2001:470:1f05:3dd: 0c:74:c2:53:86:66  UHLc       0        8     -     4 sis1
2001:470:1f05:3dd: 00:1c:bf:ce:03:0a  UHLc       0        0     -     4 sis1
2001:470:1f05:3dd: 0c:74:c2:53:86:66  UHLc       0        1     -     4 sis1
2001:470:1f05:3dd: 0c:74:c2:53:86:66  UHLc       0        4     -     4 sis1
2001:470:1f05:3dd: 00:1c:bf:ce:03:0a  UHLc       0        2     -     4 sis1
2001:470:1f05:3dd: 0c:74:c2:53:86:66  UHLc       0       18     -     4 sis1
2001:470:1f05:3dd: 0c:74:c2:53:86:66  UHLc       0       10     -     4 sis1
2001:470:1f05:3dd: 00:1c:bf:ce:03:0a  UHLc       0      184     -     4 sis1
2001:470:1f05:3dd: 00:1c:bf:ce:03:0a  UHLc       0        0     -     4 sis1
2002::/24          localhost          UGRS       0        0     -     8 lo0
2002:7f00::/24     localhost          UGRS       0        0     -     8 lo0
2002:e000::/20     localhost          UGRS       0        0     -     8 lo0
2002:ff00::/24     localhost          UGRS       0        0     -     8 lo0
fe80::/10          localhost          UGRS       0        0     -     8 lo0
fe80::%sis0/64     link#1             UC         0        0     -     4 sis0
fe80::200:24ff:fec 00:00:24:c7:37:38  UHL        0        0     -     4 lo0
fe80::%sis1/64     link#2             UC         2        0     -     4 sis1
fe80::200:24ff:fec 00:00:24:c7:37:39  UHL        0        0     -     4 lo0
fe80::e74:c2ff:fe5 0c:74:c2:53:86:66  UHLc       0       10     -     4 sis1
fe80::9567:942:9dd 00:1c:bf:ce:03:0a  UHLc       0      304     -     4 sis1
fe80::%lo0/64      fe80::1%lo0        U          0        0     -     4 lo0
fe80::1%lo0        link#5             UHL        0        0     -     4 lo0
fe80::%pppoe0/64   fe80::200:24ff:fec U          0        0     -     4 pppoe0
fe80::200:24ff:fec link#6             HL         0        0     -     4 lo0
fe80::%gif0/64     link#7             UC         0        0     -     4 gif0
fe80::200:24ff:fec link#7             UHL        0        0     -     4 lo0
fec0::/10          localhost          UGRS       0        0     -     8 lo0
ff01::/16          localhost          UGRS       0        0     -     8 lo0
ff01::%sis0/32     link#1             UC         0        0     -     4 sis0
ff01::%sis1/32     link#2             UC         0        0     -     4 sis1
ff01::%lo0/32      fe80::1%lo0        UC         0        0     -     4 lo0
ff01::%pppoe0/32   fe80::200:24ff:fec UC         0        0     -     4 pppoe0
ff01::%gif0/32     link#7             UC         0        0     -     4 gif0
ff02::/16          localhost          UGRS       0        0     -     8 lo0
ff02::%sis0/32     link#1             UC         0        0     -     4 sis0
ff02::%sis1/32     link#2             UC       139        0     -     4 sis1
ff02::1:ff01:4139% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff03:a0b9% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff04:4852% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff07:cac%s link#2             UHLc       0        0     -     4 sis1
ff02::1:ff08:f8ad% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff09:4ca8% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff09:4d01% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff0e:7929% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff0e:aeb4% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff0f:e3a3% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff10:b3b5% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff14:cef3% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff14:d350% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff19:34a%s link#2             UHLc       0        0     -     4 sis1
ff02::1:ff19:a0d9% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff1f:38bf% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff22:344b% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff22:72a4% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff25:569c% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff25:a3a3% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff28:85ee% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff2a:c1d2% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff2a:e726% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff2d:71f4% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff2f:7b91% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff31:97a7% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff32:5b5%s link#2             UHLc       0        0     -     4 sis1
ff02::1:ff35:844%s link#2             UHLc       0        0     -     4 sis1
ff02::1:ff36:ad76% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff37:c11f% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff3f:c6d%s link#2             UHLc       0        0     -     4 sis1
ff02::1:ff41:5a95% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff41:eda9% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff46:593a% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff47:c70%s link#2             UHLc       0        0     -     4 sis1
ff02::1:ff47:e12a% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff49:4f8e% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff49:809a% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff4a:34ef% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff4d:1f85% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff51:7e18% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff52:54d0% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff52:d0d5% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff54:25b8% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff55:1224% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff56:8cec% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff57:2c42% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff59:2841% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff5a:22a%s link#2             UHLc       0        0     -     4 sis1
ff02::1:ff5a:f8b0% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff5b:3e4e% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff5d:3e86% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff5e:667b% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff62:7951% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff64:6221% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff65:6a45% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff65:cf6d% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff66:331%s link#2             UHLc       0        0     -     4 sis1
ff02::1:ff66:cbd8% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff67:1fd6% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff67:7def% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff68:b94%s link#2             UHLc       0        0     -     4 sis1
ff02::1:ff69:8214% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff69:c869% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff6a:cfd1% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff6c:7ba4% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff6d:11db% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff6f:ccb9% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff71:3d7e% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff73:9719% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff76:764b% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff78:8522% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff79:9950% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff7b:316%s link#2             UHLc       0        0     -     4 sis1
ff02::1:ff7c:6918% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff80:5508% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff86:82f0% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff88:ea9a% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff8a:996a% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff8d:ebfd% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff90:610a% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff93:61%si link#2             UHLc       0        0     -     4 sis1
ff02::1:ff96:9b91% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff96:ed2d% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff97:f449% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff99:7e8%s link#2             UHLc       0        0     -     4 sis1
ff02::1:ff9b:a6ef% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff9f:670d% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff9f:a889% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff9f:af4a% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff9f:b02f% link#2             UHLc       0        0     -     4 sis1
ff02::1:ff9f:d818% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffa2:da81% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffa2:f73d% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffa5:48a0% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffaa:4fbc% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffab:6c36% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffaf:e008% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffb2:abd5% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffb2:f4de% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffb3:999e% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffbd:857a% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffbe:b15b% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffc2:45da% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffc2:c292% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffc3:fa90% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffc8:6f93% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffc9:a79d% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffce:7b65% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffce:b37d% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffce:be67% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffd1:f09f% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffd2:d58f% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffd5:baee% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffd8:360e% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffda:52f6% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffde:bfc1% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffe0:ee48% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffe2:6358% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffe3:7813% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffe9:c49b% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffea:6e91% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffea:aa15% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffeb:f88e% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffed:aca2% link#2             UHLc       0        0     -     4 sis1
ff02::1:fff0:4cda% link#2             UHLc       0        0     -     4 sis1
ff02::1:fff1:61a0% link#2             UHLc       0        0     -     4 sis1
ff02::1:fff3:780f% link#2             UHLc       0        0     -     4 sis1
ff02::1:fff3:b407% link#2             UHLc       0        0     -     4 sis1
ff02::1:fff4:5aa9% link#2             UHLc       0        0     -     4 sis1
ff02::1:fff4:a0dd% link#2             UHLc       0        0     -     4 sis1
ff02::1:fff6:1d19% link#2             UHLc       0        0     -     4 sis1
ff02::1:fff7:b7d8% link#2             UHLc       0        0     -     4 sis1
ff02::1:fff8:841f% link#2             UHLc       0        0     -     4 sis1
ff02::1:fff9:f0c%s link#2             UHLc       0        0     -     4 sis1
ff02::1:fffa:4bd9% link#2             UHLc       0        0     -     4 sis1
ff02::1:fffa:a4e6% link#2             UHLc       0        0     -     4 sis1
ff02::1:fffa:c38d% link#2             UHLc       0        0     -     4 sis1
ff02::1:ffff:5d21% link#2             UHLc       0        0     -     4 sis1
ff02::%lo0/32      fe80::1%lo0        UC         0        0     -     4 lo0
ff02::%pppoe0/32   fe80::200:24ff:fec UC         0        0     -     4 pppoe0
ff02::%gif0/32     link#7             UC         0        0     -     4 gif0

So I'm not sure where that leaves me? Should I try disabling PF on openbsd and see if that's causing it?

[arader]

As it should.  Your system originated the packet out the 6in4 interface, and the client address is the IPv6 address assigned to that interface.

If you want something else to show up, you need to use address selection.  The RFC is 3484.  For Unix type systems, the command is "ip addrlabel".  This manipulates the table described in section 2.1 of that RFC.

Yes the packet is being sent over the 6in4 interface, but it's not originating from the router. My laptop is the one that is supplying the source address, so I'd expect the external hosts to see one of its IPs, not one of the IPs of the router. RFC 3484 sounds relevant, but I can't see why the router would decide to add one of its addresses as the source, rather than leaving it as one of the laptop's? maybe I just haven't gotten to that part in the RFC, I'll keep reading.

[kasperd]

Here's the updated tcpdump output

Unfortunately the textual representation produced by tcpdump doesn't contain all the information I was looking for. Could you try to do a binary dump of the traffic and attach that to this thread? Additionally, I think having dumps from both interfaces of the same session would make it more clear, what is happening. If I understand the information correctly, then the tcpdump output you posted so far is from the sis0 interface. I'd like to see both sis0 and sis1. (The capture on the sis1 interface can be restricted to only port 79 packets).

On Linux a binary dump can be produced by adding -Uw filename to the tcpdump command line. Once you have a dump file, it can be displayed by specifying -r filename instead of an interface name to capture packets from. Additionally the dump file can be inspected using Wireshark, which can display all the details, which are missing from the text output, that you posted. You may have to look at the man page for tcpdump to find out the exact arguments to use on BSD, they are not necessarily the same as on Linux.

it looks like that's using my tunnel through he.net right?

It does indeed, so my first hypothesis was incorrect. And I just now noticed the (encap) at the end of the line to indicate that the packets were indeed encapsulated. The tcpdump I am used to displays information about the IPv4 header at the start of the line, and also includes the actual IPv4 addresses. So much more reason to look at a binary dump, where there is less ambiguity about how to interpret what I am looking at.

Should I try disabling PF on openbsd and see if that's causing it?

You can try it. That additional piece of information may help identify the cause of the problem.

[arader]

Boy is my face red!

Okay, so I finally had some free time last night to muck around again, turns out the problem was been the keyboard and the chair  :-[

First: I didn't realize running 'pfctl -d' then 'pfctl -e' wasn't enough to cause PF to actually reload the rules. This meant that the pf.conf I pasted here wasn't actually being used. The pf.conf file that was being used was a super simple one that applied NAT to both inet and inet6. Further, the pf.conf I pasted wasn't even the right syntax, when I eventually realized 'pfctl -f /etc/pf.conf' was what I need to run to update the rules, I was met with a syntax error.

Now I have a properly updated pf.conf file that only does NAT on ipv4 packets. Everything appears to work just fine!

Thanks for all your help kasperd! I definitely learned a lot and feel much more confident about my setup now. Now I just need to get my xbox out of "strict" nat mode and I'll be set!

[kasperd]

turns out the problem was been the keyboard and the chair

We all make mistakes once in a while. I prefer threads that ends with a resolution. Much better than those threads, where the OP disappears without even letting us know, if the problem was resolved. Whether the root cause was a small detail being overlooked or something deeper and more complicated isn't important to me. I do think a small detail being overlooked is the typical case though.