Project

General

Profile

Issue #1532

does strongSwan support nat64?

Added by richard hu over 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Affected version:
5.4.0
Resolution:
No change required

Description

We want use iOS9 connect to strongSwan server with nat64 enable router.
Client runs in pure IPV6, and strongSwan runs in pure IPv4 amazon cloud.
Is this supported?

History

#1 Updated by Tobias Brunner over 5 years ago

  • Status changed from New to Feedback
  • Assignee changed from Martin Willi to Tobias Brunner

We want use iOS9 connect to strongSwan server with nat64 enable router.
Client runs in pure IPV6, and strongSwan runs in pure IPv4 amazon cloud.
Is this supported?

Why not. For strongSwan it should just look like a request from an IPv4 client.

#2 Updated by richard hu over 5 years ago

Tobias Brunner wrote:

We want use iOS9 connect to strongSwan server with nat64 enable router.
Client runs in pure IPV6, and strongSwan runs in pure IPv4 amazon cloud.
Is this supported?

Why not. For strongSwan it should just look like a request from an IPv4 client.

We have tested this case in lab, the client is an iPhone which works within IPV6, the server is located at AWS ec2 which only support IPV4. VPN connections had been established successfully, but the data transfer was failed.
According to IPSEC protocol, the user data is encrypted by ESP, it cannot be seen by nat64 device, so the address cannot be translated between IPV4 and IPV6. What nat64 device can see is external IP header, it cannot see the inside IP header and user date. How it works?
do we need any special configuration on strongswan?

#3 Updated by Tobias Brunner over 5 years ago

According to IPSEC protocol, the user data is encrypted by ESP, it cannot be seen by nat64 device, so the address cannot be translated between IPV4 and IPV6.

What address?

What nat64 device can see is external IP header, it cannot see the inside IP header and user date. How it works?

