-
Notifications
You must be signed in to change notification settings - Fork 394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPv6: support it or block it? #3
Comments
Maybe what we can do is assign pseudorandom IPv6 addresses to each endpoint, and add the required commands to route IPv6 traffic to the tunnel. |
What if the server does not have IPv6 connectivity? The traffic won't go anywhere so I guess it's what we want anyways? |
Correct, packets won't go anywhere if you don't have a route for them. I added a stopgap solution to block all IPv6 traffic on the client. But the block stays after the VPN is stopped since it's not tied to a virtual interface. Automatically assigning IPv6 addresses seems like a better solution. We may even use link-local addresses. |
All IPv6 is now sent to the server. Rules for NATing that traffic are missing, so IPv6 traffic is effectively dropped. If you know the proper iptables incantations to NAT the IPv6 traffic, feel free to add them :) |
Since dsvpn forwards all the client's traffic to the server, it is clearly made for users who want to access the internet through the VPN.
Currently, if I'm not mistaken, IPv6 isn't handled at all. Adding support for it shouldn't be to hard although it may make the command line quite bloated. What do you think of at least blocking it when in
client
mode so the user's IPv6 isn't "leaking"?The text was updated successfully, but these errors were encountered: