Topic: SonicWall VPN Client ???

[Tim Jabaut]

I cannot use the SonicWall VPN Client behind my SME v5 server to connect to my office.

It is properly passing UDP 500 (IKE) traffic, as the negotiation is taking place; however I cannot ping any servers, I keep getting Request Timed Out.

Any clues???

[WXP]

Hello,

I'm not a VPN guru but I read some stuff here so I'm gonna try to help !

Could you please give more information..

- What OS are you running SonicWall VPN Client on ?
- Did you try to get connected with SonicWall VPN Client to your VPN Server from somewhere else ? I mean, is there a problem only when you try to get connected to your office VPN when you are behind your SME v5 Server ?

If the connection is established, it's a good point !

Just to know, are you sure you gave different IP adresses to your computers..

As I said above, I'm not a VPN guru and actually I never tried it but I would like to...
So I'm going to test it soon I hope

Good Luck man !

------
WXP The happy dude

[WXP]

Could help : http://linux.oreillynet.com/pub/a/linux/2001/06/22/linux_security.html

see ya

[Tim Jabaut]

The client is running on Windows 2000 Pro.

It works fine if I take the E-Smith box out of the picture.

I can see through the SonicWall Client that the IKE negotiation is going through, however, any attempts to PING a REMOTE (now local via VPN) server results in a Timeout. I am also not able to use the Microsoft Terminal Services client to connect via VPN so it is not simply an ICMP block.

I am really stuck at this point.

Any ideas???

[WXP]

Did you try another VPN Client ?

[Tim Jabaut]

It cannot be the client, as it works fine without the E-Smith box in the middle.

I am passing IKE packets (PORT 500) successfully back and forth. The problem may lie with Protocol 50, the ESP Protocol for IPSEC.

I would just like to know any easy way to sniff or monitor the IP traffic to see what is being blocked.

Is it possible that SQUID is somehow my ability to PING???

[Franck]

IPSEC VPN needs a special masquerading module (ip_masq_ipsec) in order to work across a linux 2.2 "nat" router. I don't know if it is available with SME 5

You should also add an ipchains rule in order to accept ESP (protocol 50) paquets

[Justin]

Tim, you cannot just natively run a IPSEC VPN connection from behind any NAT enabled device. This has nothing to do with e-smith but the fact that e-smith is doing NAT for your network.

Part of the IPSEC protocol is a feature called the AH (Authentication Header). Basically this is a hash (MD5 or SHA1 usually) of the contents of the packet that is used to authenticate the packet as being legitimate.

Since NAT changes the contents of the packet the hash will no longer match the contents and therefore the SonicWall thinks the packet is either forged or illegitimate. The Sonicwall will instantly drop the tunnel and hence your ping won't make it through.

There is a work around from some vendors called NAT-T which basically encapsulates the VPN packets into UDP traffic sent across the IKE ports. It seems to work with minimal overhead but there are some security considerations that need to be addressed. (DOS, forged UDP, and host mapping among other things)

Justin.

[Ritchie Logan]

OK...

I've been watching this thread for a while to see if anyone worked this out!

I have an e-smith box as my firewall/gateway/NAT etc etc and am quite happily connecting to my office from my laptop running NT4 (sheesh) over an IPSec VPN (Nortel Extranet Client) from behind e-smith.

In e-smith 4.1.2 there was a problem which required modification before IPSec would get masq'd OK (needed to add an IPCHAINS command for UDP 500). I reported this, and I'm pleased to say it got fixed for SME5.

However, when I upgraded I discovered that IPSec masqing is disabled by default. I suspect this is because VPN functionality has now become part of the servicelink deal.

The good news is that it is possible to activate it. I thought long and hard before posting this solution, but I've decided this does not take anything from the e-smith (Mitel) people, because the servicelink aspect of VPN is intended for securely connecting 2 e-smith boxes over the internet as a WAN. The functionality I (and yourselves) require is simply to allow the masqing and pass through of IPSec packets.

