[Openswan dev] ipv6 4in6 and 6in4 tunnel configuration case
Paul Wouters
paul at xelerance.com
Tue Apr 19 12:19:07 EDT 2011
On Tue, 19 Apr 2011, David McCullough wrote:
[ Sent to dev at openswan.org as well, as others might want to give their input on this as well ]
> Jivin Paul Wouters lays it down ...
>> New commits:
>> commit 75b69685900246b9960c608fa61d46da4f00de39
>> Author: Paul Wouters <paul at xelerance.com>
>> Date: Tue Apr 19 00:28:17 2011 -0400
>>
>> Temporary workaround for the parser not understanding if we want to
>> do ipv4 tunneling via ipv6 endpoints
>
> Hmm, I thought this was ok, well, adding the entries to ipsec.conf
> and doing and "ipsec setup start" would work fine.
>
> Is this just with the "ipsec auto --add" ?
Taken from openswan.git/testing/baseconfigs/all/etc/ipsec.d/ipsec.conf.common
conn west-east-4in6
also=west-east-base-ipv6
also=westnet-ipv4
also=eastnet-ipv4
conn west-east-6in4
also=west-east-base-ipv4
also=westnet-eastnet-ipv6
conn west-east-base-ipv6
also=west-east-base
connaddrfamily=ipv6
left=2001:db8:1:2::45
leftnexthop=2001:db8:1:2::23
right=2001:db8:1:2::23
rightnexthop=2001:db8:1:2::45
conn west-east-base-ipv4
also=west-east-base
left=192.1.2.45
leftnexthop=192.1.2.23
right=192.1.2.23
rightnexthop=192.1.2.45
conn westnet-ipv4
also=westnet
conn westnet
leftsubnet=192.0.1.0/24
conn eastnet-ipv4
also=eastnet
conn eastnet
rightsubnet=192.0.2.0/24
conn west-east-base
# Left security gateway, subnet behind it, next hop toward right.
leftid=@west
leftrsasigkey=0sAQNzGEFs18VKT00sA+4p+GUKn9C55PYuPQca6C+9Qhj0jfMdQnTRTDLeI+lp9TnidHH7fVpq+PkfiF2LHlZtDwMurLlwzbNOghlEYKfQ080WlOTTUAmOLhAzH28MF70q3hzq0m5fCaVZWtxcV+LfHWdxceCkjBUSaTFtR2W12urFCBz+SB3+OM33aeIbfHxmck2yzhJ8xyMods5kF3ek/RZlFvgN8VqBdcFVrZwTh0mXDCGN12HNFixL6FzQ1jQKerKBbjb0m/IPqugvpVPWVIUajUpLMEmi1FAXc1mFZE9x1SFuSr0NzYIu2ZaHfvsAZY5oN+I+R2oC67fUCjgxY+t7
# Right security gateway, subnet behind it, next hop toward left.
rightid=@east
rightrsasigkey=0sAQN3cn11FrBVbZhWGwRnFDAf8O9FHBmBIyIvmvt0kfkI2UGDDq8k+vYgRkwBZDviLd1p3SkL30LzuV0rqG3vBriqaAUUGoCQ0UMgsuX+k01bROLsqGB1QNXYvYiPLsnoDhKd2Gx9MUMHEjwwEZeyskMT5k91jvoAZvdEkg+9h7urbJ+kRQ4e+IHkMUrreDGwGVptV/hYQVCD54RZep6xp5ymaKRCDgMpzWvlzO80fP7JDjSZf9LI/MMu6c+qwXIKnWoNha75IhFyLWniVczxK2RdhmMhLsi0kC0CoOwWDSIEOb+5zbECDjjud+SF5tT8qRCWnSomX8jtbCdZ50WraQlL
Gives me the following errors:
1) ipsec_setup: while loading 'west-east-4in6': bad subnet rightsubnet=192.0.2.0/24 [does not look numeric and name lookup failed]
2) ipsec_setup: duplicate key '' in conn west-east-6in4 while processing def west-east-base-ipv6
3) ipsec_setup: duplicate key 'nexthop' in conn west-east-6in4 while processing def west-east-base-ipv6
4) ipsec_setup: duplicate key '' in conn west-east-6in4 while processing def west-east-base-ipv6
5) ipsec_setup: duplicate key 'nexthop' in conn west-east-6in4 while processing def west-east-base-ipv6
6) ipsec_setup: while loading 'west-east-6in4': bad addr rightnexthop=192.1.2.45 [does not look numeric and name lookup failed]
1) I think is because it gets via an also= the connaddrfamily=ipv6
2) unknown blank keyword seems wrong :P
3) I cannot see how it got the duplicate nexthop
4) and 5) are the same as 2) and 3) for "right" I guess
6) Odd too. It seems because westnet-eastnet-ipv6 also includes also=west-east-base-ipv6 we would get duplicates there,
but not of the ipv4 kind!
So let me rewrite everything without also= statements
conn new-west-east-4in6
left=2001:db8:1:2::45
leftnexthop=2001:db8:1:2::23
right=2001:db8:1:2::23
rightnexthop=2001:db8:1:2::45
leftsubnet=192.0.1.0/24
rightsubnet=192.0.2.0/24
leftid=@west
leftrsasigkey=0sAQNzGEFs18VKT00sA+4p+GUKn9C55PYuPQca6C+9Qhj0jfMdQnTRTDLeI+lp9TnidHH7fVpq+PkfiF2LHlZtDwMurLlwzbNOghlEYKfQ080WlOTTUAmOLhAzH28MF70q3hzq0m5fCaVZWtxcV+LfHWdxceCkjBUSaTFtR2W12urFCBz+SB3+OM33aeIbfHxmck2yzhJ8xyMods5kF3ek/RZlFvgN8VqBdcFVrZwTh0mXDCGN12HNFixL6FzQ1jQKerKBbjb0m/IPqugvpVPWVIUajUpLMEmi1FAXc1mFZE9x1SFuSr0NzYIu2ZaHfvsAZY5oN+I+R2oC67fUCjgxY+t7
rightid=@east
rightrsasigkey=0sAQN3cn11FrBVbZhWGwRnFDAf8O9FHBmBIyIvmvt0kfkI2UGDDq8k+vYgRkwBZDviLd1p3SkL30LzuV0rqG3vBriqaAUUGoCQ0UMgsuX+k01bROLsqGB1QNXYvYiPLsnoDhKd2Gx9MUMHEjwwEZeyskMT5k91jvoAZvdEkg+9h7urbJ+kRQ4e+IHkMUrreDGwGVptV/hYQVCD54RZep6xp5ymaKRCDgMpzWvlzO80fP7JDjSZf9LI/MMu6c+qwXIKnWoNha75IhFyLWniVczxK2RdhmMhLsi0kC0CoOwWDSIEOb+5zbECDjjud+SF5tT8qRCWnSomX8jtbCdZ50WraQlL
conn new-west-east-6in4
connaddrfamily=ipv6
left=192.1.2.45
leftnexthop=192.1.2.23
right=192.1.2.23
rightnexthop=192.1.2.45
leftsubnet=2001:db8:0:1::/64
rightsubnet=2001:db8:0:2::/64
leftid=@west
leftrsasigkey=0sAQNzGEFs18VKT00sA+4p+GUKn9C55PYuPQca6C+9Qhj0jfMdQnTRTDLeI+lp9TnidHH7fVpq+PkfiF2LHlZtDwMurLlwzbNOghlEYKfQ080WlOTTUAmOLhAzH28MF70q3hzq0m5fCaVZWtxcV+LfHWdxceCkjBUSaTFtR2W12urFCBz+SB3+OM33aeIbfHxmck2yzhJ8xyMods5kF3ek/RZlFvgN8VqBdcFVrZwTh0mXDCGN12HNFixL6FzQ1jQKerKBbjb0m/IPqugvpVPWVIUajUpLMEmi1FAXc1mFZE9x1SFuSr0NzYIu2ZaHfvsAZY5oN+I+R2oC67fUCjgxY+t7
rightid=@east
rightrsasigkey=0sAQN3cn11FrBVbZhWGwRnFDAf8O9FHBmBIyIvmvt0kfkI2UGDDq8k+vYgRkwBZDviLd1p3SkL30LzuV0rqG3vBriqaAUUGoCQ0UMgsuX+k01bROLsqGB1QNXYvYiPLsnoDhKd2Gx9MUMHEjwwEZeyskMT5k91jvoAZvdEkg+9h7urbJ+kRQ4e+IHkMUrreDGwGVptV/hYQVCD54RZep6xp5ymaKRCDgMpzWvlzO80fP7JDjSZf9LI/MMu6c+qwXIKnWoNha75IhFyLWniVczxK2RdhmMhLsi0kC0CoOwWDSIEOb+5zbECDjjud+SF5tT8qRCWnSomX8jtbCdZ50WraQlL
That gives me:
while loading 'new-west-east-4in6': bad addr rightnexthop=2001:db8:1:2::45 [non-ipv6 address may not contain `:']
while loading 'new-west-east-6in4': bad addr rightnexthop=192.1.2.45 [does not look numeric and name lookup failed]
If I move the connaddrfamily=ipv6 from new-west-east-6in4 to new-west-east-4in6:
while loading 'new-west-east-4in6': bad subnet rightsubnet=192.0.2.0/24 [does not look numeric and name lookup failed]
while loading 'new-west-east-6in4': bad subnet rightsubnet=2001:db8:0:2::/64 [non-ipv6 address may not contain `:']
So it really seems that the connaddrfamily= option is screwing things up. And I don't like that option at all,
because it will confuse people with these 4in6 and 6in4 tunnels.
With whack, I made the assumption that --ipv4/--ipv6 is specified for the left/right family and
--tunnelipv4/--tunnelipv6 is specified for the leftsubnet/rightsubnet family. Then the connections
load (and I got partial packet flow, but I need to confirm the latest klips ipv6 policy patches
to see if that fixes my packet flow (I got packets flowing from west to east but not back)
What I would like to do is obsolete connaddrfamily= and figure this out based on the family
of left/right and leftsubnet/rightsubnet.
Paul
More information about the Dev
mailing list