[Openswan Users] Tunnel up but cannot ping the other side.
Peter McGill
petermcgill at goco.net
Mon Sep 22 08:53:50 EDT 2008
Jesper,
This only happens with NETKEY IPSec stack because it uses the public
interface for tunneled packets. KLIPS uses ipsecX for tunneled packets
so it isn't affected by a MASQUERADE rule qualified by interface.
NETKEY is the default stack on Linux 2.6.x kernels, but on older 2.4.x
kernels it isn't and people usually installed KLIPS from the Openswan
package.
Peter
Jesper Langkjær wrote:
> Hi Peter
>
> Funny but is was the MASQUERADE rule in the firewall that was the problem.
> In the past this rule have never made any problem.
>
> But anyway i put the "iptables -t nat -A POSTROUTING -o eth0 -d 192.168.37.34 -j RETURN" in just before the "iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE" and every thing works.
>
> Thanke you for the help
>
> Kind regards
>
> Jesper Langkjær
>
> -----Original Message-----
> From: Peter McGill [mailto:petermcgill at goco.net]
> Sent: Friday, September 19, 2008 4:13 PM
> To: Jesper Langkjær
> Subject: Re: [Openswan Users] Tunnel up but cannot ping the other side.
>
>
> Jesper,
>
> #1 Disable developer debugging, it is not usually helpful, but only adds
> excessive logs. Makes reading the logs for real debug info like looking
> for a needle in a haystack. Only turn it on, if asked by a developer to
> sort out your problem.
> ipsec.conf:
> config setup
> #klipsdebug=none
> #plutodebug=none
>
> #2 Comment out or delete your conn %default section, it's not needed in
> this case and in fact is unpredictable in behavior since it is
> incorrectly indented.
>
> #3 The leftsourceip= line you added needs to be indented with a single
> tab, like all indented lines in ipsec.conf. Indenting with multiple
> spaces can have unpredictable results.
>
> #4 Your firewall is very complicated, so I'm not entirely sure but it
> looks mostly ok, except for:
> Chain POSTROUTING (policy ACCEPT 674K packets, 40M bytes)
> pkts bytes target prot opt in out source
> destination
> 10021 595K MASQUERADE all -- * eth0 0.0.0.0/0
> 0.0.0.0/0
> Which means you have a line in your script something like this:
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> This will nat all traffic outbound to the internet (including in the
> ipsec tunnel) to come from your external internet ip. This will cause
> your pings and other communication over the tunnel to fail.
> You need to add the following before it.
> iptables -t nat -A POSTROUTING -o eth0 -d 192.168.37.34 -j RETURN
> This will prevent packets for the remote lan ip from being natted, thus
> allowing the communication to work.
>
> #5 I cannot tell if the tunnel is connected or not, because barf could
> not find your logs. Did you or the system rotate them before the barf?
> They are likely in /var/log/secure*.
>
> Restart pluto and iptables with the suggested changes. Then if your
> still having trouble, create a new barf, hopefully it will contain the
> logs. Also send me the ping output.
>
>
> Peter
>
> Jesper Langkjær wrote:
>> Hi Peter
>>
>> Thanks for the quick respons.
>>
>>
>> I've try to add teh leftsourceip=10.27.1.28 aka the machine with openswan
>>
>> I'm trying to ping 192.168.37.34 but it goes via our 83.xx.xxx.xx and not the tunnel.
>>
>> I've attache the ipsec_barf.txt as requsted.
>>
>> Could it be the route in ther other end that is missing ?
>>
>> /Jesper
>>
>> -----Original Message-----
>> From: users-bounces at openswan.org [mailto:users-bounces at openswan.org]On
>> Behalf Of Peter McGill
>> Sent: Thursday, September 18, 2008 3:08 PM
>> To: Jesper Langkjær
>> Cc: users at openswan.org
>> Subject: Re: [Openswan Users] Tunnel up but cannot ping the other side.
>>
>>
>> Jesper,
>>
>> First question, where are you pinging from a host in
>> 10.27.1.0/24 or from the Fedora itself 83.xx.xxx.xx?
>> It must come from 10.27.1.0/24 or else you must add
>> leftsourceip=10.27.1.x (Fedora internal lan ip).
>> The reverse is also true, if the remote admin pings
>> 83.xx.xxx.xx this does not test the tunnel, he/she
>> must ping a live host in 10.27.1.0/24.
>>
>> Second, where are you pinging too, 192.168.37.34 or
>> 217.yyy.yy.yy? You cannot ping 217.yyy.yy.yy because
>> it is not in the subnets of the tunnel, but must ping
>> 192.168.37.34 to test the tunnel.
>>
>> Check your logs that your tunnel really is up and staying
>> up (not disconnecting.)
>> Look for pluto Quick Mode IPSec SA established.
>>
>> Check your firewall isn't masquerading or blocking the tunnel
>> traffic. The remote admin should do the same.
>>
>> If you need help checking things out, then send an
>> ipsec barf > ipsec_barf.txt as an attachment.
>>
>> Peter
>>
>> Jesper Langkjær wrote:
>>> Hi.
>>>
>>> I have problem with pinging the other side of a tunnel.
>>>
>>> My page:
>>> Fedora 4
>>> Core 2.6.16.24
>>> openswan-2.4.4-1.0.FC4.1
>>>
>>> The other side:
>>> Hardware box, unknown
>>>
>>> IPSEC.CONF
>>> config setup
>>> # Debug-logging controls: "none" for (almost) none, "all" for lots.
>>> # klipsdebug=none
>>> # klipsdebug=all
>>> # plutodebug="control parsing"
>>> # nat_traversal=yes
>>> nat_traversal=no
>>> interfaces="ipsec0=eth0"
>>>
>>> conn %default
>>> authby=rsasig
>>> leftrsasigkey=
>>> rightrsasigkey =
>>> left=%defaultroute
>>> keyingtries=1
>>> #keylife=1200s
>>> #ikelifetime=1200s
>>>
>>> #conn server_VPN
>>> # left=83.xx.xxx.xx
>>> # leftid=83.xx.xxx.xx
>>> # right=194.yyy.yyy.yy
>>> # rightsubnet=192.168.37.34/32
>>> # keyexchange=ike
>>> # keylife=2h
>>> # authby=secret
>>> # auto=start
>>>
>>>
>>> conn server_VPN
>>> left=83.xx.xxx.xx
>>> leftid=83.xx.xxx.xx
>>> leftsubnet=10.27.1.0/24
>>> right=217.yyy.yy.yy
>>> rightsubnet=192.168.37.34/32
>>> pfs=no
>>> ike=3des-sha1
>>> esp=3des-sha1
>>> keyexchange=ike
>>> keylife=2h
>>> authby=secret
>>> auto=start
>>> auth=esp
>>>
>>> The first CONN ar an old one that has been working, but now they installed som new hardware/moved server and now it dosent work anymore.
>>> When i run "service ipsec start" everything looks ok and the tunnel comes up.
>>> The other side (217.yyy.yyy.yyy) can ping my side (83.xxx.xxx.xxx) but i can't ping them.
>>>
>>> Any advise ??
>>>
>>> Kind regards
>>>
>>> Jesper Langkjaer
>>> *************************************************************************
>>> Denne e-mail er scannet for virus og spam
>>> *************************************************************************
>>> _______________________________________________
>>> Users at openswan.org
>>> http://lists.openswan.org/mailman/listinfo/users
>>> Building and Integrating Virtual Private Networks with Openswan:
>>> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>>>
>> _______________________________________________
>> Users at openswan.org
>> http://lists.openswan.org/mailman/listinfo/users
>> Building and Integrating Virtual Private Networks with Openswan:
>> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>>
>>
>> *************************************************************************
>> Denne e-mail er scannet for virus og spam
>> *************************************************************************
>>
>
> *************************************************************************
> Denne e-mail er scannet for virus og spam
> *************************************************************************
>
More information about the Users
mailing list