I've been trying all sorts of combinations to get IPv6 traffic to go out the PPTP VPN that I've setup on my Mac OS X 10.6 machine. I have the 'VPN is Tunnel Endpoint' checked in the Tunnel Details page. And I can access this machine with IPv4 through the PPTP VPN tunnel. I just can't get IPv6 to go out.
Here are the settings I have:
overcompensation:~ root# ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
inet6 fe80::d69a:20ff:fee9:6020%gif0 prefixlen 64 scopeid 0x2
inet6 2001:470:1f10:83b::2 --> 2001:470:1f10:83b::1 prefixlen 128
inet6 2001:470:1f11:83b::1 prefixlen 64
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether d4:9a:20:e9:60:20
inet6 fe80::d69a:20ff:fee9:6020%en0 prefixlen 64 scopeid 0x4
inet 10.69.137.151 netmask 0xffffff00 broadcast 10.69.137.255
media: autoselect (100baseTX <full-duplex,flow-control>)
status: active
en2: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 0b:0b:0b:0b:0b:0b
inet6 fe80::d69a:20ff:fee9:6020%en2 prefixlen 64 scopeid 0x5
inet 169.254.130.218 netmask 0xffff0000 broadcast 169.254.255.255
media: autoselect (10baseT/UTP <full-duplex>)
status: active
fw0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 4078
lladdr d4:9a:20:ff:fe:e9:60:20
media: autoselect <full-duplex>
status: inactive
en1: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 1500
ether d4:9a:20:60:c7:9f
media: <unknown subtype> (<unknown type>)
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1448
inet 184.104.31.139 --> 172.31.255.1 netmask 0xffff0000
inet6 fe80::d69a:20ff:fee9:6020%ppp0 prefixlen 64 scopeid 0x8
vboxnet0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 0a:00:27:00:00:00
gif1: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
overcompensation:~ root# netstat -nr
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 10.69.137.2 UGSc 27 0 en0
default link#5 UCSI 0 0 en2
default 172.31.255.1 UGScI 1 0 ppp0
10.69.137/24 link#4 UCS 5 0 en0
10.69.137.2 0:e0:81:1:30:4d UHLWI 25 1 en0 1161
10.69.137.3 0:19:db:85:d2:9e UHLWI 0 0 en0 729
10.69.137.107 0:1d:7d:e7:16:5f UHLWI 0 139051 en0 1199
10.69.137.151 127.0.0.1 UHS 0 0 lo0
10.69.137.255 ff:ff:ff:ff:ff:ff UHLWbI 0 3 en0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 10 32880765 lo0
169.254 link#4 UCS 1 0 en0
169.254.130.218 127.0.0.1 UHS 0 0 lo0
169.254.255.255 link#4 UHLW 1 808 en0
172.31.255.1 184.104.31.139 UH 2 29750 ppp0
184.104 ppp0 USc 1 0 ppp0
209.51.181.2 10.69.137.2 UGHS 0 0 en0
Internet6:
Destination Gateway Flags Netif Expire
default 2001:470:1f10:83b::1 UGSc gif0
::1 ::1 UH lo0
2001:470:1f10:83b::1 2001:470:1f10:83b::2 UH gif0
2001:470:1f10:83b::2 link#2 UHL lo0
2001:470:1f11:83b::/64 link#2 UC gif0
2001:470:1f11:83b::1 link#2 UHL lo0
fe80::%lo0/64 fe80::1%lo0 Uc lo0
fe80::1%lo0 link#1 UHL lo0
fe80::%gif0/64 link#2 UC gif0
fe80::d69a:20ff:fee9:6020%gif0 link#2 UHL lo0
fe80::%en0/64 link#4 UC en0
fe80::d69a:20ff:fee9:6020%en0 d4:9a:20:e9:60:20 UHL lo0
fe80::%en2/64 link#5 UC en2
fe80::d69a:20ff:fee9:6020%en2 b:b:b:b:b:b UHL lo0
fe80::%ppp0/64 fe80::d69a:20ff:fee9:6020%ppp0 Uc ppp0
fe80::d69a:20ff:fee9:6020%ppp0 link#8 UHL lo0
ff01::/32 ::1 Um lo0
ff02::/32 ::1 UmC lo0
ff02::/32 link#2 UmC gif0
ff02::/32 link#4 UmC en0
ff02::/32 link#5 UmC en2
ff02::/32 fe80::d69a:20ff:fee9:6020%ppp0 UmC ppp0
And I can't ping6 the tunnel endpoint:
overcompensation:~ root# ping6 2001:470:1f10:83b::1
PING6(56=40+8+8 bytes) 2001:470:1f10:83b::2 --> 2001:470:1f10:83b::1
ping6: sendmsg: Network is down
ping6: wrote 2001:470:1f10:83b::1 16 chars, ret=-1
Request timeout for icmp_seq=0
ping6: sendmsg: Network is down
ping6: wrote 2001:470:1f10:83b::1 16 chars, ret=-1
Request timeout for icmp_seq=1
ping6: sendmsg: Network is down
ping6: wrote 2001:470:1f10:83b::1 16 chars, ret=-1
^C
--- 2001:470:1f10:83b::1 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
overcompensation:~ root# ifconfig gif0 up
overcompensation:~ root# ping6 2001:470:1f10:83b::1
PING6(56=40+8+8 bytes) 2001:470:1f10:83b::2 --> 2001:470:1f10:83b::1
ping6: sendmsg: Network is down
ping6: wrote 2001:470:1f10:83b::1 16 chars, ret=-1
Request timeout for icmp_seq=0
ping6: sendmsg: Network is down
ping6: wrote 2001:470:1f10:83b::1 16 chars, ret=-1
^C
--- 2001:470:1f10:83b::1 ping6 statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
I also tried adding my Lan IP (en0) to gif0
overcompensation:~ root# ifconfig gif0 tunnel 10.69.137.151 209.51.181.2
overcompensation:~ root# ping6 2001:470:1f10:83b::1
PING6(56=40+8+8 bytes) 2001:470:1f10:83b::2 --> 2001:470:1f10:83b::1
Request timeout for icmp_seq=0
Request timeout for icmp_seq=1
Request timeout for icmp_seq=2
Request timeout for icmp_seq=3
^C
--- 2001:470:1f10:83b::1 ping6 statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
overcompensation:~ root# ifconfig gif0 deletetunnel
And adding the PPTP client IP address, but I didn't think this would work because this IP is already in use by ppp0.
overcompensation:~ root# ifconfig gif0 tunnel 184.104.31.139 209.51.181.2
overcompensation:~ root# ping6 2001:470:1f10:83b::1
PING6(56=40+8+8 bytes) 2001:470:1f10:83b::2 --> 2001:470:1f10:83b::1
Request timeout for icmp_seq=0
Request timeout for icmp_seq=1
^C
--- 2001:470:1f10:83b::1 ping6 statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
Any suggestions on what to try next would be greatly appreciated.
I'm not sure about OSX/BSD, but linux requires a policy route because the 6in4 and PPTP servers have the same IPv4 address.
Perhaps the OSX GUI does this automatically? Or maybe OSX/BSD always routes IPv4 based on a source IP/interface matchup or something.
I can't see the local/remote endpoints for your 6in4 tunnel in that output. Are u using the PPTP assigned IPv4 for the local endpoint?
Yes the "ifconfig gif0 tunnel 184.104.31.139 209.51.181.2" is the local PPTP's IPv4 endpoint to HE's server IPv4 address (Chicago). I also tried it with the dhcp assigned IPv4 of the machine on en0 (10.69.137.151) to HE's server IPv4 and that didn't work either.
Probably needs policy routing like linux then. I never tried to do something like this with OSX or BSD. You need to set up routing such that when the source IP is the PPTP assigned IP, it routes through the PPTP tunnel, otherwise it routes through the normal NIC.
My guess is there's some variation of the 'route' command for the IPv6 gateway that is in the wrong place, or with the wrong settings. I know IPv4 traffic goes in and out of the PPTP VPN tunnel just fine, I can ping HE's IPv4 endpoint of the tunnel, and I can connect back from the outside internet to the machine through the tunnel over IPv4. It's more a question of why IPv6 refuses to go through the tunnel.
I've got:
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
tunnel inet 184.104.31.139 --> 209.51.181.2
inet6 fe80::d69a:20ff:fee9:6020%gif0 prefixlen 64 scopeid 0x2
inet6 2001:470:1f10:83b::2 --> 2001:470:1f10:83b::1 prefixlen 128
inet6 2001:470:1f11:83b::1 prefixlen 64
Internet6:
Destination Gateway Flags Netif Expire
default 2001:470:1f10:83b::1 UGSc gif0
::1 ::1 UH lo0
2001:470:1f10:83b::1 2001:470:1f10:83b::2 UH gif0
2001:470:1f10:83b::2 link#2 UHL lo0
2001:470:1f11:83b::/64 link#2 UC gif0
2001:470:1f11:83b::1 link#2 UHL lo0
and I can ping 2001:470:1f11:83b::1 (Lan IP) and 2001:470:1f10:83b::2 (Client Tunnel IP) but not 2001:470:1f10:83b::1 (HE Tunnel IP) or get out to the wider IPv6 net.
It looks like you have the LAN IPv6 on the tunnel interface, which is wrong. It should be directly on your LAN interface. The "Client IPv6" should be on the tunnel, the "Routed /64" should be on the LAN interface.
But that shouldn't stop you from pinging across the tunnel (presuming your using the tunnel IPv6 as the source).
As I said before, Linux requires policy routing because the PPTP & 6in4 services are on the same IPv4. So the machine has to route PPTP traffic from the interface IPv4 directly over the internet to the PPTP service, but route traffic from the PPTP tunnel assigned IPv4 to the same IPv4 destination (the 6in4 server) across the PPTP tunnel. On linux this requires routing based on the source address (aka a example of policy routing). Not sure about OSX. And not sure how to do that under OSX or BSD.
I got it o work OSX 10.6.4
The only thing I did in addition to the instructions was to unhook the "sand all traffic over vpn connection" under advanced on the he vpn connection
Wow sttun & jimb, you're totally right. I must have just screwed up my configuration from all the trial and error.
I cleared all IPv6 addresses from Ethernet and the VPN in Network prefs. Restarted the machine to reset everything. Entered the NetBSD/MacOSX config script in Terminal again. And made sure 'Send all traffic over VPN" was unchecked and viola! IPv6 out to the net through the tunnel. It just works, I made it much more difficult than it is.
i have same problem, but i am using OS 10.4 server, and it doesnt seem to have that option for sending all traffic....
And, interestingly, I had already had that "Send all traffic over PPTP tunnel" unchecked. But I am still having the same problem that sota767 originally described. I'm on a 10.6.x Macbook Pro.
sota767, could you post the interface configurations of ppp0 and gif0, and what you did to manually configured gif0 after bringing up the PPTP VPN connection? That was I can compare it to my configuration.
I am, as you were, able to ping across the PPTP tunnel, but not to the opposite end of the IPv6 transit across gif0. I have tried setting the "ifconfig gif0 tunnel" with the client address (which is static, and successfully configured on my ppp0 interface), and I've tried both the "correct" address for the server, and the other-end address of the ppp0 point-to-point. Which of those server addresses are you using on the "gif0 tunnel" command?
Maybe if I can just see the commands you are running to configure the gif0 interface, that might be enough. The ppp0 interface is pretty much handled by the Network preferences panel, and I think is right.
And, as noted, I've already turned off the "Send all traffic through" checkbox for that VPN interface.
Thanks!