[opus]

It could be MTU, but I doubt it. I’d expect the Windows client to have the same behavior. You can adjust the Mac’s MTU using the terminal:

sudo ifconfig en0 mtu 1200

Enter an MTU value between 1-1500. You shouldn’t have to go any lower than 1000 or so.

Another way to test MTU is to send pings of varying size:

ping -s 1472 x.x.x.x

The max MTU for your connection is the ‘-s’ value + 28. Be sure to do this test through the VPN tunnel, because the IPSec headers added to the packet will decrease the actual packet size allowed.

What’s performing NAT on the SonicWALL side? Is it the firewall itself, or the router or some other device in front of it?

[opus]

This isn’t an error of any sort or anything you need to worry about usually.

What NAT Traversal (NAT-T) actually is is a method of encapsulating IPSec packets within UDP packets. This is done because many NAT routers, especially older ones, will not pass IPSec properly.

All that the log message you are seeing means is that the device the SonicWALL is attempting to negotiate an IPSec connection with (in your case, the Mac) does not support NAT-T. IPSec packets will be sent normally, without being encapsulated within UDP.

This is explained in SonicWALL’s FAQs.

The log info you show indicates that the IKE negotiation is completing just fine. There’s nothing wrong with your VaporSec config. My conclusion is that the problem is your home’s NAT gateway. I’d lay odds that if you set up the Mac with a public IP or behind a more current NAT router it would work fine.

The reason the PC works fine is because the SonicWALL VPN client you are using does support NAT-T and is therefore able to get around the NAT router’s IPSec incompatibility.

[opus]

By the log it looks as though VaporSec is setting up Racoon to perform a main mode IKE negotiation, but the SonicWALL’s asecurity association(SA) for this client is set up with an IPSec gateway of 0.0.0.0 and is therefore expecting an aggressive mode IKE negotiation.

Main mode cannot be used when the IP address of one side is not known in advance, which is often the case with individual clients. Aggressive mode must be used, and the user_fqdn offered by the client must match the name of the SA it is connecting to on the SonicWALL.

[opus]

SonicWALLs use the Diffie-Hellman group naming scheme (i.e. 1, 2, 5) and not the bit size (i.e. 768, 1024, etc.).

The DH group for phase 2 perfect forward secrecy is configured under the advanced settings. Make sure perfect forward secrecy is set if it is on the client. After closing the advanced settings window make sure to update the main GroupVPN page od the changes made will not take.

[opus]

The SonicWALL has a default lifetime of either 28800 (8 hours) or 86400 seconds (24 hours), depending on the firmware version. The minimum lifetime is 120 seconds.

Is it possible that you set up racoon to the wrong time unit, e.g. using seconds instead of minutes or hours?

[opus]

XAUTH is optional for all security associations (SA) in a SonicWALL. It is never a requirement.

You can make another SA that will accept a connection from any IP. Just set the SA’s IPSec gateway value to ‘0.0.0.0’. However, there are a couple other problems to note:

1. Only one client can connect to a given SA. The GroupVPN SA is the only one that allows connections from multiple clients simultaneously. You have a Pro-VX, so you have the ability to create a lot of SAs, but if you have a lot of Mac users it could be tedious.

2. You have to enter a destination network into the SonicWALL’s SA. For a VPN client, its IPSec gateway address is virtually always the same as it’s host network. In other words, when you connect to the GroupVPN SA the SonicWALL uses the same IP address for the client’s IPSec gateway and destination network. However, no other SA in the SonicWALL can operate in this manner, and must have a predefined destination network. This can be worked around by assigning the client a virtual IP address in the same subnet that is predefined by the SA the client is connecting to. However, I don’t know if Kame/Racoon supports this.

[opus]

[quote:639cad324d]What we most likely need to do here is to create some gif tunnels with ifconfig and then add some routing statements to your OSX machine to let it know that separate networks are behind the IPSec conection. We just started doing this to some degree with the Draytek routers that need this to work well, but we were not considering multiple disparate remote networks off of the same connection. [/quote:639cad324d]

Nope, you don’t have to do all of that. You only need to properly define all of the networks behind the remote SonicWall when initializing setkey.

The main issues VaporSec and multiple networks are:

(This is how I see it, based on my admittedly limited experience with VaporSec, but a pretty good understanding of the IPSec implementation in Mac OS X. It certainly isn’t a knock of the app.)

1. VaporSec doesn’t use a config file for the setkey setup. While not a deal-breaker, it makes it harder to see what’s going on (IMHO) (unless I simply can’t find where VaporSec puts it). If there was a setkey config file you could easily modify it to allow the Mac to negoiate to all of the networks behind the remote gateway.

2. VaporSec relies on the “anonymous” identifier for phase 1 & 2 in the racoon.conf file. While not really a problem if you are connecting to only a single gateway, it pretty much rules out connecting to multiple gateways simultaneously.

[opus]

There was a major bug in older SonicWALL firewall firmware releases that allowed a main mode connection to the GroupVPN SA. This was fixed with the v6.3.0.0 release.

If you are using the original SOHO and TELE models as stated in a previous post then the last release available to you is v5.1.7.0, which contains this bug.

This bug is bad because it means that a vital authentication bit is not being used. IKE main mode requires that the IP address be used as part of the authentication. If the IP address of the client is not known in advance, then aggressive mode must be used and another piece of information (FQDN, user-FQDN, the SonicWALL’s unique firewall identifier, etc.) must be used instead.

In the GroupVPN SA there is no place to enter the IP addresses of the clients connecting to the SonicWALL, so by definition aggressive mode must be used.

[opus]

The release notes I saw on VersionTracker said that v0.9 uses main mode IKE negotiation instead of aggressive mode. If you are connecting to the GroupVPN SA of a SonicWALL aggressive mode must be used.

Don’t worry about the advanced options except to turn on PFS if the client is also set to use it.

[opus]

KAME/Racoon, the IPSec implementation built into OS X, do not support the XAUTH mechanism used by the SonicWALL and other IPSec gateways to support username-based authentication.

[Author]

Posts