search

adrienverge / openfortivpn

Client for PPP+TLS VPN tunnel services
GNU General Public License v3.0
2.6k stars 317 forks source link

[Feature Request] IPv6 support #112

Open imp1sh opened 7 years ago

imp1sh commented 7 years ago

Hi,

I've been using this tool for a while now and it works great, thank you. There's only one thing. When I connect my interface ppp0 only has an IPv4 address, no IPv6 at all.

I would like to route IPv6 through the tunnel though. Could you please give a statement what the overall IPv6 support status is and if it's not supported yet, what are the plans on supporting IPv6?

Thank you very much

DimitriPapadopoulos commented 7 years ago

I agree there's an issue with IPv4 / IPv6.

Example:

I use http://ipv6-test.com to test IPv4 vs. IPv6 connectivity:

free

openfortivpn

mrbaseman commented 7 years ago

Most of the routing code is still purely ipv4 capable. If your ipv4 name servers deliver ipv6 addresses and you have a default route through the ssl tunnel, and your gateway there handles nat46, this would be a scenario that should work out of the box, but it would not require any ipv6 capability in openforticlient

imp1sh commented 7 years ago

This ticket is not about nat64 at all. What I would like to see is the ability to get assigned a valid UGA from the pool that's defined in fortigate's VPN server settings. Beyond that expected behaviour of a VPN client is to get all the routing entries that are configured in the VPN service, e.g. a default route or some static routes. Third DNS servers. I consider this a feature request. Please consider to implement, because IPv6 to me has become a matter of course.

mrbaseman commented 7 years ago

Yes, for sure a lot needs to be done to have full ipv6 support in the client. In my previous post I just wanted to draw a rough picture about what I would currently expect to work. Everything you mentioned in your last post still needs to be implemented, and if anyone wants to assist us here I would be happy to review and test pull requests that address (parts of) the problem.

mrbaseman commented 5 years ago

Reviving this ticket, I would say IPv6 support is still something that we all regard as an important thing to implement in the long term.

It is, however, a very big task, for which large parts of the code have to be re-written. I would say this is the feature that would qualify for an openfortivpn 2.0.0 release in the future.

I don't have a clue (yet) if this can be split into individual smaller tasks. Probably yes (introduction of IPv6 address objects, dns lookups, receiving an IPv6 address for the tunnel, handling of IPv6 routes, ...). I don't know (yet) how strong these tasks depend on each other. Probably for Mac and BSD at least some parts are easier to implement, because some tasks are done via syscalls to tools that are already IPv6 capable. Maybe a code review and assessment of individual tasks on the way to full IPv6 support helps to define feasible work packages.

imp1sh commented 5 years ago

As a matter of fact I just contacted Fortigate's support about what their official Linux client supports. As it turns out it doesn't support IPv6 either. On top of that I received the information that a tunnel that is connected through an IPv4 address cannot transport IPv6 through the tunnel at all. That's really something, isn''t it? I begin to think those Fortigate devices really suck with IPv6. Our device won't transport more then 400 Mbit/s via IPv6 while IPv4 is roughly 1500 Mbit/s. Thank you Fortigate. We keep thinking about migrating away from those brand.

mrbaseman commented 5 years ago

Thanks for sharing this information. It adds another important aspect to the topic. However, please be careful about the wording. We would like to have objective discussions with emotional restraint. Also, it would be interesting to know if the restraint that an IPv4 tunnel can not transport IPv6 traffic at all applies to a specific version of FortiOS, and with the performance issue the model of that device, OS version, configuration etc. may have an impact...

imp1sh commented 5 years ago

The Limit on IPv6 traffic is directly attached to the model which in my case is F60D. The limit of not being able lto transport IPv6 traffic through a tunnel that has been established with IPv4 I do not know. What I also don't know if it's the other way around, if IPv4 traffic cannot be transported when the tunnel has been established through IPv6.

mrbaseman commented 5 years ago

