Skip to content
This repository has been archived by the owner on Jun 4, 2021. It is now read-only.

WIP: Streisand IPv6 support #1471

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

alimakki
Copy link
Collaborator

Adds IPv6 support to all of the provided VPNs Streisand has to offer.
Based off of PR #1361 by @nopdotcom

@clenga
Copy link

clenga commented Nov 9, 2018

ok so last night i ran into an issue that i will try to explain as best as possible. Yesterday i created a new linode because the original had been deleted for overdue balance. I booted a new linode and used a saved disk image to restore my original VPS config. I found the /streisand folder within and went through the procedure to generate a new localhost.html doc... heres where the problem happened. Although my linode settings were saved, the IP address changed for this linode... so the generated doc shows the new IP ADDRESS but in fact when i pulled up the localhost.html and tried downloading the certificate to access the nginx user profiles, the old IP address is imbedded in the certificate, causing my web browser to block me from proceeding forward... im sure if i just reinstall the ipv6 streisand fork this would fix the problem, but maybe there is another solution so that if a users VPS ip address changes, then streisand will clear out any old addresses from previous configs

@clenga
Copy link

clenga commented Nov 9, 2018

Also, i just did an updated clone of the ipv6 branch, and im back at the nginx user instructions, and when i select to login via the ipv6 captive portal the browser gives me this... https://drive.google.com/file/d/17IxOPctRQSboRNQvshxnPKEeVWzYlnbY/view?usp=drivesdk

@clenga
Copy link

clenga commented Nov 9, 2018

as you can see in this next screenshot, the ipv4 nginx url, brings me to a captive portal no issue . https://drive.google.com/file/d/1ZwD0dqG0nF0ekM_4eAzntS92tOpPQgP1/view?usp=drivesdk

although this is minor and a user can select the advanced option to proceed anyway, i figured ide point it out. Ill continue messing around and reporting any other needed adjustments. Besides this , it seems that your ipv6 branch @alimakki runs VERY smooth and efficient during the command line setup, much improved from when i originally started using streisand back in 2016

@alimakki
Copy link
Collaborator Author

@clenga thank you for the very detailed feedback. As you have experienced, it is not possible to copy and paste a streisand install from one machine to another, as distinct ssl certificates are generated for the streisand host in question and are not portable; if they did somehow work that would be a cause of concern. Your best best is to re-deploy to a new server.

Also, i just did an updated clone of the ipv6 branch, and im back at the nginx user instructions, and when i select to login via the ipv6 captive portal the browser gives me this... https://drive.google.com/file/d/17IxOPctRQSboRNQvshxnPKEeVWzYlnbY/view?usp=drivesdk

The IPv6 address could be missing from the gateway certificate's SANs, thanks for pointing that out, it should be easily addressable.

@clenga
Copy link

clenga commented Nov 16, 2018

ok so ive been continuing testing with the ipv6 branch @alimakki, and one of the websites that i use to test quality of the ipv6 connection stated this..

"Danger! IPv6 sorta works - however, large packets appear to fail, giving the appearance of a broken website. If a publisher publishes to IPv6, you will believe their web site to be broken. Ask your ISP about MTU issues; possibly with your tunnel. Check your firewall to make sure that ICMPv6 messages are allowed (in particular, Type 2 or Packet Too Big"

maybe this is a specific issue with linodes ipv6 or maybe this is simply fixed by adjusting ipv6 firewall rules within my VPS ... honestly im not sure because im still new to ipv6... but let me know what you think

@alimakki
Copy link
Collaborator Author

@clenga could you share the the site you used which gave the danger message?

@nopdotcom
Copy link
Member

I don't think we're doing anything that will break Path MTU Discovery. See http://test-ipv6.com/faq_pmtud.html for a technical explanation.

@clenga
Copy link

clenga commented Nov 17, 2018

@alimakki the url that @nopdotcom listed above^^ is the site that gave me that message... i will run another test and screenshot the results so you can see what i see... again, im new to ipv6 so this problem may not be with streisand but rather linode

@clenga
Copy link

clenga commented Nov 17, 2018

heres the test results so you can see what I see...
https://drive.google.com/file/d/1GRoxM8jSpPI1TppcclCHXP4BzmPk95Qj/view?usp=drivesdk

@clenga
Copy link

clenga commented Nov 17, 2018

