[Openswan Users] IPsec-Setup
SilverTip257
silvertip257 at gmail.com
Mon Apr 11 19:32:51 EDT 2011
Thomas,
I can attest that the docs are not terribly out-of-date if they are
out-of-date at all.
I used the documentation I found on the web, Openswan wiki, and any
advice I got from this list to create a working setup. I used CentOS
and Debian Lenny with NETKEY (XFRM) and not KLIPS (this time around).
Something sounds wrong with your configuration if Openswan cannot find
itself/its side.
** You may not be properly reloading/removing the
configuration/connections. Look up the man page on `ipsec auto` and
you'll find everything you need to add, delete, replace, bring up, and
bring down connections. Ex: ipsec auto --replace "connection_name"
** Pretty much everything you describe I went through and fixed on my
setup. I'm telling you it has to do with the 4conns and/or advanced
routing - pick one and try it.
** Post your network layout (gateways + subnet for both ends) _AND_ a
recent config (both hosts) on a site like pastebin.com and provide a
link in your response.
The documentation does not spoon feed, but given reading and
experimentation it does provide the necessary knowledge.
---~~.~~---
Mike
// SilverTip257 //
On Mon, Apr 11, 2011 at 09:37, Thomas Schweikle <tps at vr-web.de> wrote:
> Am 08.04.2011 01:37, schrieb SilverTip257:
>> Thomas,
>>
>> I took a quick look at this and here's what I see (I'm not a
>> professional by any means!).
>
> Thanks for your reply!
>
>> First and foremost, you do not need to swap left and right sides in
>> the configs ... Openswan detects which side it is on.
>> It looks like you only have one "conn" in each config as well. Which
>> will only suffice for subnet-to-subnet traffic, not between gateways
>> or gateway to an opposite subnet.
>
> Hmmmmmmm. Without doing so, I will not have any connection at all.
> It does not look as if openswan being able to find out itself if it
> is at the left or right side.
>
>> If you want traffic between gateways and subnets (behind both
>> gateways) to be encrypted you have a few choices. I'll mention two,
>> but there may be more.
>> 1. Four Conns config - you have connections for: gw1-to-gw2,
>> gw1-to-sub2, gw2-to-sub1, sub1-to-sub2
>> 2. Advanced Routing (simplifies your config, but makes traffic
>> originate from an IP address in subnets)
>
> This means, in no case, an ipsec connection is transparent, at least
> for the gateway ipsec is running on. AFAIK this means, nearly all
> docs out there are wrong at this point, or at least do not describe
> it really correct.
>
>> I'm taking for granted that A is left and B is right (your config flip
>> flops them).
>> For advanced routing in your situation: leftsourceip=192.168.128.2 and
>> rightsourceip=192.168.1.2
>>
>> References from the wiki:
>> (towards the bottom- 4conn & advanced routing)
>> http://wiki.openswan.org/index.php/Openswan/MultipleTunnelsBetweenTheSameTwoGateways
>
> This refers to configuration options not available(?) any more. At
> least for me "rightfirewall" and "leftfirewall" gave syntax errors.
>
>> (might be helpful) http://wiki.openswan.org/index.php/Openswan/Leftsourceip
>
> This refers to an interface build by openswan. This interface does
> not exist (at least not with the newer versions of ipsec).
>
>> My advice is to read about both and determine which one is best for
>> your application. However if you only need subnets to communicate
>> advanced routing is your ticket. Gateways can still communicate via
>> the tunnel by using their subnet addresses. I could say more, but
>> I've written plenty now; and the wiki likely has all the bits I might
>> say.
>
> At the moment: none, because both do not work as described. Docs
> seem to be wrong or not up to date, or ubuntu/debian is doing
> something really harmful with these while
> compiling/packaging/installing.
>
>> Another helpful tip is to use ping with the -I parameter (capital i)
>> to specify an interface or IP address to use as the source (ex: ping
>> -I 192.168.1.2 192.168.128.2 -- this pings A from B using B's subnet
>> address, not the 172.31.x.x address).
>
> Not really, but as it was the only reply with some helpful
> information ...
>
>> Hopefully this helps.
>> Let the list know what fixes your problem. ;)
>
> At now --- all problems remain:
> - I can ping the remote gateway from the local one
> - I can't ping the local gateway from the remote one
> - I can't ping a host on the remote subnet from the local gateway
> - I can't ping a host on the local subnet from the remote gateway
> - I can't ping a host on the remote subnet from a local one
> - I can't ping a host on the local subnet from a remote one
>
> PS: firewalls are not active on any gateway or host!
>
>
>> ---~~.~~---
>> Mike
>> // SilverTip257 //
>>
>>
>>
>> On Thu, Apr 7, 2011 at 17:15, Thomas Schweikle <tps at vr-web.de> wrote:
>>> Hi!
>>>
>>> Having two systems, want to tunnel between two subnets. I have:
>>>
>>> on my server (A):
>>> Internet eth0: 172.31.99.27 gw 192.168.99.1
>>> Internal eth1: 192.168.128.2; net 192.168.128.0/24
>>>
>>> on the client (B):
>>> Internet eth0: unknown (DSL) gw 192.168.1.1 (DSL-Router is gateway)
>>> Internal eth0: 192.168.1.2; net 192.168.1.0/24
>>>
>>> on (B):
>>> conn B-A
>>> type= tunnel
>>> auth= esp
>>> authby= secret
>>> keyexchange= ike
>>> pfs= no
>>> aggrmode= yes
>>> ike= 3des-sha1-modp1024
>>> esp= 3des-sha1
>>> auto= start
>>> #
>>> # LOCAL
>>> leftid= @B
>>> left= 192.168.1.2
>>> leftsubnet= 192.168.1.0/24
>>> leftnexthop= %defaultroute (I assume 192.168.1.1)
>>> #
>>> # REMOTE
>>> rightid= @A
>>> right= 172.31.99.27
>>> rightsubnet= 192.168.128.0/24
>>> rightnexthop= %defaultroute (I assume 172.31.99.1)
>>>
>>>
>>> on (A):
>>> conn A-B
>>> type= tunnel
>>> auth= esp
>>> authby= secret
>>> keyexchange= ike
>>> pfs= no
>>> aggrmode= yes
>>> ike= 3des-sha1-modp1024
>>> esp= 3des-sha1
>>> auto= add
>>> #
>>> # LOCAL
>>> leftid= @A
>>> left= 172.31.99.27
>>> leftsubnet= 192.168.128.0/24
>>> leftnexthop= %defaultroute (I assume 172.31.99.1)
>>> #
>>> # REMOTE
>>> rightid= @B
>>> right= %any
>>> rightsubnet= 192.168.1.0/24
>>> rightnexthop= %defaultroute (I assume 192.168.1.1)
>>>
>>>
>>> Starting IPsec doesn't give any error messages (A):
>>> Apr 7 22:59:02 A kernel:
>>> [1143570.309552] NET: Registered protocol family 15
>>> Apr 7 22:59:02 A kernel:
>>> [1143570.351431] Initializing XFRM netlink socket
>>> Apr 7 22:59:02 A kernel:
>>> [1143570.359222] Intel AES-NI instructions are not detected.
>>> Apr 7 22:59:02 A pluto:
>>> adjusting ipsec.d to /etc/ipsec.d
>>>
>>> Starting IPsec on the client also (B):
>>> Apr 7 23:02:03 ns3 kernel:
>>> [5964887.221337] NET: Registered protocol family 15
>>> Apr 7 23:02:03 ns3 kernel:
>>> [5964887.251574] intel_rng: FWH not detected
>>> Apr 7 23:02:03 ns3 kernel:
>>> [5964887.328468] Initializing XFRM netlink socket
>>> Apr 7 23:02:03 ns3 kernel:
>>> [5964887.334486] padlock: VIA PadLock not detected.
>>> Apr 7 23:02:03 ns3 kernel:
>>> [5964887.339793] padlock: VIA PadLock Hash Engine not detected.
>>> Apr 7 23:02:03 ns3 kernel:
>>> [5964887.347344] padlock: VIA PadLock not detected.
>>> Apr 7 23:02:03 ns3 pluto:
>>> adjusting ipsec.d to /etc/ipsec.d
>>>
>>>
>>> For the routing tables I have
>>> (on A):
>>> 192.168.128.0 0.0.0.0 255.255.254.0 U 0 0 0 eth1
>>> 172.31.99.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
>>> 0.0.0.0 213.95.82.1 0.0.0.0 UG 100 0 0 eth0
>>>
>>> (on B):
>>> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
>>> 0.0.0.0 192.168.1.1 0.0.0.0 UG 100 0 0 eth0
>>>
>>>
>>> Now trying to ping the server (from B):
>>> root at B:~# ping 172.31.99.27
>>> PING 172.31.99.27 (172.31.99.27) 56(84) bytes of data.
>>> 64 bytes from 172.31.99.27: icmp_req=1 ttl=57 time=27.9 ms
>>> 64 bytes from 172.31.99.27: icmp_req=2 ttl=57 time=28.7 ms
>>> 64 bytes from 172.31.99.27: icmp_req=3 ttl=57 time=27.9 ms
>>> 64 bytes from 172.31.99.27: icmp_req=4 ttl=57 time=29.4 ms
>>> 64 bytes from 172.31.99.27: icmp_req=5 ttl=57 time=30.6 ms
>>> 64 bytes from 172.31.99.27: icmp_req=6 ttl=57 time=28.9 ms
>>> 64 bytes from 172.31.99.27: icmp_req=7 ttl=57 time=29.0 ms
>>> ^C
>>> --- 172.31.99.27 ping statistics ---
>>> 7 packets transmitted, 7 received, 0% packet loss, time 6009ms
>>> rtt min/avg/max/mdev = 27.921/28.960/30.639/0.871 ms
>>>
>>>
>>> Now the internal address of the server (from B):
>>> root at B:~# ping 192.168.128.2
>>> PING 192.168.128.2 (192.168.128.2) 56(84) bytes of data.
>>> 64 bytes from 192.168.128.2: icmp_req=1 ttl=64 time=29.2 ms
>>> 64 bytes from 192.168.128.2: icmp_req=2 ttl=64 time=29.1 ms
>>> 64 bytes from 192.168.128.2: icmp_req=3 ttl=64 time=32.4 ms
>>> 64 bytes from 192.168.128.2: icmp_req=4 ttl=64 time=30.9 ms
>>> 64 bytes from 192.168.128.2: icmp_req=5 ttl=64 time=28.9 ms
>>> 64 bytes from 192.168.128.2: icmp_req=6 ttl=64 time=28.9 ms
>>> ^C
>>> --- 192.168.128.2 ping statistics ---
>>> 6 packets transmitted, 6 received, 0% packet loss, time 5007ms
>>> rtt min/avg/max/mdev = 28.920/29.936/32.474/1.322 ms
>>>
>>>
>>> And last some system within the connected subnet (from B):
>>> root at B:~# ping 192.168.128.4
>>> PING 192.168.128.4 (192.168.128.4) 56(84) bytes of data.
>>>
>>>
>>> Any idea why this does not work??
>>>
>>>
>>> --
>>> Thomas
>>>
>>>
>>> _______________________________________________
>>> Users at openswan.org
>>> http://lists.openswan.org/mailman/listinfo/users
>>> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>>> Building and Integrating Virtual Private Networks with Openswan:
>>> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>>>
>>>
>
>
> --
> Thomas
>
>
More information about the Users
mailing list