Hurricane Electric's IPv6 Tunnel Broker Forums
May 20, 2013, 10:45:16 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Welcome to Hurricane Electric's Tunnelbroker.net forums!
 
   Home   Help Search Login Register  
Hurricane Electric's IPv6 Tunnel Broker Forums > General IPv6 Topics > IPv6 on Linux & BSD & Mac > Mac OS X 10.6 - Can't get IPv6 traffic through PPTP VPN Tunnel
Pages: [1]
« previous next »
  Print  
Author Topic: Mac OS X 10.6 - Can't get IPv6 traffic through PPTP VPN Tunnel  (Read 4840 times)
sota767
Newbie
*
Posts: 8


View Profile
« on: July 01, 2010, 09:33:04 pm »
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.
Logged
jimb
Hero Member
*****
Posts: 804


^^^ Warped picture


View Profile
« Reply #1 on: July 01, 2010, 11:33:10 pm »
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?
Logged
sota767
Newbie
*
Posts: 8


View Profile
« Reply #2 on: July 02, 2010, 12:24:54 am »
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.
Logged
jimb
Hero Member
*****
Posts: 804


^^^ Warped picture


View Profile
« Reply #3 on: July 02, 2010, 12:42:06 am »
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.
Logged
sota767
Newbie
*
Posts: 8


View Profile
« Reply #4 on: July 02, 2010, 11:35:18 am »
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.
« Last Edit: July 02, 2010, 11:41:22 am by sota767 » Logged
jimb
Hero Member
*****
Posts: 804


^^^ Warped picture


View Profile
« Reply #5 on: July 02, 2010, 04:25:31 pm »
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.
Logged
sttun
Jr. Member
**
Posts: 54


View Profile
« Reply #6 on: July 06, 2010, 11:24:16 am »
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
Logged
sota767
Newbie
*
Posts: 8


View Profile
« Reply #7 on: July 08, 2010, 08:32:42 am »
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.
Logged
annoyingspore
Newbie
*
Posts: 19


View Profile
« Reply #8 on: August 03, 2010, 11:28:17 pm »
i have same problem, but i am using OS 10.4 server, and it doesnt seem to have that option for sending all traffic....
Logged
distal
Newbie
*
Posts: 3


View Profile
« Reply #9 on: September 21, 2010, 11:17:55 am »
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!
Logged
Pages: [1]
  Print  
« previous next »
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!