[strongSwan] Migration from Openswan to Strongswan

Andreas Steffen andreas.steffen at strongswan.org
Tue May 10 14:50:53 CEST 2011


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]==




More information about the Users mailing list