-
Notifications
You must be signed in to change notification settings - Fork 2k
WIP: Streisand IPv6 support #1471
base: master
Are you sure you want to change the base?
Conversation
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 |
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 |
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 |
@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.
The IPv6 address could be missing from the gateway certificate's SANs, thanks for pointing that out, it should be easily addressable. |
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 |
@clenga could you share the the site you used which gave the danger message? |
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. |
@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 |
heres the test results so you can see what I see... |
im currently running the following setup: Im going to try proxy.sh security check tool next and see what is produced |
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. |
07b36af
to
b41e2d2
Compare
There was a problem hiding this 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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just another ULA reminder.
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
cd17cd9
to
af78894
Compare
Adds IPv6 support to all of the provided VPNs Streisand has to offer.
Based off of PR #1361 by @nopdotcom