VPN connection problem to SonicWall

Ari Maniatis,

pluto is the vpn daemon. FQDN means fully
qualified domain name - I thought Astaro
supports only PreSharedKey and RSA authentication.
Try to change settings on your sonic wall.
Please let me and others know the result.

regards
ollion

ID_USER_FQDN means that the Pluto daemon expects an e-mail address of the form "user@domain" from SonicWall. I'm not familiar with the Astaro user interface, so I don't know how you have configured the ID of your Sonic Wall Peer. I am working directly with the configuration file /etc/ipsec.conf and there will be an entry 

rightid=user@domain

It seems that SonicWall sends you an ID_FQDN instead, which is a Fully Qualified Domain Name, i.e. a host name of the form "host.domain". In this case you must configure a host name in etc/ipsec.conf, too. This takes the form

rightid=@host.domain

The @ in front is important since it prevents Pluto to resolve it to an IP address using DNS and forces it to use it as a host ID string.

Regards

Andreas

[ 02 January 2002: Message edited by: Andreas Steffen ]

ID_USER_FQDN means that the Pluto daemon expects an e-mail address of the form "user@domain" from SonicWall. I'm not familiar with the Astaro user interface, so I don't know how you have configured the ID of your Sonic Wall Peer. I am working directly with the configuration file /etc/ipsec.conf and there will be an entry 

rightid=user@domain

It seems that SonicWall sends you an ID_FQDN instead, which is a Fully Qualified Domain Name, i.e. a host name of the form "host.domain". In this case you must configure a host name in etc/ipsec.conf, too. This takes the form

rightid=@host.domain

The @ in front is important since it prevents Pluto to resolve it to an IP address using DNS and forces it to use it as a host ID string.

Regards

Andreas

[ 02 January 2002: Message edited by: Andreas Steffen ]

After a second and closer examination of your log file I have come to the conclusion that it is SonicWall which is sending in fact an ID_USER_FQDN but that the configured and transmitted ID string is not an e-mail address. This is why the Pluto daemon on the Astaro firewall rejects it. In order to solve this problem you must either configure a valid e-mail address on the SonicWall or as an alternative configure a hostname (which on the SonicWall side
must not be preceded by a @ character).

Regards

Andreas

Thank you for your advice. I did even track down some messages where other people had similar problems with SonicWall talking to FreeS/wan.

It appears that the SonicWall transmits a field called "firewall identifier" and tells the remote end that it is in user@FQDN format. So I thought to put an identifier of that format into the field on the SonicWall. As you can see, the identifier looks in the right format - but it still doesn't work. The error is still the same.

Do you have any ideas of what to look at next? The error message is not very clear. I've done a Google search on the error code, but not much came up.

Thanks
Ari Maniatis

What SonicWall ID did you configure on the Astaro side? It seems that either it is not of type ID_USER_FQDN or it does not have the value 'sydney@oneumbrella.com.au'. Is it possible to configure ID_USER_FQDN IDs with the Astaro GUI?

Regards

Andreas

The Sonicwall has only one place in the GUI to set a firewall ID. That place doesn't allow choice between different types of ID (IP, FQDN, name@FQDN, etc). I have entered "sydney@oneumbrella.com.au", hence that identifier which appears in the log.

On the other hand, Astaro doesn't allow VPN names to be of the format name@FQDN. In fact putting a "@" casues a strange bug in Astaro web interface. But I presume it is not necessary to create a matching ID entry in the Astaro interface. At the Astaro end I am simply naming the connection "umbrella".

Cheers
Ari Maniatis

For FreeS/WAN to sucessfully setup an ISAKMP SA both type and value of the peer ID must match exactly.

There is absolutely no way around this!

As a workaround you could try to hack /etc/ipsec.conf and /etc/ipsec.secrets on the Astaro Firewall directly:

If the SonicWall peer is RIGHT then just edit
the rightid entry in ipsec.conf to

conn connectionname_1
     ...
     rightid=sydney@oneumbrella.com.au
     ...

In ipsec.secrets you must change the line with the preshared secret (PSK) to

sydney@oneumbrella.com.au @fish.your_domain : PSK ....

I don't know if these changes will be persistent or if the Astaro GUI will overwrite them the next time you make another configuration.

Regards

Andreas

It has just come to my mind that for PSK
authentication you must probably declare the IP
addresses of both connections ends in place of
their ID_FQDN or ID_USER_FQDN. So if your ipsec.secrets file already contains IP addresses just leave them untouched.

Regards

Andreas

Now I get the error message:

Jan  4 22:24:51 fish Pluto[4344]: | Peer's ID is ID_USER_FQDN: 'sydney@oneumbrella.com.au'
Jan  4 22:24:51 fish Pluto[4344]: "umbrella_1" #1: we require peer to have ID '203.17.212.74', but peer declares 'sydney@oneumbrella.com.au'

So, just for laughs I tried using the IP address in the SonicWall's identifier but ASL just complains that it requires the ID to contain a "@".

I also tried your suggestion of adding a "rightid" to ipsec.conf, but unfortunately ASL overwrites that file on a regular basis. Changing any packet filter rule, stopping and starting VPN, etc. At any rate I couldn't get IPSEC to run (even chrooting it) manually - I am not familiar with how the application runs.

Do you know whether switching to manual keying will help? IKE requires the firewall identifier, but does manual keying also? Every change I make requires me to go onsite to my customer to change SonicWall settings - that's why this process is a little slow for me.

Astaro: how do I log a feature request for an additional setting in the web interface for "remote firewall ID"? It appears that this might be all that is needed to get SonicWall interoperability.


Thank you for all your help - I really appreciate it.

Ari Maniatis