Why should that be changed? Did you assign a virtual IPv6 address to the iPhone? If so, just assign it an IPv4 address, which the server can then forward properly (or just use NAT64 there too to NAT the virtual IPv6 address to the server's public IPv4 address).

#4 Updated by richard hu over 5 years ago

Tobias Brunner wrote:

According to IPSEC protocol, the user data is encrypted by ESP, it cannot be seen by nat64 device, so the address cannot be translated between IPV4 and IPV6.

What address?

What nat64 device can see is external IP header, it cannot see the inside IP header and user date. How it works?

Why should that be changed? Did you assign a virtual IPv6 address to the iPhone? If so, just assign it an IPv4 address, which the server can then forward properly (or just use NAT64 there too to NAT the virtual IPv6 address to the server's public IPv4 address).

No, I assigned an IPV4 address. You mean the user data is IPV4, then encapsulated by IPV6 header. So the iPhone must work in dual stack, if VPN is not connected, it works in pure IPV6 environment, If VPN is connected, the user data first is handled by IPV4 fist, then encrypted by ESP, at last encapsulated by IPV6 header and forward out. Is it right?

we did a test, run a test ping app on ios. with capture the packet on nat64 device, we can see the ping packet (both v4 and v6) to outside and back inside.
But found the response ping packet's checksum is 0 on both v4 and v6 packet. And the ping response is illegal on wireshark GUI. And the ping failed.

#5 Updated by Tobias Brunner over 5 years ago

You mean the user data is IPV4, then encapsulated by IPV6 header.

Yes, if you assign a virtual IPv4 address the original packet should be IPv4. This gets encrypted and the ESP packet will be sent in an IPv6 packet.

As you can see on VirtualIP you may also assign IP addresses of both families if the client requests them.

we did a test, run a test ping app on ios. with capture the packet on nat64 device, we can see the ping packet (both v4 and v6) to outside and back inside.

What do you mean with "both v4 and v6"? Did you decrypt the ESP packet? Or did you try assigning a v4 and a v6 address?

But found the response ping packet's checksum is 0 on both v4 and v6 packet. And the ping response is illegal on wireshark GUI. And the ping failed.

Checksums might be incorrect in Wireshark because of hardware offloading. Make sure that's actually the reason for the failure on the client.

#6 Updated by richard hu over 5 years ago

Tobias Brunner wrote:

You mean the user data is IPV4, then encapsulated by IPV6 header.

Yes, if you assign a virtual IPv4 address the original packet should be IPv4. This gets encrypted and the ESP packet will be sent in an IPv6 packet.

As you can see on VirtualIP you may also assign IP addresses of both families if the client requests them.

we did a test, run a test ping app on ios. with capture the packet on nat64 device, we can see the ping packet (both v4 and v6) to outside and back inside.

What do you mean with "both v4 and v6"? Did you decrypt the ESP packet? Or did you try assigning a v4 and a v6 address?

I mean we capture the packet both on the nat64 device and on strongswan server.
on the storngswan server side, we can see the decrypted icmp request and icmp response from real server.
on the nat64 device, we can see the two direction packet (include request and response). the wireshark show response packet checksum illegal.

But found the response ping packet's checksum is 0 on both v4 and v6 packet. And the ping response is illegal on wireshark GUI. And the ping failed.

Checksums might be incorrect in Wireshark because of hardware offloading. Make sure that's actually the reason for the failure on the client.

we also captured ipv4 only vpn traffic, on both direction the udp checksum was 0. compare with ipv6 case, outgoing packet has checksum and response has no checksum. thus wireshark judge it as illegal.

we found following comments on stackoverflow -----
With UDP over IPv4, the checksum field is technically optional. If the value is 0, checksums are ignored. However, UDP over IPv6 requires the checksum to be non-zero, and datagrams with a zeroed checksum must be discarded. If the checksum should be zero, it has to be sent as FFFF. (Look for "UDP checksum" in RFC 2460, the RFC that specifies IPv6).
-------
if above is correct, then the problem is that strongswan did not response checksum?
is there a way to turn on checksum in such case?

#7 Updated by Tobias Brunner over 5 years ago

we also captured ipv4 only vpn traffic, on both direction the udp checksum was 0.

UDP checksums of the UDP-encapsulated ESP packet? This is without NAT64? Just between client and server? Where did you capture that?

compare with ipv6 case, outgoing packet has checksum and response has no checksum.

Outgoing from where? The NAT device or the client? Did you capture the response before or after the the NAT? How do the checksums look on the server? Also see CorrectTrafficDump.

#8 Updated by richard hu over 5 years ago

Tobias Brunner wrote:

we also captured ipv4 only vpn traffic, on both direction the udp checksum was 0.

UDP checksums of the UDP-encapsulated ESP packet? This is without NAT64? Just between client and server? Where did you capture that?

The network topology is like below:
iPhone(vpn client within IPV6) ---- mac(nat64) ---- nat(IPV4 nat device) ---- ec2(Strongswan server) ---- Real server
Since there is a nat device in IPV4 networking, the IPsec VPN must support NAT-T draft, which will insert an UDP header before ESP header. There is a nat64 device which will translate IPV6 to IPV4, due to the NAT-T, what nat64 device see is an UDP packet carried with ESP payload, it just treat it as a normal UDP packet.
We captured packet both on mac(nat64) and ec2(strongswan server).
On ec2 server, we can see client send packet to real server, and recevie packet from real server, then it forward back to vpn client. Both decrypted and encrypted packet looks normal.
On mac(nat64), we can see the request packet encapsulated with IPV6, and translated to IPV4 networking, it has UDP checksum. We also see the response packet encapsulated by IPsec with UDP checksum 0, then it is translated to IPV6, and be recognized as illegal packed due to checksum issue.

compare with ipv6 case, outgoing packet has checksum and response has no checksum.

Outgoing from where? The NAT device or the client? Did you capture the response before or after the the NAT? How do the checksums look on the server? Also see CorrectTrafficDump.

On mac(nat64) device, the request from client to server has UDP checksum, but the response from server to client has no UDP checksum(0x0000).

#9 Updated by Tobias Brunner over 5 years ago

I had a look at RFC 3948 (UDP Encapsulation of IPsec ESP Packets). In section 2.1 it says the following:

The UDP header is a standard [RFC0768] header, where

   o  the Source Port and Destination Port MUST be the same as that used
      by IKE traffic,
   o  the IPv4 UDP Checksum SHOULD be transmitted as a zero value, and
   o  receivers MUST NOT depend on the UDP checksum being a zero value.

So the checksum SHOULD actually be zero (but it's OK if it is not). I guess if the NAT64 device drops the packet due to that it is wrong (or should perhaps just fix the checksum if it has a problem if it is zero).

#10 Updated by richard hu over 5 years ago

Tobias Brunner wrote:

I had a look at RFC 3948 (UDP Encapsulation of IPsec ESP Packets). In section 2.1 it says the following:

[...]

So the checksum SHOULD actually be zero (but it's OK if it is not). I guess if the NAT64 device drops the packet due to that it is wrong (or should perhaps just fix the checksum if it has a problem if it is zero).

I also captured the packet on iPhone, it could receive the IPV6 response with UDP checksum 0x0000. I am not sure whether iPhone discard this packet.

According to RFC 2460(IPv6 Specification):
o Unlike IPv4, when UDP packets are originated by an IPv6 node,
the UDP checksum is not optional. That is, whenever
originating a UDP packet, an IPv6 node must compute a UDP
checksum over the packet and the pseudo-header, and, if that
computation yields a result of zero, it must be changed to hex
FFFF for placement in the UDP header. IPv6 receivers must
discard UDP packets containing a zero checksum, and should log
the error.

#11 Updated by Tobias Brunner over 5 years ago

So the checksum SHOULD actually be zero (but it's OK if it is not). I guess if the NAT64 device drops the packet due to that it is wrong (or should perhaps just fix the checksum if it has a problem if it is zero).

I also captured the packet on iPhone, it could receive the IPV6 response with UDP checksum 0x0000. I am not sure whether iPhone discard this packet.

I guess if it follows RFC 2460 to the letter ("IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error.") and does not support RFC 6935 (which I guess applies to UDP-encapsulated ESP, see RFC 6936) it would:

                                                              To improve
   support for IPv6 UDP tunnels, this document updates RFC 2460 to allow
   endpoints to use a zero UDP checksum under constrained situations
   (primarily for IPv6 tunnel transports that carry checksum-protected
   packets), following the applicability statements and constraints in
   [RFC6936].

So perhaps the NAT64 device should compute the UDP checksum when it translates from IPv4 to IPv6. As per RFC 6146, section 3.7:

   The translation of the packet is as specified in Sections 4 and 5 of
   the IP/ICMP Translation Algorithm [RFC6145], with the following
   modifications:
   ...
                                            ... In addition, the TCP
      or UDP checksum must also be updated to reflect the translated
      addresses and ports ...

And RFC 7915, section 4.5 (which recently replaced RFC 6145):

...
For UDP packets that do not contain a UDP checksum (i.e., the UDP
checksum field is zero), the translator SHOULD provide a
configuration function to allow:

   1.  Dropping the packet and generating a system management event that
       specifies at least the IP addresses and port numbers of the
       packet.

   2.  Calculating an IPv6 checksum and forwarding the packet (which has
       performance implications).

#12 Updated by richard hu over 5 years ago

I am trying to use another nat64 to verify this issue. Is there any successful case from your knowledge?

#13 Updated by Noel Kuntze over 4 years ago

  • Status changed from Feedback to Closed
  • Resolution set to No change required

Also available in: Atom PDF