The following commands enable the masqing of IPSec in SME5:
> /sbin/e-smith/db configuration setprop masq ipseq yes
> /sbin/e-smith/signal-event remoteaccess-update

you can also check the IPSec packets are getting masq'd by doing
> /sbin/ipchains -L -n
This will give you a complete list of all ipchains.
I have 2 chains corresponding to the above rules:
ACCEPT  ipv6-crypt---0.0.0.0/0       n/a
ACCEPT  udp  ------  0.0.0.0/0       500 -> 500

Of course.... you can always start them manually by entering the following lines - substituting $OUTERNET for your external IP:
> /sbin/ipchains --append input -p 50 -s 0/0 -d $OUTERNET -j ACCEPT
> /sbin/ipchains --append input -p udp -s 0/0 500 -d $OUTERNET 500 -j ACCEPT

This should sort you out.

Ritchie

[Dan G.]

I have been pulling my hair out trying to get a CheckPoint VPN-1 SecureClient to connect, and I still can't work it out.  I have entered the commands your post gives, and verified them with /sbin/ipchains -L -n --- they are there, but no dice on the connection.  SecureClient times out, unable to connect.

I have tried the "Advanced IKE Settings" options "Force UDP Encapsulation," and even enabled "Support IKE over TCP" for giggles --- still, no dice.

Does anyone have this working with CheckPoint VPN-1?  I'd love to get this sorted out.  It's really a hassle plugging in outside the firewall to receive company email, then reconnecting inside the firewall to print, etc.  I'm about one day away from just putting an second NIC in this machine, and setting up internal/external routing.  Of course, I'd rather have the "real" and elegant solution.

Dan

[Justin]

Dan - have you tested running it without using the AH?

Its not ideal but cleaner than your dual nic solution.

Justin.

[Dan G.]

Justin,

I am not sure what you mean about running the client without the AH.  Can you give me any additional guidance there?  There is no option I'm aware of for disabling it.  Not sure the company firewall would accept the connection if it's not 'spec' anyway.

FWIW, I have managed to get one client working using the ipportfwd rpm from the contrib downloads --- but that only solves part of the problem.  I do need to be able to run multiple clients behind the firewall, and port forwarding will only allow for a single connection.  Am I incorrect in thinking the instructions posted would give transparent handling of multiple connections?

Thanks a ton for your reply,

Dan

[Ritchie Logan]

> Am I incorrect in thinking the instructions posted would give transparent
> handling of multiple connections?

Yes.

I have had 2 connections running concurrently through my box. Port forwarding will work, but it is a "brute force" method.

In my client (Nortel Extranet) I need to "Disable Keepalives" to make the connection work.

Ritchie

[Dan G.]

Thanks for the clarificationi, Ritchie.  The VPN-1 SecureClient does not have many configuration options that I can see.  Only IKE encapsulation, force TCP, and FWZ.  

I did find some interesting info on www.phoneboy.com, at: http://www.phoneboy.com/faq/0141.html

There are several other options there are I can try, such as configuration changes to the some *.c files on the SecureRemote client.  Certainly nothing as simple as a user interface-accessible check box :/

Another thing that may be useful to some folks connecting to FW-1 boxes was this tidbit, taken from that same page:

    "If UDP Encapsulation Mode is used, make sure it can pass UDP Port 2746"

That's one port I had not seen any reference to previously, and may be the key to someone else's dilemma.

Regards,

Dan

[Ritchie Logan]

TYPO
====

To all those who have tried this and found it not to work - my instructions contained a typo:

> /sbin/e-smith/db configuration setprop masq ipseq yes
> /sbin/e-smith/signal-event remoteaccess-update

should be

> /sbin/e-smith/db configuration setprop masq ipsec yes
> /sbin/e-smith/signal-event remoteaccess-update

Note: IPSEC, not IPSEQ!!

Ritchie