IPv6 Over OpenVPN

bert64

I am attempting to configure an IPv6 VPN… I currently have V6 routing fine between internal subnets and over the internet, i have created an openvpn instance within pfsense and ipv4 is working fine over it however i cannot for the life of me get v6 to work...

I have allocated a /64 block to the ipv6 tunnel network, and specified my /48 under the ipv6 local network which should allow openvpn users to route to the other hosts on the network. When i connect, using the latest beta of tunnelblick on macosx and openvpn 2.3.1 on linux the tap interface is allocated an ipv6 address of ::1000 within the subnet i specified, while the openvpn server has an address of ::1. The client also adds the route to the /48, which it sends via the link local address of the openvpn server on tap0.
I have also created firewall rules to permit the traffic, and have even tried allow all ipv6 traffic to see if that would help.

I cannot ping from the client to the server over v6, and running tcpdump on the server the packets never arrive.
If i try to ping the client from the server i get the following error:

ping6: sendmsg: Address family not supported by protocol family
ping6: wrote <subnet>::1000 16 chars, ret=-1

Any suggestions as to what could be wrong? According to the pfsense documentation this should all work as i've configured it...</subnet>

dotOne

Add these lines to the advanced configuration

We are default route for IPv6

push "route-ipv6 ::/0"

/Andre

bert64

Tried that, it then creates a default route on the client via tun0 but i still can't get v6 traffic to go anywhere…

jimp

I've also been seeing that error on one of my routers on a recent snapshot. I haven't yet tracked down the source or had time to update that to a more recent snapshot though.

Before anything else, I'd upgrade to a current snapshot and see if the problem still exists.

Usually that error comes from the system trying to use the "wrong" address type in some way, for example trying to send IPv4 traffic to an IPv6 address but that doesn't appear to be the case, at least as far as I could see.

jimp

I tracked down the cause of this. The next new snapshot will work again.

bert64

@jimp:

I tracked down the cause of this. The next new snapshot will work again.

Great thanks, all seems to be working as it should with the 19th june snapshot.