im currently running the following setup:
~Galaxy S9 9.0 Pie Beta ZRK1 build
*T-Mobile US LTE
~OpenVPN by Arne ipv4/ipv6 dual stack config
*Tested dual stack ipv4/ipv6 with HTTP
tinyproxy (successfully)
~Ubuntu 16.04 LTS Linode VPS
~Connectivity to various URLs and Apps
(successfull)

Im going to try proxy.sh security check tool next and see what is produced

@nopdotcom
Copy link
Member

I don't think we should block this PR on it, but It Might Be Nice someday to generate, for example, WireGuard profiles that specify the server's IPv6 address as the VPN endpoint.

Copy link
Member

@nopdotcom nopdotcom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing major. Remaining work:

  • We have to get rid of 2001:db8::. That's a documentation-only prefix, and will cause confusion. I don't think this is mergeable without that change.
  • I added the notion of a "service" network at 10.10.10.10, for stuff all authenticated users should be able to get at. Should we create a similar fixed ULA for IPv6? fd10:1010:10::/64?
  • Aside from well-known addresses, it's generally considered bad form to hard-wire ULAs. Although there's an official way to generate them, OpenWrt just grabs some bits out of /dev/urandom and calls it a day.

Not sure how much time I have to work on this right now, but since I've been running this a bunch of places, I'd like to get it into mainline.

ExecStart=/sbin/{{ ocserv_firewall_rule_v6 }}

[Install]
WantedBy=multi-user.target
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing a trailing newline.

{% for item in upstream_dns_servers_v6 %}
dns = {{ item }}
{% endfor %}
ipv6-subnet-prefix = 64
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would using ipaddr, make life easier here? {{ ocserv_ipv6_network | ipaddr('prefix') }}

ocserv_firewall_rule_v6: "ip6tables --wait {{ streisand_iptables_wait }} -t nat -A POSTROUTING -j MASQUERADE"

ocserv_ipv4_network: "192.168.1.0/24"
ocserv_ipv6_network: "fda9:4efe:7e3b:03ea::/48"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, we should generate a ULA per Streisand system. For ocserv we'd only want a /64, though?

@@ -1,4 +1,4 @@
dev tun
dev tun-ipv6
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be conditional on having IPv6 enabled, or do we want this always-on because it will catch IPv6 leaks or something?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll have to test this scenario to check for leaks, thanks for pointing it out

proto tcp6

{% if streisand_ipv6_address is defined %}
server-ipv6 2001:db8:0:124::/64
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't use 2001:db8:: for anything. Do we want a second ULA for now, or to separate subnets inside our "main" ULA?

proto udp

{% if streisand_ipv6_address is defined %}
server-ipv6 2001:db8:0:123::/64
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, we can't use 2001:db8::; needs to be a ULA, I think.

dnsmasq_openvpn_udp_ipv6: "2001:db8:0:123::1001"

openvpn_server_tcp_ipv6_address: "2001:db8:0:124::/64"
openvpn_server_udp_ipv6_address: "2001:db8:0:123::/64"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No 2001:db8::.

@@ -6,6 +6,10 @@ dh none
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"

{% if streisand_ipv6_address is defined %}
push "route-ipv6 ::/0"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a side note, do we want to push IPv6 routes to people all the time anyway, to avoid IPv6 leaks?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, we definitely should. It's being done for WireGuard as is so others should follow suite

@@ -6,9 +6,14 @@ wireguard_server_private_key_file: "{{ wireguard_path }}/server.key"
wireguard_server_public_key_file: "{{ wireguard_path }}/server.pub"

dnsmasq_wireguard_ip: "10.192.122.1"
dnsmasq_wireguard_ipv6: "fde9:7496:c3d7:a47f::1001"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just another ULA reminder.

nopdotcom and others added 5 commits September 19, 2019 18:11
If a system has *existing* IPv6 connectivity, support some services over it.

sslh: Adding another listen line opens up the gateway (and ssh).

shadowsocks: Adding another listen address opens the service; obfs works too.

gateway: Adding the IPv6 address to the self-signed gateway SSL cert works.

Note that systems with IPv6 ingress get IPv6 egress for connection-oriented services for free; check with https://ipv6.google.com/
- branch based off of @nopdotcom's PR StreisandEffect#1361
- initial commit for supporting all VPNs over IPv6
- add IPv6 status
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants