[Openswan Users] IPsec-Setup
Thomas Schweikle
tps at vr-web.de
Mon Apr 11 09:37:29 EDT 2011
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 219 bytes
Desc: OpenPGP digital signature
Url : http://lists.openswan.org/pipermail/users/attachments/20110411/a66a8524/attachment-0001.bin
More information about the Users
mailing list