Anyone know how to get IPSec passthru to work on Sonicwall SOHO??
Danny Schmid
I have the Sonicwall SOHO setup using NAT. I would to be able to use a
workstation on my LAN to talk to the Timestep box at work. I am able
to connect to the Timestep box via a Timestep Permit Client, but I am
dropping connection. I set up a rule to allow the IP address of the
Timestep box to come in from the WAN to the LAN via IPSEC protocol.
Still having problems. Any suggestions??
Danny Schmid
Jeanne Webster
ESP) packet and drop it on the wire. Then SonicWall will modify the packet
by changing the IP address. In the process all of the IPSEC authentication
stuff (technical term) is altered and the Timestep gateway at work drops the
packet. Try to create a rule to allow IP protocol 50 and 51 thru without
masquerading.
Good luck,
JW
"Danny Schmid" <danny....@home.com> wrote in message
news:b3npmsoent31101ci...@4ax.com...
NoneSuch
this function. Some don't. The SonicWall supports it, but unfortunately
it is broken in many releases (the SonicWall drops fragmented packets).
Some people have reported success, there was a note recently which indicated
that the next release will fix it.
Additionally, IP 51 is used for Authentication Header, which is not often
used by TimeStep as it doesn't involve encrypting the payload (ie: not
very useful) so you can probably ignore it.
None
Danny Schmid
Yes I know its possible because I have tested a Linksys DSL\Cable
Router with firmware 1.30 and it works perfectly. Hopefully the next
release of the Sonicwall fireware with support IPSec Passthru.
Danny Schmid
Eric
>You can't use NAT with IPSEC. Your timestep client will prepare the AH (or
>ESP) packet and drop it on the wire. Then SonicWall will modify the packet
>by changing the IP address. In the process all of the IPSEC authentication
>stuff (technical term) is altered and the Timestep gateway at work drops the
>packet. Try to create a rule to allow IP protocol 50 and 51 thru without
>masquerading.
>
>Good luck,
>JW
Well, if he bypasses "masquerading", he better be using a real,
routable IP address, that was allocated to his internet feed, on that
client. Otherwise, the packet may get to the other site, but nothing
will come back. I suggest you need a firewall that supports IPSEC.
- Eric
Danny Schmid
I had a call open with Sonicwall. The said that the Sonicwall
suppports IPSEC ESP automaticly, without any rules but does not
support IPSEC AH.
Jeanne Webster
packet is encrypted at the workstation and the firewall NATs the address be
replacing the private IP address with the firewall's public IP address the
security association won't work. I have tried NATing IPSEC traffic from a
Nortel Contivity 4500 and Checkpoint SecureRemote running on FW-1. In both
cases the VPN rejected the NAT'd packets. You need to make sure that your
IPSEC and NAT implementations conform to RFC2709 and perform IPSEC tunneling
with the NAT device acting as an end-point. I have not used TimeStep but if
they have solved the IPSEC-NAT issue I will give them a call. Thanks for
the information.
JW
J Webster
quite right. ESP should permit the IP source address to be replaced without
any problem. It is only the AH protocol that hashes the IP header and
causes NAT problems. And as None said in his earlier post not many folks
are using AH.
Thnx for setting me straight,
JW
"Jeanne Webster" <jweb...@cox.rr.com> wrote in message
news:KNvb5.1138$mp.4...@typhoon.southeast.rr.com...
rick_...@my-deja.com
The SonicWALL does indeed support IPSec (ESP) pass through (and has for
the last several releases). I use it every day behind a SOHO with 1:N
NAT without any problems.
I did, however, add two rules as a safety:
1 - a predefined rule for IPSec (ESP)
2 - a predefined rule for Key Exchange (IKE)
I put the IP address of my PC with the IPSec client in the Public LAN
Server field (on the Access | Services tab) for both of them.
The reason I added the rules was that in the case where the VPN
concentrator (far end) initiated a new IKE key negotiation there is a
possibility that the firewall (not only with a SonicWALL) MIGHT have
timed-out IKE in it's state table. The firewall would then not know
where to send the IKE message and the VPN could hang. It is only a
precaution, but it works very reliably for me.
Rick Reddy
SonicWALL
In article <cbqsmsc2cl5dglbo5...@4ax.com>,
Sent via Deja.com http://www.deja.com/
Before you buy.
Danny Schmid
Thanks Rick, I just added both rules, IPSec (ESP) and Key Exchange
(IKE), added the IP address of my workstation running the Permit
Client to the Server field for both IPSec and Key Exchange, restarted
the Sonicwall.
Still same problem. There has to be something different with the
Sonicwall implementation of IPSec Passthru verus the LinkSys EtherFast
Cable/DSL Router implementation because it works perfect with the
LinkSys.
Thanks for the suggestions
Danny Schmid
wail...@my-deja.com
ethernet card. This will help with IPSec passthru SonicWall due to a
bug in many firmware versions.
Which utility for Win95, 98 or NT? Look for either EasyMTU or TweakDUN,
a better choice despite the name which refers to PPP tuning. Both
readily findable at shareware sites:
http://google.yahoo.com/bin/query?p=easymtu+tweakdun&hc=0&hs=0
In article <slrn8mrekd...@alrescha.com>,
id...@like.spam (NoneSuch) wrote:
> This is simply wrong. You can use NAT with IPSec. Many firewalls support
> this function. Some don't. The SonicWall supports it, but unfortunately
> it is broken in many releases (the SonicWall drops fragmented packets).
> Some people have reported success, there was a note recently which indicated
> that the next release will fix it.
>
> Additionally, IP 51 is used for Authentication Header, which is not often
> used by TimeStep as it doesn't involve encrypting the payload (ie: not
> very useful) so you can probably ignore it.
>
> None
>
> On Thu, 13 Jul 2000 01:44:25 GMT, Jeanne Webster wrote:
> >You can't use NAT with IPSEC. Your timestep client will prepare the AH (or
> >ESP) packet and drop it on the wire. Then SonicWall will modify the packet
> >by changing the IP address. In the process all of the IPSEC authentication
> >stuff (technical term) is altered and the Timestep gateway at work drops the
> >packet. Try to create a rule to allow IP protocol 50 and 51 thru without
> >masquerading.
> >
> >Good luck,
> >JW
> >
> >"Danny Schmid" <danny....@home.com> wrote in message
> >news:b3npmsoent31101ci...@4ax.com...
> >> Anyone know how to get IPSEC passthru to work on Sonicwall SOHO??
> >>
> >> I have the Sonicwall SOHO setup using NAT. I would to be able to use a
> >> workstation on my LAN to talk to the Timestep box at work. I am able
> >> to connect to the Timestep box via a Timestep Permit Client, but I am
> >> dropping connection. I set up a rule to allow the IP address of the
> >> Timestep box to come in from the WAN to the LAN via IPSEC protocol.
> >> Still having problems. Any suggestions??
> >>
> >> Danny Schmid
> >>
> >
> >
>
nobody youknow
I'm having little (make that zero) luck connecting Checkpoint VPN-1
SecureClient (ver. 4.1) through my SonicWall. Your note suggests that
there is essentially no need to do anything special, but that you do
recommend adding the two rules. I've added them. It still doesn't
work.
Here's the setup: I have a single public IP address and use DHCP and
NAT to assign private addresses to the machines on the LAN. The
SecureClient system is a laptop which is only plugged into the LAN
when needed. DHCP is set to always give the same private address to
that laptop.
I have default rules blocking everything LAN-to-WAN and WAN-to-LAN
and several rules making exceptions to those for specific protocols
and/or specific WAN and/or LAN IP addresses. I've never had any
problems. I added the two rules you suggest. Attempting to connect
and then reading the firewall logs showed the the laptop attempting to
a NetBios (port 137) connection to a remote system (probably for WINS
resolution). I added a rule allowing that connection. The next
attempt at connection gave a firewall log entry indicating an attempt
by the laptop port 259 to connect to port 259 of the remote firewall
server. I added a rule allowing that connection.
The next attempt at connecting gave a firewall log entry indicating an
attempt by the remote firewall server to connect to my public IP
address. Both the source and destination IP addresses had blanks
where I expect to see the port numbers. The SOHO dropped the
connection with a "unknown protocol dropped" message.
That's as far as I've been able to get. Suggestions?
On Fri, 14 Jul 2000 17:44:08 GMT, rick_...@my-deja.com wrote:
>Just to clarify:
>
>The SonicWALL does indeed support IPSec (ESP) pass through (and has for
>the last several releases). I use it every day behind a SOHO with 1:N
>NAT without any problems.
>
>I did, however, add two rules as a safety:
>1 - a predefined rule for IPSec (ESP)
>2 - a predefined rule for Key Exchange (IKE)
>
>I put the IP address of my PC with the IPSec client in the Public LAN
>Server field (on the Access | Services tab) for both of them.
>
>The reason I added the rules was that in the case where the VPN
>concentrator (far end) initiated a new IKE key negotiation there is a
>possibility that the firewall (not only with a SonicWALL) MIGHT have
>timed-out IKE in it's state table. The firewall would then not know
>where to send the IKE message and the VPN could hang. It is only a
>precaution, but it works very reliably for me.
>
>Rick Reddy
>SonicWALL
>
>
>
>
>
>In article <cbqsmsc2cl5dglbo5...@4ax.com>,
> Danny Schmid <danny....@home.com> wrote:
>> On Thu, 13 Jul 2000 15:48:17 -0400, Eric
>> <eje...@jensenXresearchX.com> wrote:
>>
>> >On Thu, 13 Jul 2000 01:44:25 GMT, "Jeanne Webster"
>> ><jweb...@cox.rr.com> wrote for the entire planet to see:
>> >
>> >>You can't use NAT with IPSEC. Your timestep client will prepare the
>AH (or
>> >>ESP) packet and drop it on the wire. Then SonicWall will modify the
>packet
>> >>by changing the IP address. In the process all of the IPSEC
>authentication
>> >>stuff (technical term) is altered and the Timestep gateway at work
>drops the
>> >>packet. Try to create a rule to allow IP protocol 50 and 51 thru
>without
>> >>masquerading.
>> >>
>> >>Good luck,
>> >>JW
>> >
>> >Well, if he bypasses "masquerading", he better be using a real,
>> >routable IP address, that was allocated to his internet feed, on that
>> >client. Otherwise, the packet may get to the other site, but nothing
>> >will come back. I suggest you need a firewall that supports IPSEC.
>> >
>> >- Eric
>> >
>> I had a call open with Sonicwall. The said that the Sonicwall
>> suppports IPSEC ESP automaticly, without any rules but does not
>> support IPSEC AH.
>>
>
>