VPN key exchange getting no response when using masq
a
checkpoint securemote VPN thru linux masq fine too. I now need to use
Nortel's Contivity "Extranet Access Client" instead of checkpoint
securemote. I can use this new client fine if I connect a windows PC
directly to the internet, but I cannot even get any key exchange response at
all from the VPN server when I try to run behind the linux masq box. That
is, the private PC sends out UDP port 500 key exchange requests to the VPN
server as:
UDP: privateIP:500--> vpnserver:500
which get masq'd to:
UDP:publicIP:unprivport-->vpnserver:500
and nothing ever comes back from the VPN server I'd expect either:
UDP:vpnserver:500-->publicIP:unprivport
or
UDP:vpnserver:500-->publicIP:500
but neither comes back.
I can ping the VPN server thru the masq box fine. I have a firewall rule to
let thru and log anything going to, or coming from, the VPN server, but
nothing comes back, honest.
ANY ideas anyone? I know the VPN is configured to use ESP (protocol 50),
and I intend to have all sorts of trouble getting THAT to masq (I guess I
need ip_masq_ipsec.o, no?), but my client isn't even sending out proto50
yet, it is stuck waiting for the key exchange (which I assume will just be
UDP port 500.) Is it possible that there is some sort of checksum in the
UDP 500 packet that, due to masq changing the source IP and port, is causing
the vpnserver to discard the packets as bogus? This didn't happen with the
checkpoint client, is this possible?
HELP HELP HELPHELP thanks!
a
Well, after reading thru Jhardin's ip_masq_ipsec.c source, I see that
installing this module should fix the UDP port 500 masq problem. I compiled
that module and installed it, and like _magic_, the key exchange now seems
to work. YEY!
Now, I see the ESP packets coming from my private PC into the input
firewall, I see the ESP packets being forward/masq'd to the output firewall,
but I see no log of the ESP packet going out the output firewall! And, I
get no ESP packets coming back from the VPN server. This IS the same exact
problem I had two years ago, which I asked about, and I never got it to
work. Unfortunately, my old VPN client could do UDP-encap, so I could avoid
the problem, but now I cannot with my new client (Nortel.)
I am still using RH 7.0 with the stock kernel that comes with it, 2.2.16-22,
not recompiled. All I did was run menuconfig to enable ipsec, and then
compiled the ip_masq_ipsec module and installed it.
Is there something in the kernel that could be causing the problem I am
seeing (dropping the ESP packets on the way out)???? Please, any ideas
would be hugely appriciated! Is it possible that even though I am using
ip_masq_ipsec as a module, and part of that at least seems to be working
(the key exchange stuff), that somehow there is support in the kernel itself
that needs to be turned on specifically for ipsec packets?
thank you for your time!
"a" <asanfo...@hotmail.com> wrote in message
news:iw%x8.45219$3C4.6...@news1.east.cox.net...
a
COMPLETELY following the instructions for patching on
http://www.impsec.org/linux/masquerade/ip_masq_vpn.html
(I missed the RH7.0 patch described below - as soon as I rebuilt
ip_masq_ipsec and loaded it, everything worked like a charm, the esp packets
now go out and come back!!!! Even though RH7.0 (2.2.16-22) has the vpn
patch, it STILL needs this patch or ESP packets will not get out! This
patch also fixes pptp for the same thing, I suppose, but I didn't test that)
damn. RTFM
--------------------------------------------------------------------
The following patch is needed for the RedHat or Mandrake 2.2.16 kernel, or a
kernel which has had the VS-Masq (Virtual Server) patch applied. This
includes the kernel shipped with RedHat 7.0 - if you have RedHat 7.0 and you
are using the kernel that came with it, you do need this patch. The RedHat
2.2.17-14 update kernel includes this patch, I recommend you get that kernel
RPM from the FTP site rather than patching and rebuilding.
If verbose PPTP debugging shows a masquerade address (maddr) of 0.0.0.0 is
being used, or tcpdump on your Internet interface shows something like:
08:32:26 0.0.0.0 > 1.2.3.4: ip-proto-50 108 (ttl 63, id 1)
...then you need to apply this patch. To apply this patch:
cd /usr/src/linux/net/ipv4
zcat patchfile.gz | patch -l -p0
2.2.16: [ HTTP Mirror 1 (USA: WA)
"a" <asanfo...@hotmail.com> wrote in message
news:UCby8.52368$3C4.7...@news1.east.cox.net...