[Openswan Users] Why I have 2 tunnels up on Openswan?

Neal P. Murphy neal.p.murphy at alum.wpi.edu
Wed Oct 14 17:19:43 EDT 2015 

On Wed, 14 Oct 2015 20:36:23 +0300
Michael Furman <michael_furman at hotmail.com> wrote:

> Thanks!!!
> Is "ASD" connection name?

Yes.

> Can I create multiple host to host connections?
> Like star?

But of course! Each of your 'branches' (left sides) will have their local subnets in their respective left-subnet specs. Their right-subnet specs will contain all of the subnets for all of the branches; or they will be 0.0.0.0/0 (or 0.0.0.0/1,0.0.0.128/1 if openswan is old enough) if you want all internet traffic funneled through the central node in addition to branch traffic. The center (hub) node's ipsec.conf will have a "conn name" for each VPN; basically, it will collect all of the 'conn names' from the branches.

That said, I haven't played with this in a few years; I was helping someone connect SmoothWall Express firewalls and SonicWall firewalls. I don't remember if the conn specs are all symmetric; that is, the center node may have slightly different specs.

If any of the branch openswans are behind NAT, you'll have some extra config work to do.

N


> 
> "Neal P. Murphy" <neal.p.murphy at alum.wpi.edu> wrote:
> 
> On Wed, 14 Oct 2015 15:58:15 +0100
> Nick Howitt <nick at howitts.co.uk> wrote:
> 
> > virtual_private is irrelevant for this type of tunnel and can be dropped. I think it is only needed for roadwarrior type connections where we are allocating them an IP. Also left/rightid can probably be left to default. Unfortunately I don't know the rsa configs so I can't give much more help, although, if it were me, I'd try to get a simple psk connection going before switching to rsa
> >
> 
> A very simple host-to-host .conf using klips:
> ----------
> version 2
> 
> config setup
>         protostack=klips
>         interfaces=%defaultroute
>         klipsdebug=none
>         plutodebug=none
>         plutowait=no
>         uniqueids=yes
> 
> conn clear
>         auto=ignore
> 
> conn clear-or-private
>         auto=ignore
> 
> conn private-or-clear
>         auto=ignore
> 
> conn private
>         auto=ignore
> 
> conn block
>         auto=ignore
> 
> conn packetdefault
>         auto=ignore
> 
> conn asd
>         ike=3des-md5
>         esp=3des-md5
>         authby=secret
>         keyingtries=0
>         left=10.20.30.81
>         leftnexthop=%defaultroute
>         right=10.20.30.82
>         rightnexthop=%defaultroute
>         compress=no
>         auto=start
> ----------
> I verified that host-to-host traffic does pass through the tunnel.
> 
> You could add 'left-subnet=10.20.30.81/32' and 'right-subnet=10.20.30.82/32'; but this changes nothing, since traffic to and from the hosts' IPs are already routed through the tunnel.
> 
> You could add 'left-subnet=10.20.30.81/32,192.0.2.0/28' and 'right-subnet=10.20.30.82/32,192.0.2.16/28' to make the tunnel host/net to host/net.
> 
> You could add 'left-subnet=192.0.2.0/28' and 'right-subnet=192.0.2.16/28' to make the tunnel net to net. In this case, the hosts would have to set the source address to their respective subnet addresses in order for traffic they originate to pass through the VPN.
> 
> You could add 'left-subnet=192.0.2.3/32' and 'right-subnet=192.0.2.19/32' to make the tunnel 'client' to 'client'. In this case, only traffic between those two hosts would pass through the VPN. And if those addresses are not the hosts' addresses, the hosts could not communicate across the VPN.
> 
> You could add 'left-subnet=0.0.0.0/0' and 'right-subnet=192.0.2.19/32' to make the tunnel 'client' to 'internet'. That is, all traffic to and from 192.0.2.19 (that passes through the openswan host) would be sent across the tunnel. If the openswan hosts do not run NAT services, packets from 192.0.2.19 will travel through the VPN while packets to 192.0.2.19 will travel more directly (not in the VPN). You could use this to force all non-local branch office traffic to pass through a central node.
> 
> In short, without the subnet specs, the VPN is host-to-host. The subnet specs control exactly which traffic is sent through the VPN.
> 
> 
> [Off in the wild blue yonder] With suitable creativity, it may be possible to create a .conf that would define 'dual counter-rotating rings' of IPSEC VPNs where portions of the IP address space are divided among the various hosts (call it 'internet multi-tap'); if one host goes down, the others can still communicate. (Clearly this would be an academic exercise; cross-internet latency would be horrendous.)
> 
> N
> 
> 
> > On 14/10/2015 15:39, Michael Furman wrote:
> > Hi,
> > It is host to host tunnel.
> >
> > I want to encrypt connection from one server to another.
> >
> > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/Host-To-Host_VPN_Using_Openswan.html
> >
> > Michael
> >
> >
> > ------------------------------------------------
> > From: alex.petcu at sipstatus.com
> > To: michael_furman at hotmail.com; users at lists.openswan.org
> > Subject: RE: [Openswan Users] Why I have 2 tunnels up on Openswan?
> > Date: Wed, 14 Oct 2015 14:37:04 +0000
> >
> > HI Michael,
> >
> >
> >
> > I don’t understand what you want to accomplish. All the IPs in your config are in the same network, so the config doesn’t make much sense.
> >
> >
> >
> > Alex
> >
> >
> >
> > From: Michael Furman [mailto:michael_furman at hotmail.com]
> > Sent: Wednesday, October 14, 2015 5:29 PM
> > To: Alex Petcu <alex.petcu at sipstatus.com>; users at lists.openswan.org
> > Subject: RE: [Openswan Users] Why I have 2 tunnels up on Openswan?
> >
> >
> >
> > Alex,
> > Thank you for your help!
> >
> > I have added the allowed network in virtual_private:
> >
> > virtual_private=%v4:172.16.0.0/16
> >
> >
> > I still have same warnings but I have one channel :)
> >
> > In the previous mail I have replaced my real IPs with x.x.
> >
> > In this mail I do not replace my IPs.
> >
> >
> > Questions:
> > 1)    Why I have same warnings?
> > 2)    Do I have problems with configuration of my tunnel?
> >
> > The configuration:
> >
> > conn tunnel1
> >     leftid=@172.16.0.2
> >     left=172.16.0.2
> >     leftrsasigkey=0sAQPAhum5UFDrYdMcQChUs2mfDuH1bbJTV9mrA+H+CMWsG9ZoBqD0sAZiEDa7VcckUAzhX0pna99VRMXgyIw39qMplbwl2qPTh0Z3Gh0uU301tF/fqG3onBTkYZ2S2kEt2K4W9NX6kQtUHeS46tfK7EIezLaDAYyzszHCjBI589GPk3ONF5fP+JT32cjjsnSC7UZ42+whsuEYzA4PynRJPe8QZFPidIVAGMrPGM4G+f92Xu18W+nEPQ9F2TNwhonXEnRQm9T8h10VXXMaju76aHT0sFFJIF+usG8gvht+mHuSpVx0hYdvZ6tFeooOS3Y/TBT4Yd2wWyCmvn/M7VRBQXWe/B/ha9pr5A5LeD3Bv8VBfEUuOiJ8DfmCWV9EJVklDb3sSO7e9Ctbh1pMr8LaxBNihZARbk9VXG7Ec7wN3agcNh7AK8hqRHpHYeCI52oTKqW0WLwt7uD58aQaUb9KjJ3v6yyAB41yMk1uldW2Ne4UjVW7LD5KKJlSlcWPX2NMkDFzaLjgQjztDpGv2q1WtCCm3Z01Vygv6I5O0E4C1ho8di1RaHHBxHH1gmU5pEzDY+50JKj+oZMp/MBMm4sKXlIGhtFvL1jb7SKEo28ODA0VyqBOb6qZnqRDLY5wUQ47DpiRnceRVRBTRBGtIo3khYVQwMH9AskpWS5JBSjzs7tiww==
> >     rightid=@172.16.0.1
> >     right=172.16.0.1
> >     rightrsasigkey=0sAQOaklcK7POvVOHl+oD6NoH49/By81rm4mGil+U2PK2caW6/V20eugufjRKMRbP7ubR8EUVzNY7lXj3ylocmysB08rWtCSkecPM3IMVxHusSLok8tv6nIkT/GclBcJlSoorCp+W7KGPVrj+KuCsqmjqpcUTrrsDbkuvt2lD49AoVPEy6ODAj2mEQvRER/Rpm868pGvz0xkGVjCnqKhD7jDdodXhkSJPq1MleRmGt8M17/6Bjk3FAATXCyksZ1kU9+XKhO9C5lajUnaElTXDu9vxuIjkNQ6pYlzagn6OO98WA+HxTwRCGmIxkWMZZ2fUGwHuWz4Kp2cPLgN7Tuxahr/U9NqWCKi7ti751yDiuLaHAu1J15ywUhRMSsQWse+nrDejQ17Pgb9UXqDsbnNNbkD7Lq1C2urUMOoBb0C76XlT5Yyr82phk9YaEj2x7m9AIRHmQMOv4z92po3Gz1mAeFroJJ1/HFF+u+HrMh5bO4tivTAtNNh7R7NfbrhkJtAlUJVfB8NK90DTiCxO9x6oXG1PNGeLT/duJ2H1VatCjkiRcpITX81ytHBUmMjDLpekPOOgSZlWNr+tbn32Li3Mnfx6tBoHjXk5kzSPgYWanfJQFyyczd1js/dG3kmtyQ6Gb8m08T0AN6cJVuezT0mWtLTIyztxdkah1QaLPQZz9W+LqrQ==
> >     authby=rsasig
> >     # load and initiate automatically
> >     auto=start
> >     virtual_private=%v4:172.16.0.0/16
> >
> >
> >
> > The output of ipsec auto --status:
> >
> > 000 using kernel interface: netkey
> > 000 interface lo/lo ::1
> > 000 interface lo/lo 127.0.0.1
> > 000 interface lo/lo 127.0.0.1
> > 000 interface eth0/eth0 172.16.0.2
> > 000 interface eth0/eth0 172.16.0.2
> > 000 %myid = (none)
> > 000 debug none
> > 000
> > 000 virtual_private (%priv):
> > 000 - allowed 0 subnets:
> > 000 - disallowed 0 subnets:
> > 000 WARNING: Either virtual_private= is not specified, or there is a syntax
> > 000          error in that line. 'left/rightsubnet=vhost:%priv' will not work!
> > 000 WARNING: Disallowed subnets in virtual_private= is empty. If you have
> > 000          private address space in internal use, it should be excluded!
> > 000
> > 000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
> > 000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=128, keysizemax=128
> > 000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
> > 000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
> > 000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=12, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=16, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=12, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=16, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=22, name=(null), ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
> > 000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
> > 000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
> > 000 algorithm ESP auth attr: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384, keysizemin=384, keysizemax=384
> > 000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512, keysizemin=512, keysizemax=512
> > 000 algorithm ESP auth attr: id=8, name=(null), keysizemin=160, keysizemax=160
> > 000 algorithm ESP auth attr: id=9, name=(null), keysizemin=128, keysizemax=128
> > 000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
> > 000
> > 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=3, name=OAKLEY_BLOWFISH_CBC, blocksize=8, keydeflen=128
> > 000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
> > 000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=65004, name=OAKLEY_SERPENT_CBC, blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=65005, name=OAKLEY_TWOFISH_CBC, blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=65289, name=OAKLEY_TWOFISH_CBC_SSH, blocksize=16, keydeflen=128
> > 000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
> > 000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
> > 000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
> > 000 algorithm IKE hash: id=5, name=OAKLEY_SHA2_384, hashsize=48
> > 000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
> > 000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
> > 000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
> > 000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
> > 000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
> > 000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
> > 000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
> > 000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
> > 000 algorithm IKE dh group: id=22, name=OAKLEY_GROUP_DH22, bits=1024
> > 000 algorithm IKE dh group: id=23, name=OAKLEY_GROUP_DH23, bits=2048
> > 000 algorithm IKE dh group: id=24, name=OAKLEY_GROUP_DH24, bits=2048
> > 000
> > 000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0}
> > 000
> > 000 "tunnel1": 172.16.0.2<172.16.0.2>[@172.16.0.2,+S=C]...172.16.0.1<172.16.0.1>[@172.16.0.1,+S=C]; erouted; eroute owner: #2
> > 000 "tunnel1":     myip=unset; hisip=unset;
> > 000 "tunnel1":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; nat_keepalive: yes
> > 000 "tunnel1":   policy: RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK; prio: 32,32; interface: eth0;
> > 000 "tunnel1":   newest ISAKMP SA: #1; newest IPsec SA: #2;
> > 000 "tunnel1":   IKE algorithm newest: AES_CBC_128-SHA1-MODP2048
> > 000
> > 000 #2: "tunnel1":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 27381s; newest IPSEC; eroute owner; isakmp#1; idle; import:admin initiate
> > 000 #2: "tunnel1" esp.6960dfd0 at 172.16.0.1 esp.52077bc8 at 172.16.0.2 tun.0 at 172.16.0.1 tun.0 at 172.16.0.2 ref=0 refhim=4294901761
> > 000 #1: "tunnel1":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 1940s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
> > 000
> >
> > ------------------------------------------------
> >
> > From: alex.petcu at sipstatus.com
> > To: michael_furman at hotmail.com; users at lists.openswan.org
> > Subject: RE: [Openswan Users] Why I have 2 tunnels up on Openswan?
> > Date: Wed, 14 Oct 2015 12:42:01 +0000
> >
> > I think the answer is here:
> >
> > “000 virtual_private (%priv):
> > 000 - allowed 0 subnets:
> > 000 - disallowed 0 subnets:
> > 000 WARNING: Either virtual_private= is not specified, or there is a syntax
> > 000          error in that line. 'left/rightsubnet=vhost:%priv' will not work!
> > 000 WARNING: Disallowed subnets in virtual_private= is empty. If you have
> > 000          private address space in internal use, it should be excluded!”
> >
> >
> >
> > You should configure the allowed and blocked networks in the general section of the ipsec.conf file (virtual_private=).
> >
> >
> >
> > Your tunnel is also not correctly configured:
> >
> > x.x.0.2<x.x.0.2>[+S=C]...x.x.0.1<x.x.0.1>[+S=C]; erouted; eroute owner: #4
> >
> > The left and right IPs should be the public IPs of the 2 ends of the tunnel.
> >
> >
> >
> > From: Users [mailto:users-bounces at lists.openswan.org] On Behalf Of Michael Furman
> > Sent: Wednesday, October 14, 2015 3:32 PM
> > To: users at lists.openswan.org
> > Subject: Re: [Openswan Users] Why I have 2 tunnels up on Openswan?
> >
> >
> >
> > Hi,
> > I get the following output:
> > Where it is listed that I have 2 channels?
> > Why I have 2 channels if I have executed the following commands only once?
> >
> > ipsec auto --add tunnel1
> > ipsec auto --up tunnel1
> >
> >
> >
> > 000 using kernel interface: netkey
> > 000 interface lo/lo ::1
> > 000 interface lo/lo 127.0.0.1
> > 000 interface lo/lo 127.0.0.1
> > 000 interface eth0/eth0 x.x.0.2
> > 000 interface eth0/eth0 x.x.0.2
> > 000 %myid = (none)
> > 000 debug none
> > 000
> > 000 virtual_private (%priv):
> > 000 - allowed 0 subnets:
> > 000 - disallowed 0 subnets:
> > 000 WARNING: Either virtual_private= is not specified, or there is a syntax
> > 000          error in that line. 'left/rightsubnet=vhost:%priv' will not work!
> > 000 WARNING: Disallowed subnets in virtual_private= is empty. If you have
> > 000          private address space in internal use, it should be excluded!
> > 000
> > 000 algorithm ESP encrypt: id=3, name=ESP_3DES, ivlen=8, keysizemin=192, keysizemax=192
> > 000 algorithm ESP encrypt: id=6, name=ESP_CAST, ivlen=8, keysizemin=128, keysizemax=128
> > 000 algorithm ESP encrypt: id=7, name=ESP_BLOWFISH, ivlen=8, keysizemin=40, keysizemax=448
> > 000 algorithm ESP encrypt: id=11, name=ESP_NULL, ivlen=0, keysizemin=0, keysizemax=0
> > 000 algorithm ESP encrypt: id=12, name=ESP_AES, ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=13, name=ESP_AES_CTR, ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=14, name=ESP_AES_CCM_A, ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=15, name=ESP_AES_CCM_B, ivlen=12, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=16, name=ESP_AES_CCM_C, ivlen=16, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=12, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=16, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=22, name=(null), ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=252, name=ESP_SERPENT, ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP encrypt: id=253, name=ESP_TWOFISH, ivlen=8, keysizemin=128, keysizemax=256
> > 000 algorithm ESP auth attr: id=1, name=AUTH_ALGORITHM_HMAC_MD5, keysizemin=128, keysizemax=128
> > 000 algorithm ESP auth attr: id=2, name=AUTH_ALGORITHM_HMAC_SHA1, keysizemin=160, keysizemax=160
> > 000 algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256, keysizemin=256, keysizemax=256
> > 000 algorithm ESP auth attr: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384, keysizemin=384, keysizemax=384
> > 000 algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512, keysizemin=512, keysizemax=512
> > 000 algorithm ESP auth attr: id=8, name=(null), keysizemin=160, keysizemax=160
> > 000 algorithm ESP auth attr: id=9, name=(null), keysizemin=128, keysizemax=128
> > 000 algorithm ESP auth attr: id=251, name=(null), keysizemin=0, keysizemax=0
> > 000
> > 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=0, name=(null), blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=3, name=OAKLEY_BLOWFISH_CBC, blocksize=8, keydeflen=128
> > 000 algorithm IKE encrypt: id=5, name=OAKLEY_3DES_CBC, blocksize=8, keydeflen=192
> > 000 algorithm IKE encrypt: id=7, name=OAKLEY_AES_CBC, blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=65004, name=OAKLEY_SERPENT_CBC, blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=65005, name=OAKLEY_TWOFISH_CBC, blocksize=16, keydeflen=128
> > 000 algorithm IKE encrypt: id=65289, name=OAKLEY_TWOFISH_CBC_SSH, blocksize=16, keydeflen=128
> > 000 algorithm IKE hash: id=1, name=OAKLEY_MD5, hashsize=16
> > 000 algorithm IKE hash: id=2, name=OAKLEY_SHA1, hashsize=20
> > 000 algorithm IKE hash: id=4, name=OAKLEY_SHA2_256, hashsize=32
> > 000 algorithm IKE hash: id=5, name=OAKLEY_SHA2_384, hashsize=48
> > 000 algorithm IKE hash: id=6, name=OAKLEY_SHA2_512, hashsize=64
> > 000 algorithm IKE dh group: id=2, name=OAKLEY_GROUP_MODP1024, bits=1024
> > 000 algorithm IKE dh group: id=5, name=OAKLEY_GROUP_MODP1536, bits=1536
> > 000 algorithm IKE dh group: id=14, name=OAKLEY_GROUP_MODP2048, bits=2048
> > 000 algorithm IKE dh group: id=15, name=OAKLEY_GROUP_MODP3072, bits=3072
> > 000 algorithm IKE dh group: id=16, name=OAKLEY_GROUP_MODP4096, bits=4096
> > 000 algorithm IKE dh group: id=17, name=OAKLEY_GROUP_MODP6144, bits=6144
> > 000 algorithm IKE dh group: id=18, name=OAKLEY_GROUP_MODP8192, bits=8192
> > 000 algorithm IKE dh group: id=22, name=OAKLEY_GROUP_DH22, bits=1024
> > 000 algorithm IKE dh group: id=23, name=OAKLEY_GROUP_DH23, bits=2048
> > 000 algorithm IKE dh group: id=24, name=OAKLEY_GROUP_DH24, bits=2048
> > 000
> > 000 stats db_ops: {curr_cnt, total_cnt, maxsz} :context={0,0,0} trans={0,0,0} attrs={0,0,0}
> > 000
> > 000 "tunnel1": x.x.0.2<x.x.0.2>[+S=C]...x.x.0.1<x.x.0.1>[+S=C]; erouted; eroute owner: #4
> > 000 "tunnel1":     myip=unset; hisip=unset;
> > 000 "tunnel1":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; nat_keepalive: yes
> > 000 "tunnel1":   policy: RSASIG+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK; prio: 32,32; interface: eth0;
> > 000 "tunnel1":   newest ISAKMP SA: #3; newest IPsec SA: #4;
> > 000 "tunnel1":   IKE algorithm newest: AES_CBC_128-SHA1-MODP2048
> > 000
> > 000 #4: "tunnel1":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 28147s; newest IPSEC; eroute owner; isakmp#3; idle; import:not set
> > 000 #4: "tunnel1" esp.ff2e9b3f at x.x.0.1 esp.2d2e0f90 at x.x.0.2 tun.0 at x.x.0.1 tun.0 at x.x.0.2 ref=0 refhim=4294901761
> > 000 #3: "tunnel1":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 2947s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:not set
> > 000 #2: "tunnel1":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 27661s; isakmp#1; idle; import:admin initiate
> > 000 #2: "tunnel1" esp.599c11b1 at x.x.0.1 esp.88bbf3fd at x.x.0.2 tun.0 at x.x.0.1 tun.0 at x.x.0.2 ref=0 refhim=4294901761
> > 000 #1: "tunnel1":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 2220s; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
> > 000
> >
> >
> > To remind you this is output of service ipsec status
> >      IPsec running  - pluto pid: 17009
> >      pluto pid 17009
> >      2 tunnels up
> >      some eroutes exist
> > ------------------------------------------------
> >
> > From: alex.petcu at sipstatus.com
> > To: users at lists.openswan.org
> > Date: Mon, 12 Oct 2015 15:24:50 +0000
> > Subject: Re: [Openswan Users] Why I have 2 tunnels up on Openswan?
> >
> > You can try to see more with
> >
> > ipsec auto –status
> >
> >
> >
> > It will show details for each tunnel.
> >
> >
> >
> > From: Users [mailto:users-bounces at lists.openswan.org] On Behalf Of Michael Furman
> > Sent: Monday, October 12, 2015 4:39 PM
> > To: users at lists.openswan.org
> > Subject: [Openswan Users] Why I have 2 tunnels up on Openswan?
> >
> >
> >
> > I have started to use Openswan on Centos6 and was able to configure Host to Host using the following document:
> >
> > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/Host-To-Host_VPN_Using_Openswan.html
> >
> >
> > My configuration is following (on both sides):
> >
> >
> >         conn tunnel1
> >         left=x.x.0.2
> >         leftrsasigkey=0sA…iww==
> >         right=x.x.0.1
> >         rightrsasigkey=0sA…qrQ==
> >         authby=rsasig
> >         # load and initiate automatically
> >         auto=start
> >
> >
> >
> > I have enabled tunnel using the following command:
> >
> >     ipsec auto --add tunnel1
> >     ipsec auto --up tunnel1
> >
> >
> > Why I have 2 tunnels up?
> > I see it on both sides
> >
> >     service ipsec status
> >     IPsec running  - pluto pid: 27830
> >     pluto pid 27830
> >     2 tunnels up
> >     some eroutes exist
> >
> >
> >
> >
> >
> > _______________________________________________ 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
> >
> >
> > _______________________________________________
> > 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
> 
> _______________________________________________
> 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

More information about the Users mailing list