Thanks for the additional information. We have a couple of 60D's too. They are out of sale now, and the subsequent model 60E is available, which has the newer NP6Lite networking processor asic. It's still the "Lite" variant for the entry-level appliances, but the NP6 generation of the E series fully supports IPv6 in hardware whereas the models with the NP4 generation have to handle IPv6 in software.

imp1sh commented 5 years ago

I found out about those differences but only way AFTER we bought the device. Even today when you look at the specification sheets of current devices you won't find any detail about differences between IPv4 and IPv6 throughput. You also won't find any information about what processor type is being used in which device at all.

mrbaseman commented 5 years ago

I believe the whole E series has NP6, but I don't have a reference for that at hand. If in doubt you can ask your reseller. But this discussion has gone a bit off-topic now. This issue is about future plans to implement IPv6 support in openfortivpn.

gittela commented 5 years ago

It is correct that ipv6 support in ipv4 (and vice versa) SSLvpn tunnels on Fortigate i kind of lacking, our company (an ISP) had several rounds with them on this issue. We shifted our focus away from SSLvpn because of this. However, the biggest problem now is actually that ipv6 persist outside the tunnel. Would it be possible to an an option to take down any existing ipv6 routes while connected? Possibly by calling a if-down and if-up script?

mrbaseman commented 5 years ago

@gittela I guess the problem of the separation of ipv4 and ipv6 features is due to the fact that with NP4 processors IPv4 traffic is handled in hardware whereas IPV6 is done in software. I would expect this problem to go away with some FortiOS version (maybe 6.x) in combination with E series hardware or so. Anyhow, this doesn't help anyone running D series hardware and it's highly speculative from my side. Taking down the ipv6 routes should be possible with pppd ip-up/down scripts (see the wiki). Of course this is far from being enforced by the vpn gateway, but to be honest, even for the pushed ipv4 default route the organization running the vpn gateway can never be sure that the client doesn't change the routing manually or run a second vpn in parallel.

dwmw2 commented 3 years ago

I've set up a test Fortigate VM and played with IPv6. It does still seem to be true (this is FortiOS 7.0.0) that you the server will only give you the same IP protocol that you used to connect to it.

So my SSL-VPN config on the server has both Legacy IP and IPv6 ranges attached to it. If my connection to the server over the public Internet is IPv6, I get an IPv6 address in the tunnel. If my connection to the same SSL-VPN is over Legacy IP, I get a Legacy IP address in the tunnel. Both of them work fine with OpenConnect now but only one at a time.

rnhmjoj commented 3 years ago

What do you think of supporting connecting to a gateway from an IPv6-only network (with NAT64/DNS64)? I think it would only be necessary to try an AAA query first and then using AF_INET6 to connect to the gateway, but I may be wrong.

dwmw2 commented 3 years ago

Yes, that will work. It doesn't have much to do with the VPN client or the server. Just set up DNS to point to an IPv6 address which is doing NAT64 to the server, and the client uses that.

You could probably use the--resolve option to OpenConnect, and a public NAT64 service, to test. Connectivity over IPv6, as well as IPv6 transport, is all fully working in OpenConnect HEAD now.

dwmw2 commented 3 years ago

Confirming that works... Over IPv6 you only get the IPv6 address in the tunnel:

 $ sudo ip tuntap add mode tun dev tun0 user $LOGNAME
 $  ./openconnect --protocol  fortinet fortigate.infradead.org:8443  -i tun0 -s /bin/true -u dwmw2 
