[Openswan Users] [NEWSENDER - ] - Re: IPsec configuration
Ana
kentdavies at gmail.com
Sat Nov 16 12:50:54 UTC 2013
Forgot to send my reply to Pascal.
Kent
On Sat, Nov 16, 2013 at 12:37 PM, Ana <kentdavies at gmail.com> wrote:
> Hello Pascal.
>
> Thanks.
>
> From machine A I test like this:
>
> [root at mainmachine etc]# ping -I 10.1.1.254 10.1.2.254
> PING 10.1.2.254 (10.1.2.254) from 10.1.1.254 : 56(84) bytes of data.
> ^C
> --- 10.1.2.254 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 3424ms
> [root at mainmachine etc]# ping -I 10.1.1.254 10.1.2.2
> PING 10.1.2.2 (10.1.2.2) from 10.1.1.254 : 56(84) bytes of data.
> ^C
> --- 10.1.2.2 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 3727ms
> [root at mainmachine etc]#
>
>
> Listening on *eth6* of machine B with Wireshark I got this:
> [image: Inline image 1]
>
> So now I believe it's encrypted but host is unreachable.
>
> On machine A, If I do this instead:
>
> [root at mainmachine etc]# ping -I 192.168.1.1 10.1.2.254
> PING 10.1.2.254 (10.1.2.254) from 192.168.1.1 : 56(84) bytes of data.
> 64 bytes from 10.1.2.254: icmp_seq=1 ttl=64 time=0.411 ms
> 64 bytes from 10.1.2.254: icmp_seq=2 ttl=64 time=1.22 ms
> 64 bytes from 10.1.2.254: icmp_seq=3 ttl=64 time=0.442 ms
> ^C
> --- 10.1.2.254 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 3000ms
> rtt min/avg/max/mdev = 0.411/0.691/1.222/0.376 ms
> [root at mainmachine etc]# ping -I 192.168.1.1 10.1.2.2
> PING 10.1.2.2 (10.1.2.2) from 192.168.1.1 : 56(84) bytes of data.
> ^C
> --- 10.1.2.2 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 3351ms
> [root at mainmachine etc]#
>
>
> Listening on *eth6* of machine B with Wireshark I got this:
> [image: Inline image 2]
>
> Host now is reachable but conn is not encrypted.
>
> I believe I have some kind of routing problem.
>
> My routing table on Machine A is this:
>
> [root at mainmachine etc]# route -n
>
> Kernel IP routing table
>
> Destination Gateway Genmask Flags Metric Ref Use
> Iface
>
> 192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0
> eth2
>
> 10.1.1.0 0.0.0.0 255.255.255.0 U 1 0 0
> eth1
>
> 10.1.2.0 192.168.1.2 255.255.255.0 UG 0 0 0
> eth2
>
> 0.0.0.0 10.1.1.254 0.0.0.0 UG 0 0 0
> eth1
>
> And on Machine B is this:
>
> [root at mainmachine etc]# route -n
>
> Kernel IP routing table
>
> Destination Gateway Genmask Flags Metric Ref Use
> Iface
>
> 192.168.1.0 0.0.0.0 255.255.255.0 U 1 0 0
> eth6
>
> 10.1.1.0 192.168.1.1 255.255.255.0 UG 0 0 0
> eth6
>
> 10.1.2.0 0.0.0.0 255.255.255.0 U 1 0 0
> eth5
>
> 0.0.0.0 10.1.2.254 0.0.0.0 UG 0 0 0
> eth5
>
>
> Aren't those routing tables correct?
>
> Thanks,
>
> Kent Davies
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Nov 16, 2013 at 12:12 PM, Pascal Fuks <Pascal at financial-art.be>wrote:
>
>> Hello Ana,
>> You should take care when pinging to make packets come from your "lan" IP.
>> So
>> From A:
>> ping -I 10.1.1.254 10.1.2.254
>> This should work.
>>
>> This is because the IP stack always choose the interface that is the
>> nearest to the destination as normal source for the packet, thus choosing
>> your "public" IP as source. When using -I in ping, you force the source to
>> be in the LeftSubnet...
>> Regards
>> Pascal Fuks
>> Network & Security Architect,
>> CEO / Administrateur délégué,
>>
>> Tel. : +32 2 387 08 00
>> Fax : +32 2 387 07 06
>> Email : pascal at financial-art.be
>> IM: pascal at financial-art (MSN)
>> Free/Busy Time : *http://www.financialart.be/pfukscal.html
>> <http://www.financialart.be/pfukscal.html>*
>>
>> On 16 Nov 2013, at 12:37, Bart Smink <bartsmink at gmail.com> wrote:
>>
>> Hi Kent,
>>
>> Nice images, way better than the usual textart. I think that you need to
>> change virtual private to virtual_private=%v4:
>> 0.0.0.0/0,%v6:fd00::/8,%v6:fe80::/10,%v4:!10.1.1.0/24 on left and
>> virtual_private=%v4:0.0.0.0/0,%v6:fd00::/8,%v6:fe80::/10,%v4:!10.1.2.0/24on right. In ipsec.conf it is normal to have left as the local computer. So
>> the ipsec.conf on computer B would be left = 192.168.2.1 leftsubnet =
>> 10.1.2.0/24 right = 192.168.1.1 rightsubnet = 10.1.1.0/24 . And I dont
>> use leftnexthop and rightnexthop in my config, and I dont think you need
>> it, it is the next hop to the ISP, so in the direction of the WAN network.
>>
>> Greetings,
>>
>> Bart
>>
>>
>>
>> 2013/11/16 Ana <kentdavies at gmail.com>
>>
>>> Hi everybody.
>>>
>>>
>>> I’m starting to learn *IPsec* and I'm having some problems.
>>>
>>>
>>> I’m running two virtual machines with CentOS that simulates the
>>> network depicted in the bellow picture.
>>>
>>> <image.png>
>>>
>>>
>>>
>>> I want to create an IPsec tunnel between machine A and machine B. The
>>> keys should be negotiated using IKE and the tunnel should enable total
>>> connectivity between the two machines.
>>>
>>>
>>>
>>> My *ipsec.conf* file on both machines is this:
>>>
>>>
>>> config setup
>>>
>>> protostack=netkey
>>>
>>> dumpdir=/var/run/pluto/
>>>
>>> nat_traversal=yes
>>>
>>> virtual_private=%v4:10.1.1.0/24,%v4:10.1.2.0/24
>>>
>>> conn gw-to-gw
>>>
>>> authby=secret
>>>
>>> left=192.168.1.1
>>>
>>> leftsubnet=10.1.1.0/24
>>>
>>> leftnexthop=192.168.1.2
>>>
>>> right=192.168.1.2
>>>
>>> rightsubnet=10.1.2.0/24
>>>
>>> rightnexthop=192.168.1.1
>>>
>>> auto=start
>>>
>>> type=tunnel
>>>
>>>
>>> And *ipsec.secrets* on both machines is this:
>>>
>>>
>>> 192.168.1.1 192.168.1.2 : PSK "test"
>>>
>>>
>>>
>>> I then do* service ipsec start* on machine A followed by the same
>>> command on machine B. Then, again on machine A, I do *ipsec auto –up
>>> gw-to-gw* followed by the exact same command on machine B.
>>>
>>> Machine A output:
>>>
>>> [root at mainmachine etc]# service ipsec start
>>>
>>> ipsec_setup: Starting Openswan IPsec U2.6.32/K2.6.32-358.23.2.el6.i686...
>>>
>>> ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in
>>> /proc/sys/crypto/fips_enabled
>>>
>>> [root at mainmachine etc]# ipsec auto --up gw-to-gw
>>>
>>> 117 "gw-to-gw" #5: STATE_QUICK_I1: initiate
>>>
>>> 004 "gw-to-gw" #5: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
>>> mode {ESP=>0xc17e5cb7 <0xefd31319 xfrm=AES_128-HMAC_SHA1 NATOA=none
>>> NATD=none DPD=none}
>>>
>>> [root at mainmachine etc]#
>>>
>>>
>>> Machine B output:
>>>
>>> [root at mainmachine etc]# service ipsec start
>>>
>>> ipsec_setup: Starting Openswan IPsec U2.6.32/K2.6.32-358.23.2.el6.i686...
>>>
>>> ipsec_setup: /usr/libexec/ipsec/addconn Non-fips mode set in
>>> /proc/sys/crypto/fips_enabled
>>>
>>> [root at mainmachine etc]# ipsec auto --up gw-to-gw
>>>
>>> 117 "gw-to-gw" #6: STATE_QUICK_I1: initiate
>>>
>>> 004 "gw-to-gw" #6: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
>>> mode {ESP=>0xf5fe7b43 <0x94c97925 xfrm=AES_128-HMAC_SHA1 NATOA=none
>>> NATD=none DPD=none}
>>>
>>> [root at mainmachine etc]#
>>>
>>>
>>>
>>> I’m now using Wireshark to see how the traffic goes through the network
>>> from machine A to machine B.
>>>
>>>
>>> Listening on interface *eth5 *of machine B and pinging* 10.1.2.254* or
>>> *10.1.2.2* from machine A, Wireshark does not capture any packet. If I
>>> do the exact same procedure but not listening on interface *eth6*Wireshark captures the following image.
>>>
>>> <33en.jpg>
>>>
>>>
>>> I believe that the packet should somehow be encrypted but Wireshark is
>>> telling me that it is not, so probably I have some kind of error on my
>>> *ipsec.conf* configuration.
>>>
>>>
>>> Can someone point me in some direction?
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Kent Davies
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users at lists.openswan.org
>>> https://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
>>>
>>>
>>
>>
>> --
>> **** DISCLAIMER ****
>>
>> "This e-mail and any attachment thereto may contain information which is
>> confidential and/or protected by intellectual property rights and are
>> intended for the sole use of the recipient(s) named above.
>> Any use of the information contained herein (including, but not limited
>> to, total or partial reproduction, communication or distribution in any
>> form) by other persons than the designated recipient(s) is prohibited.
>> If you have received this e-mail in error, please notify the sender
>> either by telephone or by e-mail and delete the material from any computer".
>>
>> Thank you for your cooperation.
>> _______________________________________________
>> Users at lists.openswan.org
>> https://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
>>
>>
>>
>> **** DISCLAIMER ****
>>
>> "This e-mail and any attachment thereto may contain information which is
>> confidential and/or protected by intellectual property rights and are
>> intended for the sole use of the recipient(s) named above.
>> Any use of the information contained herein (including, but not limited
>> to, total or partial reproduction, communication or distribution in any
>> form) by other persons than the designated recipient(s) is prohibited.
>> If you have received this e-mail in error, please notify the sender
>> either by telephone or by e-mail and delete the material from any computer".
>>
>> Thank you for your cooperation.
>>
>> * This e-mail was scanned against known viruses by MDaemon-DKAV
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20131116/63c322dd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 100366 bytes
Desc: not available
URL: <http://lists.openswan.org/pipermail/users/attachments/20131116/63c322dd/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 62742 bytes
Desc: not available
URL: <http://lists.openswan.org/pipermail/users/attachments/20131116/63c322dd/attachment-0003.png>
More information about the Users
mailing list