[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