Hello,
I have a rb 433 ah with ros 6.27. I managed to setup a tunnel for ipv6 and my clients get ipv6 conectivity. But pptp clients get only ipv6 address but link local default route in windows. What can be wrong?


PPP adapter VPN Home:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : VPN Home
Physical Address. . . . . . . . . :
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:470:20c7::3(Preferred)
Link-local IPv6 Address . . . . . : fe80::3%59(Preferred)
IPv4 Address. . . . . . . . . . . : 10.10.248.3(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : fe80::f%59
0.0.0.0
DHCPv6 IAID . . . . . . . . . . . : 886073317
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1B-65-D8-B9-D0-67-E5-3B-0E-23

DNS Servers . . . . . . . . . . . : 95.77.94.88
78.96.7.88
NetBIOS over Tcpip. . . . . . . . : Enabled

Thanks

Link local default route is actually a normal thing in IPv6.
You also see lots of link-local next hops in ospf.

All the next hop does is tell a host where to send a packet for a given destination.
The next hop address never appears in the IP header, so it doesn't matter if it's a link-local address.

Your problem is more likely to be in the routing of the public prefix.
Are you delegating prefixes to the VPN clients, or simply placing a /64 onto the server's pptp and using SLAAC to assign individual hosts? - in other words, if you had 5 clients connected at once, would they have 5 different /64s or just be 5 different hosts in the same /64?

Hi,
I`m using /64 prefix with SLAAC both for non pptp clients and for pptp. It seems to not forwarding ipv6 packets becouse i cand not ping any ipv6 address and not the gateway. Routing has nothing to do with ping some address in the same /64 subnet

Here is my ipv6 config maybe helps....
/ipv6 dhcp-server
add address-pool=ipv6-pool disabled=no interface=lanbridge name=server1
/ipv6 pool
add name=ipv6-pool prefix=2001:470:20c7::/48 prefix-length=64
/ipv6 address
add address=2001:470:1f1a:233::2 comment="ip 6 extern" interface=sit1
add address=2001:470:20c7::1 comment="clasa 6 routata" from-pool=ipv6-pool interface=lanbridge
/ipv6 nd
set [ find default=yes ] advertise-dns=yes interface=lanbridge other-configuration=yes
add advertise-dns=yes hop-limit=1 interface=pptp-in-kiaunel other-configuration=yes
add advertise-dns=yes hop-limit=1 other-configuration=yes
/ipv6 route
add distance=1 dst-address=2000::/3 gateway=2001:470:1f1a:233::1
[admin@MikroTik] >
And ppp config
[admin@MikroTik] > ppp export compact
# apr/16/2015 19:20:51 by RouterOS 6.27
# software id = K994-1W4A
#
/ppp profile
set 0 bridge=lanbridge dhcpv6-pd-pool=ipv6-pool remote-ipv6-prefix-pool=ipv6-pool
set 1 bridge=lanbridge dhcpv6-pd-pool=ipv6-pool remote-address=dhcp remote-ipv6-prefix-pool=ipv6-pool
/ppp secret
add local-address=10.10.248.1 name=korolis password=xxxxxxxx remote-address=10.10.248.2
add local-address=10.10.248.1 name=server password=xxxxxxxxx remote-address=10.10.248.4 remote-ipv6-prefix=2001:470:20c7::/64
add local-address=10.10.248.1 name=kiaunel password=xxxxxxxxx profile=default-encryption remote-ipv6-prefix=2001:470:20c7::/64
[admin@MikroTik] >

for fun - try to ping ff02::1%59 (all IPv6 speakers on L2TP interface) and ff02::2%59 (all ipv6 routers on L2TP interface)

(and they say IPv6 has no broadcast)

It sounds like neighbor discovery is broken on this link.

C:\Windows\system32>ping ff02::1%59

Pinging ff02::1%59 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.

Ping statistics for ff02::1%59:
Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),
Control-C
^C
C:\Windows\system32>

C:\Windows\system32>ping ff02::2%59

Pinging ff02::2%59 with 32 bytes of data:
PING: transmit failed. General failure.
PING: transmit failed. General failure.
PING: transmit failed. General failure.

Ping statistics for ff02::2%59:
Packets: Sent = 3, Received = 0, Lost = 3 (100% loss)
Control-C
^C
C:\Windows\system32>
C:\Windows\system32>ping fe80::20c:42ff:fe3b:28bb%3

Pinging fe80::20c:42ff:fe3b:28bb%3 with 32 bytes of data:
Reply from fe80::20c:42ff:fe3b:28bb%3: time=5ms
Reply from fe80::20c:42ff:fe3b:28bb%3: time=1ms
Reply from fe80::20c:42ff:fe3b:28bb%3: time=1ms

Ping statistics for fe80::20c:42ff:fe3b:28bb%3:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 5ms, Average = 2ms
Control-C
^C
C:\Windows\system32>
Thios is now my default gw in pptp client

Thios is now my default gw in pptp client

Do the multicast pings work with %3 in stead of %59?

(the %xx number denotes which physical interface index to use when the address is ambiguous)

i think yes
I can not understand why the pptp interface is treated diferent than lan ... in lan i have a fully working SLAAC ipv6 dual stack. Also i did not manage to make dhcpd6 server work by asingning DUID for clients .. i get wrong duid ... but this is another problem.. for now i just would like to have ipv6 conectivity when i`m remote. Could be a windows pptp client problem? Seems to me you know well ipv6, can you try on one routerboard this scenario to see if it works?

Did any of the replies look like they had the MAC addresses of devices at the main site?

Do you see any neighbors on the interface?
netsh int ipv6 show nei 3
(short for: netsh interface ipv6 show neighbor 3) (3 being the interface index)

look for neighbors other than the ff02::1:ffxx:xxxx addresses - those are 'solicited node address' multicast addresses - a way to stop "arp" (ND) from being a broadcast at layer 2. (seems kind of silly to me, but hey, it's a brave new world)

Interface 54: VPN Home


Internet Address Physical Address Type
-------------------------------------------- ----------------- -----------
2001:470:20c7::3 Permanent
fe80::f Permanent
ff02::1 Permanent
ff02::2 Permanent
ff02::c Permanent
ff02::16 Permanent
ff02::fb Permanent
ff02::1:2 Permanent
ff02::1:ff00:3 Permanent