[Openswan Users] Hub and spoke routing issue when using Openswan
Mattias Mattsson
mm4748190 at gmail.com
Thu Feb 12 11:40:34 EST 2009
Hi Frank,
I appreciate your answer.
I'm starting to get an idea of what the issue is now. Reading your email I
started to investigate my eroutes more. I then saw the recent email
regarding
http://bugs.xelerance.com/view.php?id=985
and read through the information there when I realized that I had
encountered the same issue as mentioned in this bug.
When compiling openswan and using it, I found that the 'eroute' command was
segfaulting and tracked down the problem to an array size. I applied the
same fix as mentioned in bug id 985, i.e. replaced
struct sadb_ext *extensions[SADB_EXT_MAX + 1];
with
struct sadb_ext *extensions[K_SADB_EXT_MAX + 1];
in eroute.c
This fixed the command so that it didn't segfault and I could see eroutes
being inserted so I didn't think more of it.
Now, however, I tried a more basic scenario with just a plain eroute to a
subnet behind the hub, and that does not work either. So apparently there
are further issues in the eroute binary causing manually inserted eroutes to
not work.
I'll continue looking there.
Thanks / Mattias
On Wed, Feb 11, 2009 at 10:22 AM, Frank Mayer <frank.mayer at knapp.com> wrote:
>
> Hi,
>
> as far as I know, also from other devices, you need to have a separate
> IPSec SA for each left/right subnet pair.
> E.g. with a Cisco router given the access list
> permit ip 172.16.10.0 0.0.0.255 172.16.30.0 0.0.0.255
> permit ip 172.16.10.0 0.0.0.255 172.16.60.0 0.0.0.255
> as a pendant to left/right subnets, the Cisco device would automatically
> establish
> - one IPSec SA for 172.16.10.0/24 <=> 172.16.30.0/24, and
> - one IPSec SA for 172.16.10.0/24 <=> 172.16.60.0/24
>
> I've never been working with FreeS/WAN, but do you think, FreeS/WAN might
> have behaved similarly? Can you maybe check how many IPSEC SAs FreeS/WAN
> establishes for each of your connections?
>
> With Openswan, the only thing that ever worked for me was configuring a
> separate connection for each pair of left/right subnets. Openswan will,
> then, establish only one ISAKMP SA with the Peer, but will establish one
> IPSEC SA per connection defined.... maybe not the ideal solution.
>
> Something that might be worth looking into would be tunnelling over IPSec:
> you establish a host-to-host IPSec Tunnel, and inside that IPSEC tunnel you
> define e.g. a GRE (IP-over-IP- or whatever) tunnel.
> That tunnelling device, then, can be used for routing as many subnets as
> you like without needing to change the IPSec configuration at all.
>
> Best Regards,
> Frank
>
> (Please forgive the long signature, but it's required for company
> policies).
> Mit freundlichen Grüßen
>
> Frank Mayer
> Computer Technologies Group
> -----------------------------
> Phone: +43 316 495-5640
> Mobile: +43 664 80495 5640
> Fax: +43 316 491 395
> frank.mayer at knapp.com
> www.KNAPP.com
> -----------------------------
> KNAPP Logistik Automation GmbH
> Guenter-Knapp-Str. 5-7
> 8075 Hart bei Graz, Austria
> -----------------------------
> Commercial register number: FN 36404k
> Commercial register court: Graz
> -----------------------------
> The information in this e-mail (including any attachment) is confidential
> and intended to be for the use of the addressee(s) only. If you have
> received the e-mail by mistake, any disclosure, copy, distribution or use of
> the contents of the e-mail is prohibited, and you must delete the e-mail
> from your system. As e-mail can be changed electronically KNAPP assumes no
> responsibility for any alteration to this e-mail or its attachments. KNAPP
> has taken every reasonable precaution to ensure that any attachment to this
> e-mail has been swept for virus. However, KNAPP does not accept any
> liability for damage sustained as a result of such attachment being virus
> infected and strongly recommend that you carry out your own virus check
> before opening any attachment.
>
>
> > ----- Message from Mattias Mattsson <mm4748190 at gmail.com> on Wed, 11
> > Feb 2009 09:15:31 -0800 -----
> >
> > To:
> >
> > hiren joshi <joshihirenn at gmail.com>
> >
> > cc:
> >
> > users at openswan.org
> >
> > Subject:
> >
> > Re: [Openswan Users] Hub and spoke routing issue when using Openswan
> >
> > Hi Hiren,
> >
> > Thanks for your answer.
> >
> > I tried the configuration you suggested but I cannot get the tunnels
> > to establish if the hub does not actually own the subnet being
> > configured in ipsec.conf.
> >
> > Is this kind of setup supported in Openswan? If others have this
> > working then maybe my issue lies elsewhere?
> >
> > Thanks / Mattias
> >
>
> > On Wed, Feb 11, 2009 at 2:59 AM, hiren joshi <joshihirenn at gmail.com>
> wrote:
> > Are you sure leftsubnet/rightsubnet configuration is right?
> > I think it should be something like:
> >
> > y'
> > |
> > x' -- X -- Y -- Z -- z'
> >
> > X(spoke-1):
> > leftsubnet x'
> > rightsubnect z'
> > left X
> > right Y
> >
> > Z(spoke-2):
> > leftsubnet z'
> > rightsubnect x'
> > left Z
> > right Y
> >
> > Y: C-1 Y: C-2
> > leftsubnet x' leftsubnet z'
> > rightsubnect z' rightsubnect x'
> > left Y left Y
> > right Z right X
> >
> > Regards,
> > hiren
> >
> > On Tue, Feb 10, 2009 at 10:09 PM, Mattias Mattsson <mm4748190 at gmail.com
> > > wrote:
> > > Hi All,
> > >
> > > I'm having a problem when trying to upgrade from FreeS/WAN 1.99 to
> Openswan
> > > 2.6.18 (klips).
> > >
> > > The setup is a hub and spoke VPN where two spoke sites (B and C) are
> > > connecting into the hub site (A). The protected subnets are all
> different
> > > (i.e. this is not an 'extruded subnet' setup) and eroutes are used to
> route
> > > from B to C and vice versa.
> > >
> > > On each of the spokes, an additional eroute is added with the local
> subnet
> > > as the source and the other spokes subnet as the destination and the
> hub as
> > > the gateway.
> > >
> > > On the hub, two eroutes are added, each having one spoke as the source
> and
> > > the other spoke as the destination.
> > >
> > > This works fine when using Freeswan, but when using Openswan for the
> hub,
> > > the Hub does not even accept the incoming traffic from the spoke, i.e.
> if I
> > > do a tcpdump on ipsec0 I do not see the incoming traffic.
> > >
> > > I'm including the configuration for the two setups, as well as some
> ping and
> > > tcpdump output, note that they have different IP addresses (I set up
> two
> > > setups to be able to run the tests at the same time). For both setups,
> the
> > > WAN addresses are on the 192.168.1.x network and the LAN addresses are
> on
> > > different 172.16.x.x subnets. Also note that in the Openswan setup,
> only the
> > > hub is using Openswan, the two spokes are still Freeswan.
> > >
> > > How do I make this work in Openswan?
> > >
> > > Thanks / Mattias
> > >
> > >
> > >
> > >
> >
> -------------------------------------------------------------------------------------------------------------------------------------
> > > For the Freeswan setup, the IP addresses are as follows:
> > > Hub - 172.16.10.110 - 192.168.1.10
> > > Spoke1 - 172.16.30.130 - 192.168.1.30
> > > Spoke2 - 172.16.60.160 - 192.168.1.60
> > >
> > > Hub's ipsec.conf
> > > -----------------------
> > > config setup
> > > interfaces = "ipsec0=eth1"
> > > klipsdebug = none
> > > plutodebug = none
> > > plutoload = %search
> > > plutostart = %search
> > > uniqueids = yes
> > > hidetos = no
> > > conn t10to30
> > > type = tunnel
> > > left = 192.168.1.10
> > > right = 192.168.1.30
> > > leftnexthop = 192.168.1.1
> > > leftsubnet = 172.16.10.0/24
> > > rightsubnet = 172.16.30.0/24
> > > auto = start
> > > keyexchange = ike
> > > authby = secret
> > > auth = esp
> > > keyingtries = 0
> > > esp = AES128-SHA1
> > > pfs = yes
> > > rekey = yes
> > > leftid = 192.168.1.10
> > > rightid = 192.168.1.30
> > > ike = 3DES-SHA-MODP1024
> > > ikelifetime = 28800s
> > > keylife = 86400s
> > > rekeymargin = 10m
> > > rekeyfuzz = 20%
> > > conn t10to60
> > > type = tunnel
> > > left = 192.168.1.10
> > > right = 192.168.1.60
> > > leftnexthop = 192.168.1.1
> > > leftsubnet = 172.16.10.0/24
> > > rightsubnet = 172.16.60.0/24
> > > auto = start
> > > keyexchange = ike
> > > authby = secret
> > > auth = esp
> > > keyingtries = 0
> > > esp = AES128-SHA1
> > > pfs = yes
> > > rekey = yes
> > > leftid = 192.168.1.10
> > > rightid = 192.168.1.60
> > > ike = 3DES-SHA-MODP1024
> > > ikelifetime = 28800s
> > > keylife = 86400s
> > > rekeymargin = 10m
> > > rekeyfuzz = 20%
> > >
> > > Hub's eroutes
> > > -----------------------
> > > 0 172.16.10.0/24 -> 172.16.30.0/24 =>
> > > tun0x101b at 192.168.1.30
> > > 0 172.16.10.0/24 -> 172.16.60.0/24 =>
> > > tun0x101f at 192.168.1.60
> > > 26 172.16.30.0/24 -> 172.16.60.0/24 =>
> > > tun0x101f at 192.168.1.60
> > > 26 172.16.60.0/24 -> 172.16.30.0/24 =>
> > > tun0x101b at 192.168.1.30
> > >
> > > Spoke1's ipsec.conf
> > > -----------------------
> > > config setup
> > > interfaces = "ipsec0=eth1"
> > > klipsdebug = none
> > > plutodebug = none
> > > plutoload = %search
> > > plutostart = %search
> > > uniqueids = yes
> > > hidetos = no
> > > conn t30to10
> > > type = tunnel
> > > left = 192.168.1.30
> > > right = 192.168.1.10
> > > leftnexthop = 192.168.1.1
> > > leftsubnet = 172.16.30.0/24
> > > rightsubnet = 172.16.10.0/24
> > > auto = start
> > > keyexchange = ike
> > > authby = secret
> > > auth = esp
> > > keyingtries = 0
> > > esp = AES128-SHA1
> > > pfs = yes
> > > rekey = yes
> > > leftid = 192.168.1.30
> > > rightid = 192.168.1.10
> > > ike = 3DES-SHA-MODP1024
> > > ikelifetime = 28800s
> > > keylife = 86400s
> > > rekeymargin = 10m
> > > rekeyfuzz = 20%
> > >
> > > Spoke1's eroutes
> > > -----------------------
> > > 0 172.16.30.0/24 -> 172.16.10.0/24 =>
> > > tun0x1004 at 192.168.1.10
> > > 26 172.16.30.0/24 -> 172.16.60.0/24 =>
> > > tun0x1004 at 192.168.1.10
> > >
> > >
> > > Spoke2's ipsec.conf
> > > -----------------------
> > > config setup
> > > interfaces = "ipsec0=eth1"
> > > klipsdebug = none
> > > plutodebug = none
> > > plutoload = %search
> > > plutostart = %search
> > > uniqueids = yes
> > > hidetos = no
> > > conn t60to10
> > > type = tunnel
> > > left = 192.168.1.60
> > > right = 192.168.1.10
> > > leftnexthop = 192.168.1.1
> > > leftsubnet = 172.16.60.0/24
> > > rightsubnet = 172.16.10.0/24
> > > auto = start
> > > keyexchange = ike
> > > authby = secret
> > > auth = esp
> > > keyingtries = 0
> > > esp = AES128-SHA1
> > > pfs = yes
> > > rekey = yes
> > > leftid = 192.168.1.60
> > > rightid = 192.168.1.10
> > > ike = 3DES-SHA-MODP1024
> > > ikelifetime = 28800s
> > > keylife = 86400s
> > > rekeymargin = 10m
> > > rekeyfuzz = 20%
> > >
> > > Spoke2's eroutes
> > > -----------------------
> > > 0 172.16.60.0/24 -> 172.16.10.0/24 =>
> > > tun0x1004 at 192.168.1.10
> > > 62 172.16.60.0/24 -> 172.16.30.0/24 =>
> > > tun0x1004 at 192.168.1.10
> > >
> > >
> > > When pinging from spoke1 to hub:
> > > # ping -I 172.16.30.130 172.16.10.110
> > > PING 172.16.10.110 (172.16.10.110): 56 data bytes
> > > 64 bytes from 172.16.10.110: icmp_seq=0 ttl=64 time=3.2 ms
> > > 64 bytes from 172.16.10.110: icmp_seq=1 ttl=64 time=2.3 ms
> > >
> > > When pinging from spoke1 to spoke2:
> > > # ping -I 172.16.30.130 172.16.60.160
> > > PING 172.16.60.160 (172.16.60.160): 56 data bytes
> > > 64 bytes from 172.16.60.160: icmp_seq=0 ttl=63 time=12.7 ms
> > > 64 bytes from 172.16.60.160: icmp_seq=1 ttl=63 time=4.6 ms
> > >
> > > Tcpdump on spoke1 when pinging from spoke1 to spoke2:
> > > # tcpdump -ni ipsec0 icmp
> > > tcpdump: listening on ipsec0
> > > 00:34:17.262268 172.16.30.130 > 172.16.60.160: icmp: echo request (DF)
> > > 00:34:17.266201 172.16.60.160 > 172.16.30.130: icmp: echo reply
> > >
> > > And tcpdump on hub when pinging from spoke1 to spoke2:
> > > # tcpdump -ni ipsec0 icmp
> > > tcpdump: listening on ipsec0
> > > 16:29:56.543048 172.16.30.130 > 172.16.60.160: icmp: echo request (DF)
> > > 16:29:56.543527 172.16.30.130 > 172.16.60.160: icmp: echo request (DF)
> > > 16:29:56.545636 172.16.60.160 > 172.16.30.130: icmp: echo reply
> > > 16:29:56.546168 172.16.60.160 > 172.16.30.130: icmp: echo reply
> > >
> > >
> > >
> >
> -------------------------------------------------------------------------------------------------------------------------------------
> > > For the Openswan setup, the IP addresses are as follows:
> > > Hub - 172.16.50.150 - 192.168.1.50
> > > Spoke1 - 172.16.40.140 - 192.168.1.40
> > > Spoke2 - 172.16.20.120 - 192.168.1.20
> > >
> > > Hub's ipsec.conf
> > > -----------------------
> > > config setup
> > > interfaces = "ipsec0=eth1"
> > > klipsdebug = none
> > > plutodebug = none
> > > uniqueids = yes
> > > hidetos = no
> > > conn t50to40
> > > type = tunnel
> > > left = 192.168.1.50
> > > right = 192.168.1.40
> > > leftnexthop = 192.168.1.1
> > > leftsubnet = 172.16.50.0/24
> > > rightsubnet = 172.16.40.0/24
> > > auto = start
> > > keyexchange = ike
> > > authby = secret
> > > auth = esp
> > > keyingtries = 0
> > > esp = AES128-SHA1
> > > pfs = yes
> > > rekey = yes
> > > leftid = 192.168.1.50
> > > rightid = 192.168.1.40
> > > ike = 3DES-SHA-MODP1024
> > > ikelifetime = 28800s
> > > keylife = 86400s
> > > rekeymargin = 10m
> > > rekeyfuzz = 20%
> > > conn t50to20
> > > type = tunnel
> > > left = 192.168.1.50
> > > right = 192.168.1.20
> > > leftnexthop = 192.168.1.1
> > > leftsubnet = 172.16.50.0/24
> > > rightsubnet = 172.16.20.0/24
> > > auto = start
> > > keyexchange = ike
> > > authby = secret
> > > auth = esp
> > > keyingtries = 0
> > > esp = AES128-SHA1
> > > pfs = yes
> > > rekey = yes
> > > leftid = 192.168.1.50
> > > rightid = 192.168.1.20
> > > ike = 3DES-SHA-MODP1024
> > > ikelifetime = 28800s
> > > keylife = 86400s
> > > rekeymargin = 10m
> > > rekeyfuzz = 20%
> > >
> > > Hub's eroutes
> > > -----------------------
> > > 0 172.16.20.0/24 -> 172.16.40.0/24 =>
> > > tun0x1016 at 192.168.1.40
> > > 0 172.16.40.0/24 -> 172.16.20.0/24 =>
> > > tun0x1014 at 192.168.1.20
> > > 2 172.16.50.0/24 -> 172.16.20.0/24 =>
> > > tun0x1014 at 192.168.1.20
> > > 12 172.16.50.0/24 -> 172.16.40.0/24 =>
> > > tun0x1016 at 192.168.1.40
> > >
> > >
> > > Spoke1's ipsec.conf
> > > -----------------------
> > > config setup
> > > interfaces = "ipsec0=eth1"
> > > klipsdebug = none
> > > plutodebug = none
> > > plutoload = %search
> > > plutostart = %search
> > > uniqueids = yes
> > > hidetos = no
> > > conn t40to50
> > > type = tunnel
> > > left = 192.168.1.40
> > > right = 192.168.1.50
> > > leftnexthop = 192.168.1.1
> > > leftsubnet = 172.16.40.0/24
> > > rightsubnet = 172.16.50.0/24
> > > auto = start
> > > keyexchange = ike
> > > authby = secret
> > > auth = esp
> > > keyingtries = 0
> > > esp = AES128-SHA1
> > > pfs = yes
> > > rekey = yes
> > > leftid = 192.168.1.40
> > > rightid = 192.168.1.50
> > > ike = 3DES-SHA-MODP1024
> > > ikelifetime = 28800s
> > > keylife = 86400s
> > > rekeymargin = 10m
> > > rekeyfuzz = 20%
> > >
> > > Spoke1's eroutes
> > > -----------------------
> > > 2 172.16.20.0/24 -> 172.16.40.0/24 =>
> > > tun0x1008 at 192.168.1.50
> > > 2 172.16.20.0/24 -> 172.16.50.0/24 =>
> > > tun0x1008 at 192.168.1.50
> > >
> > > Spoke2's ipsec.conf
> > > -----------------------
> > > config setup
> > > interfaces = "ipsec0=eth1"
> > > klipsdebug = none
> > > plutodebug = none
> > > plutoload = %search
> > > plutostart = %search
> > > uniqueids = yes
> > > hidetos = no
> > > conn t20to50
> > > type = tunnel
> > > left = 192.168.1.20
> > > right = 192.168.1.50
> > > leftnexthop = 192.168.1.1
> > > leftsubnet = 172.16.20.0/24
> > > rightsubnet = 172.16.50.0/24
> > > auto = start
> > > keyexchange = ike
> > > authby = secret
> > > auth = esp
> > > keyingtries = 0
> > > esp = AES128-SHA1
> > > pfs = yes
> > > rekey = yes
> > > leftid = 192.168.1.20
> > > rightid = 192.168.1.50
> > > ike = 3DES-SHA-MODP1024
> > > ikelifetime = 28800s
> > > keylife = 86400s
> > > rekeymargin = 10m
> > > rekeyfuzz = 20%
> > >
> > > Spoke2's eroutes
> > > -----------------------
> > > 549 172.16.40.0/24 -> 172.16.20.0/24 =>
> > > tun0x100c at 192.168.1.50
> > > 12 172.16.40.0/24 -> 172.16.50.0/24 =>
> > > tun0x100c at 192.168.1.50
> > >
> > >
> > > When pinging from spoke1 to hub:
> > > # ping -I 172.16.20.120 172.16.50.150
> > > PING 172.16.50.150 (172.16.50.150): 56 data bytes
> > > 64 bytes from 172.16.50.150: icmp_seq=0 ttl=64 time=12.4 ms
> > > 64 bytes from 172.16.50.150: icmp_seq=1 ttl=64 time=10.4 ms
> > >
> > > When pinging from spoke1 to spoke2:
> > > # ping -I 172.16.20.120 172.16.40.140
> > > PING 172.16.40.140 (172.16.40.140): 56 data bytes
> > >
> > > --- 172.16.40.140 ping statistics ---
> > > 8 packets transmitted, 0 packets received, 100% packet loss
> > >
> > > Tcpdump on spoke1 when pinging from spoke1 to spoke2:
> > > # tcpdump -ni ipsec0 icmp
> > > tcpdump: listening on ipsec0
> > > 16:33:49.927435 172.16.20.120 > 172.16.40.140: icmp: echo request (DF)
> > > 16:33:50.927440 172.16.20.120 > 172.16.40.140: icmp: echo request (DF)
> > >
> > > And tcpdump on hub when pinging from spoke1 to spoke2:
> > > # tcpdump -ni ipsec0 icmp
> > > tcpdump: listening on ipsec0
> > >
> > > 0 packets received by filter
> > > 0 packets dropped by kernel
> > >
> > >
> > > I can ping from the hub to spoke2:
> > > # ping -I 172.16.50.150 172.16.40.140
> > > PING 172.16.40.140 (172.16.40.140): 56 data bytes
> > > 64 bytes from 172.16.40.140: icmp_seq=0 ttl=64 time=3.3 ms
> > > 64 bytes from 172.16.40.140: icmp_seq=1 ttl=64 time=2.1 ms
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Users at openswan.org
> > > http://lists.openswan.org/mailman/listinfo/users
> > > Building and Integrating Virtual Private Networks with Openswan:
> > >
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
> > >
> > >
> > _______________________________________________
> > Users at openswan.org
> > http://lists.openswan.org/mailman/listinfo/users
> > Building and Integrating Virtual Private Networks with Openswan:
> > http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20090212/1ec6120b/attachment-0001.html
More information about the Users
mailing list