[strongSwan] Migration from Openswan to Strongswan
Pavel Arnošt
pavel.arnost at valvera.cz
Tue May 10 15:07:07 CEST 2011
It looks like that there are zeroes everywhere.
--------------------------------------------------
From: "Andreas Steffen" <andreas.steffen at strongswan.org>
Sent: Tuesday, May 10, 2011 2:50 PM
To: "Pavel Arnošt" <pavel.arnost at valvera.cz>
Cc: <users at lists.strongswan.org>
Subject: Re: [strongSwan] Migration from Openswan to Strongswan
> The problem looks extremely strange. Could you send me the following
> information:
>
> ip -s xfrm policy
> ip -x xfrm state
>
> so that I can check if there are any packet hits or esp errors.
>
> Andreas
>
> On 05/10/2011 01:19 PM, Pavel Arnošt wrote:
>> Hi, thanks, I managed to get similar system with the same software
>> versions
>> but simplier setup where I can test it at will. At the beginning, I have
>> Openswan:
>>
>> /etc/ipsec.conf:
>>
>> version 2.0
>>
>> config setup
>> plutodebug="parsing"
>>
>> conn %default
>> authby=secret
>>
>> conn CONN
>> type=tunnel
>> left=A.A.A.A
>> leftsubnet=172.24.26.64/26
>> right=B.B.B.B
>> rightsubnet=172.27.96.15/32
>> auto=start
>> auth=esp
>> keylife=3600s
>> ikelifetime=1440m
>> compress=no
>> ike=aes256-sha1,aes128-md5
>> esp=aes256-sha1,aes128-md5
>> pfs=yes
>>
>> # ping -I 172.24.26.65 172.27.96.15
>> PING 172.27.96.15 (172.27.96.15) from 172.24.26.65 : 56(84) bytes of
>> data.
>> 64 bytes from 172.27.96.15: icmp_seq=1 ttl=123 time=6.32 ms
>> 64 bytes from 172.27.96.15: icmp_seq=2 ttl=123 time=5.69 ms
>> 64 bytes from 172.27.96.15: icmp_seq=3 ttl=123 time=5.58 ms
>>
>> Then I uninstall Openswan and install Strongswan:
>>
>> /etc/ipsec.conf:
>>
>> version 2.0
>>
>> config setup
>> plutodebug="parsing"
>> charonstart=no
>>
>> conn %default
>> keyexchange=ikev1
>> authby=secret
>> leftfirewall=yes
>> lefthostaccess=yes
>>
>> conn CONN
>> type=tunnel
>> left=A.A.A.A
>> leftsubnet=172.24.26.64/26
>> right=B.B.B.B
>> rightsubnet=172.27.96.15/32
>> auto=start
>> auth=esp
>> keylife=3600s
>> ikelifetime=1440m
>> compress=no
>> ike=aes256-sha1,aes128-md5
>> esp=aes256-sha1,aes128-md5
>> pfs=yes
>>
>> # ping -I 172.24.26.65 172.27.96.15
>> PING 172.27.96.15 (172.27.96.15) from 172.24.26.65 : 56(84) bytes of
>> data.
>> ping: sendmsg: No such process
>> ping: sendmsg: No such process
>> ping: sendmsg: No such process
>>
>> SAs are established:
>>
>> 000 #2: "CONN" STATE_QUICK_I2 (sent QI2, IPsec SA established);
>> EVENT_SA_REPLACE in 2719s; newest IPSEC; eroute owner
>> 000 #2: "CONN" esp.bfbfcee8 at 194.228.96.46 (0 bytes)
>> esp.c7b835a6 at 213.180.34.38 (0 bytes); tunnel
>> 000 #1: "CONN" STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in
>> 85277s; newest ISAKMP
>>
>> Policies are in place:
>>
>> src 172.27.96.15/32 dst 172.24.26.64/26
>> dir in priority 1819
>> tmpl src B.B.B.B dst A.A.A.A
>> proto esp reqid 16384 mode tunnel
>> src 172.24.26.64/26 dst 172.27.96.15/32
>> dir out priority 1819
>> tmpl src A.A.A.A dst B.B.B.B
>> proto esp reqid 16386 mode tunnel
>> src 172.27.96.15/32 dst 172.24.26.64/26
>> dir fwd priority 1819
>> tmpl src B.B.B.B dst A.A.A.A
>> proto esp reqid 16385 mode tunnel
>>
>> Firewall policies also in place:
>>
>> Chain INPUT (policy DROP 63626 packets, 5624K bytes)
>> pkts bytes target prot opt in out source
>> destination
>> 0 0 ACCEPT all -- eth1 * 172.27.96.15
>> 172.24.26.64/26 policy match dir in pol ipsec reqid 16384 proto 50
>>
>> Chain FORWARD (policy DROP 106K packets, 4269K bytes)
>> pkts bytes target prot opt in out source
>> destination
>> 0 0 ACCEPT all -- eth1 * 172.27.96.15
>> 172.24.26.64/26 policy match dir in pol ipsec reqid 16384 proto 50
>>
>> Chain OUTPUT (policy ACCEPT 21M packets, 21G bytes)
>> pkts bytes target prot opt in out source
>> destination
>> 0 0 ACCEPT all -- * eth1 172.24.26.64/26
>> 172.27.96.15 policy match dir out pol ipsec reqid 16384 proto 50
>>
>> All zeroes, I would expect something in the OUTPUT chain (from ping -I
>> 172.24.26.65 172.27.96.15).
>>
>> eth1 is external interface and eth0 is internal interface with IP
>> 172.24.26.65 assigned:
>>
>> 2: eth0:<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen
>> 1000
>> link/ether 00:18:fe:32:56:08 brd ff:ff:ff:ff:ff:ff
>> inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
>> inet 172.24.26.65/26 brd 172.24.26.127 scope global eth0:0
>>
>> What am I missing?
>>
>> Thanks,
>> Regards,
>> Pavel Arnost
>>
>> --------------------------------------------------
>> From: "Andreas Steffen"<andreas.steffen at strongswan.org>
>> Sent: Tuesday, May 10, 2011 12:12 PM
>> To: "Pavel Arnošt"<pavel.arnost at valvera.cz>
>> Cc:<users at lists.strongswan.org>
>> Subject: Re: [strongSwan] Migration from Openswan to Strongswan
>>
>>> Hello Pavel,
>>>
>>> if you have iptables in place and you ping the internal interface
>>> of the VPN gateway then you need an INPUT/OUTPUT iptables rule
>>> to access that interface. Thus you'll need
>>>
>>> leftfirewall=yes
>>> lefthostaccess=yes
>>>
>>> If you have a MASQUERADING rule in place which NATs all traffic
>>> from the internal network to the outer IP address of the gateway
>>> then you must exempt traffic to be tunneled from this rule by adding
>>>
>>> iptables -t nat -I POSTROUTING 1 -s 10.10.0.0/16 -o eth0 \
>>> -m policy --dir out --pol ipsec --proto esp -j ACCEPT
>>>
>>> Regards
>>>
>>> Andreas
>>>
>>> On 05/10/2011 11:51 AM, Pavel Arnošt wrote:
>>>> Hi,
>>>> I tried to migrate our Openswan VPN (2.6.21) to Strongswan VPN (4.5.1)
>>>> on our CentOS 5 server. Openswan package is from official CentOS
>>>> repository (openswan-2.6.21-5.el5_6.4), Strongswan package have been
>>>> built from this spec file:
>>>> http://developer.intra2net.com/git/?p=strongswan-rpm;a=blob_plain;f=strongswan.spec;hb=e2bb0076fce6d44ee80cff4b20d90a0eee1fa689
>>>> I slightly modified configuration for IKEv1 keying, ipsec.conf looks
>>>> like:
>>>> config setup
>>>> charonstart=no
>>>> plutodebug="control"
>>>> conn %default
>>>> keyexchange=ikev1
>>>> authby=secret
>>>> conn CONN
>>>> type=tunnel
>>>> left=A.A.A.A
>>>> leftsubnet=192.168.52.0/24
>>>> right=B.B.B.B
>>>> rightsubnet=10.10.0.0/16
>>>> auto=start
>>>> auth=esp
>>>> ikelifetime=28800s
>>>> keylife=3600s
>>>> compress=no
>>>> ike=3des-sha1-modp1024
>>>> esp=3des-sha1
>>>> pfs=yes
>>>> dpddelay=30
>>>> dpdtimeout=120
>>>> dpdaction=restart
>>>> Both ISAKMP and IPsec SA were succesfully established, ip xfrm policy
>>>> output was the same as output from Openswan. But...
>>>> In tcpdump, I saw incoming ESP traffic from B.B.B.B, but no ESP traffic
>>>> from our address A.A.A.A. Ping to 10.10.255.1 returned no response, so
>>>> I
>>>> think that policies were in place (with turned off VPN, ping returned
>>>> "host unreachable" from far away gateway). I added "iptables -I FORWARD
>>>> -j ACCEPT" rule to iptables to rule out problem with firewall.
>>>> Do you have any idea what can be wrong?
>>>> Thanks,
>>>> Regards,
>>>> Pavel Arnost
>
> ======================================================================
> Andreas Steffen andreas.steffen at strongswan.org
> strongSwan - the Linux VPN Solution! www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ip_s_xfrm_policy.txt
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110510/055af6fa/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ip_s_xfrm_state.txt
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110510/055af6fa/attachment-0001.txt>
More information about the Users
mailing list