GET https://fortigate.infradead.org:8443/
Connected to [2001:8b0:10b:1234::110]:8443
SSL negotiation with fortigate.infradead.org
Connected to HTTPS on fortigate.infradead.org with ciphersuite (TLS1.3)-(ECDHE-SECP384R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
Password: 
POST https://fortigate.infradead.org:8443/remote/logincheck
GET https://fortigate.infradead.org:8443/remote/fortisslvpn_xml
DTLS is enabled on port 8443
Got IPv6 DNS server 2001:8b0:10b:1::1
Got IPv6 DNS server 2001:8b0:10b:1:21d:7dff:fe04:dbe2
Got IPv6 address fdff:ffff::1/120
Got IPv6 route ::/0
Idle timeout is 5 minutes.
Established DTLS connection (using GnuTLS). Ciphersuite (DTLS1.2)-(ECDHE-SECP384R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM).
Requesting calculated MTU of 1331
Configured as fdff:ffff::1/120, with SSL disconnected and DTLS connected
Session authentication will expire at Tue May  4 04:05:11 2021

Over Legacy IP you get only Legacy IP:

 $  ./openconnect --protocol  fortinet fortigate.infradead.org:8443  -i tun0 -s /bin/true -u dwmw2 --resolve fortigate.infradead.org:178.238.156.110
GET https://fortigate.infradead.org:8443/
Connected to 178.238.156.110:8443
SSL negotiation with fortigate.infradead.org
Connected to HTTPS on fortigate.infradead.org with ciphersuite (TLS1.3)-(ECDHE-SECP384R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
Password: 
POST https://fortigate.infradead.org:8443/remote/logincheck
GET https://fortigate.infradead.org:8443/remote/fortisslvpn_xml
DTLS is enabled on port 8443
Got IPv4 DNS server 90.155.92.193
Got IPv4 DNS server 90.155.92.209
Got Legacy IP address 10.212.134.200
Got IPv4 route 192.168.122.0/255.255.255.0
Idle timeout is 5 minutes.
Established DTLS connection (using GnuTLS). Ciphersuite (DTLS1.2)-(ECDHE-SECP384R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM).
Requesting calculated MTU of 1351
Configured as , with SSL disconnected and DTLS connected
Session authentication will expire at Tue May  4 04:05:28 2021

And if you use NAT64 to reach the server over Legacy IP, that's what you get:

 $  ./openconnect --protocol  fortinet fortigate.infradead.org:8443  -i tun0 -s /bin/true -u dwmw2 --resolve fortigate.infradead.org:2001:8b0:6464:0:666:616:b2ee:9c6e
GET https://fortigate.infradead.org:8443/
Connected to [2001:8b0:6464:0:666:616:b2ee:9c6e]:8443
SSL negotiation with fortigate.infradead.org
Connected to HTTPS on fortigate.infradead.org with ciphersuite (TLS1.3)-(ECDHE-SECP384R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
Password: 
POST https://fortigate.infradead.org:8443/remote/logincheck
GET https://fortigate.infradead.org:8443/remote/fortisslvpn_xml
DTLS is enabled on port 8443
Got IPv4 DNS server 90.155.92.193
Got IPv4 DNS server 90.155.92.209
Got Legacy IP address 10.212.134.200
Got IPv4 route 192.168.122.0/255.255.255.0
Idle timeout is 5 minutes.
Established DTLS connection (using GnuTLS). Ciphersuite (DTLS1.2)-(ECDHE-SECP384R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM).
Requesting calculated MTU of 1331
Configured as , with SSL disconnected and DTLS connected
Session authentication will expire at Tue May  4 04:05:40 2021
rnhmjoj commented 3 years ago

Nice, thank you. I gave a quick look at tunnel.c and it's not so easy: the IP literal is being stored and there are lots of places where IPv4 is assumed, besides it seems the address is also used (for routing?) in ipv4.c, I don't know what to do here.

dwmw2 commented 3 years ago

Do you specifically want openfortivpn to work with IPv6, or would you be content with any open source client?

As author of OpenConnect I'm trying to limit my interactions here to talking about the protocol and generic discussion about how the servers behave, without giving the most direct and obvious answer that occurs to me...

rnhmjoj commented 3 years ago

I'm fine with using openconnect, but the more IPv6-enabled applications, the better. I wanted to make a patch to fix openfortivpn, but it seems beyond my abilities and limited free time.

fluboi commented 2 years ago

FortiOS 7.0 bring the ability to do dual stack (IPv4 and IPv6 simultaneously through the same tunnel). It would be great to see that working also with openfortivpn. :)