Hi there,
I don''t think there is any reliable way to test the state of your VPN
by
testing between the tunnel end points. This is, when you are using
Freeswan to build IPSEC tunnels.
Using ip route you can make sure Netfilter will not drop any packets
directed from tunnel end point A to the external interface of tunnel end
point B. Just, this won''t test if the tunnel exists. This will just
make
sure there is a valid connection between the WAN interfaces. This works
just fine because this is a valid route.
The WAN interface is not part of the encryption domain. Packets are only
encrypted when they originate from an IP being part of the address range
of your LAN''s. Both LAN (loc) interfaces of the participating firewalls
are. So why doesn''t it work ?
First of all I am also maintaining a bunch of Checkpoint 4.1 and NG VPN
appliances/servers/connections. They will allow you to ping the remote
inside interface. As this works and they normally (90%) are based on
Linux too, this can''t be a TCP/IP stack or a general IPSEC problem.
Just, Checkpoint allows me to define the firewall itself as being part
of the tunnel.
What is different between a Checkpoint and a freeswan IPSEC
implementation seems to be the IPSEC device. Checkpoint will not use it.
>From what I see it seems to me the IPSEC device assumes the identity of
the LAN or the WAN interface as needed. Sending an icmp request from the
LAN Interface might make the IPSEC sending it as originating from the
WAN interface. The WAN is not part of the encryption so the packet is
discarded. Sending a ping from a host on LAN A to the firewalls
interface in LAN B normally works as it does not originated from an
interface controlled by the IPSEC interface.
What ever, there is a reason freeswan never made it into the kernel.
While it was the only working IPSEC implementation available for Linux
for some time it always was a sophisticated hack. I am definitely
looking forward to kernel 2.6.
Reliable tests for tunnels must originate from a host in LAN A to a host
in LAN B and they should not use ICMP. You can as easily write scripts
testing the existence of a script checking of an open port like 21, 80
etc.
Regards,
Axel
-----Original Message-----
From: Dave B [mailto:dragin33@hotmail.com]
Sent: Freitag, 22. August 2003 22:07
To: l0f33t@yahoo.com
Cc: shorewall-users@lists.shorewall.net
Thanks for your timely responce. i will continue to test my
configuration
to more accurately find what the problem is. One thing i can tell you
is
that it does normally go down when left alone for a while. So your
explanation of tcp traffic going trough the tunnel sounds like it could
be
the answer. One of the obstacles i''m facing is setting up my servers
so
that they can ping themselves over the link. The way i understand it is
that any host can ping any host over the VPN but the servers themselves
kinda play monkey in the middle and they one can''t ping the
other''s IP
over
the link. To more accuratly describe the problem i believe when the
recieving computer gets the ICMP request it pushes it''s response out
the
default interface, eth0 (or the internet side.) This won''t work
because
of
RFC1918 and so many other reasons. I''ve seen somebody talking about an
ip
route that i can add to make this work but i couldn''t get his
particular
command to work on my server - got errors. Could anyone explain how i
might
acomplish this with ip route? Here''s my setup in case you need to
know.
192.168.7.0/24 | (192.168.7.3/192.168.2.3) | 192.168.2.1 | INTERNET |
192.168.10.1 | (192.168.10.3/192.168.1.3) | 192.168.1.0/24
Thanks again!
>From: Joshua Banks <l0f33t@yahoo.com>
>To: Dave B <dragin33@hotmail.com>
>Subject: Re: [Shorewall-users] Keep Alive
>Date: Fri, 22 Aug 2003 04:12:17 -0700 (PDT)
>
>
>Ok, now I can tell where your at, unix/linux knowledge wise that is.
>
>Which is good.
>
>
>Sorry for the long winded response earlier. I just didn''t know
where
you >were at with the basics
>of vpn..
>
>Your asking how to test to see if a vpn is up and functioning? Then
what to >do to re-establish the
> tunnel or rekey the connection to bring the tunnel back up.
>
>Again this can be a simple solution or a complicated one depending on
what >the actual PROBLEM is
>if there is one..
>
>First,
>I would take the simple approach for this. Assuming that behind each
>gateway your using private
>RFC1918 addressing you should be able to simply create a script that
will >ping from one private
>lan to the other at an internval that you deem adequate. We know that
if >your using rfc1918
>addressing behind both gateways that the only way that traffic sent
from >private address, to a
>private address is through a vpn tunnel.
>
>SEE....if the tunnel goes down while Site A [Host pc1] with ip
>192.168.253.20 is trying to get to
>Site B [Server pc5] with ip of 10.0.0.2...through the vpn tunnel...it
will >obviously fail if the
>tunnel goes down because we know that internet routers and most
firewalls >(if configed correctly)
>will not pass RFC1918 addresses through themselves. I''m sure you
already >know this.
>
>Now comes the second part. What to do if your ping script fails to
reach >the other side...Ok..
>
>Well, "why did it actually fail to reach the other side."? Lots of
>possibilities here for failure
>and this is where things can get complicated.
>
>And this is where you would need to know why its failing or some of the
>most common reasons for a
>tunnel to fail to be able to design a script to detect not only the
actual >tunnel collapsing but
>how to try and bring it back up when its detected as down. Script
>creativity which really isn''t my
>
>area of expertise is what your going to need.
>
>
>
>To make a simple first step solution to what in some cases may be a
>complicated problem is to
>create a Ping script that pings from inside Site A private lan to the
>inside private address of
>the nic on the peer gateway/fireall like 1 time every 15 or 30
seconds. We >know that this device
>(peer gateway) should always be up. If its not then your tunnel
won''t
be up >either. Usually. (If)
>for after a minute or so your pings are timing out (then) ping from
inside >Site A private lan to
>External nic on peer gateway/firewall. At this point this ping should
be >routed around the tunnel
>over the internet in the clear assuming that Site B''s external nic
has
a >public ip address.
>
>(If) you get replies (then) try and rekey the tunnel to bring it back
up.>
>Sorry to be so long winded, but there''s really no sure fire
solution
>considering the number of
>things that can bring a tunnel down. But what I''ve laid out above
is a
>simple start.
>
>The thing is, is that YOU need to be familiar with what has caused YOUR
>tunnel to go down in the
>past to create a script to deal with future collapses.
>
>The software developer or Free/SWAN vpn dev. team are the best people
to >pose your question to I
>guess. And I only say this because each flavor of vpn code created out
in >the world will have
>thier own pluses and minuses. Althoug they are trying to get everyone
to >keep to an ipsec standard
>operating procedure so to say. So going to the Free/SWAN dev team
source >which are intimately
>familiar with what bugs are in thier vpn package and under what kind of
>conditions, (normal and
>abnormal), that causes vpn tunnels to collapse is your best bet..
>
>Simple things that I''ve seen that bring down a tunnel... depending
on
the >dev package..allot of
>times if a tunnle sits idle for too long the tunnel will either rekey
or go >down.. Sending any
>type of Tcp type traffic, (packets that receive acknowledgements),
through >the tunnel will keep
>the tunnel up.
>Sometimes I"ve seen that if there is to much UDP type traffic without
any >tcp traffic, that one
>side will think the other isn''t responding because UDP is
connectionless >based and doesn''t create
>a circut like tcp does and collapses the tunnel if nothing is coming
back >in the other direction.
>Thats supposedly called IPSEC logic,,,,but we all know that this is
>actually IPSEC illogic...Some
>vendors do this though.... I wish I was more intimate with Free/SWAN to
>give you better ideas.
>
>I hope this helped in some way Dave. Good luck..
>
>JBanks
>
>
>
>__________________________________
>Do you Yahoo!?
>The New Yahoo! Search - Faster. Easier. Bingo.
>http://search.yahoo.com
_________________________________________________________________
Help protect your PC: Get a free online virus scan at McAfee.com.
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
_______________________________________________
Shorewall-users mailing list
Post: Shorewall-users@lists.shorewall.net
Subscribe/Unsubscribe:
http://lists.shorewall.net/mailman/listinfo/shorewall-users
Support: http://www.shorewall.net/support.htm
FAQ: http://www.shorewall.net/FAQ.htm