headers
Paolo Basenghi | 1 Jun 2006 10:38
Picon
Favicon

Re: High Availability (HA)

Heartbeat can only be a part of the whole design.
Heartbeat can do IP address failover, but cannot do iptables/netfilter status replication between hosts: if the master breaks, the second node will accept traffic on the same IP after heartbeat system has "failed-over" the IP address, but every existing connection established on the master will fail on the secondary node because every packet will be considered NEW and every existing NATed connection will break. Heartbeat does not and cannot maintain the netfilter kernel tables syncronized.

Heartbeat is good for service failover but leave to each service the duty of providing status and data replication.

If the service is netfilter/iptables firewall, the solution for status replication can be ct_sync, but is a not yet mature project and involve kernel patching and rebuild.
You can refer to: http://svn.netfilter.org/netfilter/branches/netfilter-ha/linux-2.6/README for more info about it.

And... if you will be successful with it please: share your experience!!  :-)

Bye
----------------------------------------------------- Paolo Basenghi - Sistemi Informativi Az. Speciale Farmacie Comunali Riunite Via Doberdò, 9 - 42100 Reggio Emilia Tel. +39(0522)543312 - Fax +39(0522)550146 paolo.basenghi <at> fcr.re.it; www.fcr.re.it; www.saninforma.it; www.futurfarma.it -----------------------------------------------------

Julian Hein ha scritto:
Hi,
I look for a HA solution. Did some of you manage to configure such a solution ?
Yes, with heartbeat. If one node goes down, the other takes over. It is pretty straight. Best, Julian ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=k&kid
Permalink | Reply | 4 comments |
headers
Tom Eastep | 1 Jun 2006 18:31
Favicon

Re: High Availability (HA)

Paolo Basenghi wrote:

> 
> If the service is netfilter/iptables firewall, the solution for status
> replication can be ct_sync, but is a not yet mature project and involve
> kernel patching and rebuild.
> You can refer to:
> http://svn.netfilter.org/netfilter/branches/netfilter-ha/linux-2.6/README
> for more info about it.
> 

It is my understanding that work on ct_sync has pretty much stopped and the code
in SVN is against 2.6.10 or thereabouts.

-Tom
--

-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep <at> shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
Permalink | Reply | 3 comments |
headers
John Serink | 1 Jun 2006 19:42
Picon
Favicon

Openswan 2.2.0 using the the 2.6 Netkey stack(not KLIPS)

Hi All:

Here is what I am running:
rx1000test:~# uname -a
Linux rx1000test 2.6.8-16-486-rx #1 Wed Mar 15
15:33:23 UTC 2006 i586 GNU/Linux
rx1000test:~# shorewall version
2.2.3
rx1000test:~# ipsec version
Linux Openswan U2.2.0/K2.6.8-16-486-rx (native)

Ok, I've been through the docs for shorewall 2.2.3 and
they have a section on setting up for IPSec but its
using the racoon user space tools, not Openswan. The
section on Openswan assumes the use of the KLIPS stack
rather than the 2.6 kernel's NETKEY stack or internal
stack.

Does anyone know how to setup shorewall for a VPN
using  Openswan and the Netkey stack in kernal 2.6?

Cheers,
John

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
Permalink | Reply | 1 comment |
headers
Arne Bernin | 1 Jun 2006 20:22
Picon

Re: High Availability (HA)

On Thu, 2006-06-01 at 09:31 -0700, Tom Eastep wrote:

> 
> It is my understanding that work on ct_sync has pretty much stopped and the code
> in SVN is against 2.6.10 or thereabouts.

That is true, it seems the project is dead. But with the
netfilter/nflink library it is possible to do session/conntrack syncs
via userspace. There is at least one project that does this called
conntrackd (http://people.netfilter.org/pablo/conntrackd/) which might
fill this gap once it is ready for real usage...

> -Tom

--arne

--

-- 
Arne Bernin <arne <at> alamut.de>

http://www.ucBering.de

-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
Permalink | Reply | 0 comments |
headers
info | 1 Jun 2006 20:46
Picon

AW: Openswan 2.2.0 using the the 2.6 Netkey stack(not KLIPS)


With this links you should find some hints configuring FREESWAN/OPENSWAN

http://www.shorewall.net/VPNBasics.html
http://www.shorewall.net/IPSEC.html
http://www.shorewall.net/IPSEC-2.6.html

I´ve running many tunnels with this and the docu gives answer to all the
questions you should have and more...

-----Ursprüngliche Nachricht-----
Von: shorewall-users-admin <at> lists.sourceforge.net
[mailto:shorewall-users-admin <at> lists.sourceforge.net] Im Auftrag von John
Serink
Gesendet: Donnerstag, 1. Juni 2006 19:42
An: shorewall-users <at> lists.sourceforge.net
Betreff: [Shorewall-users] Openswan 2.2.0 using the the 2.6 Netkey stack(not
KLIPS)

Hi All:

Here is what I am running:
rx1000test:~# uname -a
Linux rx1000test 2.6.8-16-486-rx #1 Wed Mar 15
15:33:23 UTC 2006 i586 GNU/Linux
rx1000test:~# shorewall version
2.2.3
rx1000test:~# ipsec version
Linux Openswan U2.2.0/K2.6.8-16-486-rx (native)

Ok, I've been through the docs for shorewall 2.2.3 and
they have a section on setting up for IPSec but its
using the racoon user space tools, not Openswan. The
section on Openswan assumes the use of the KLIPS stack
rather than the 2.6 kernel's NETKEY stack or internal
stack.

Does anyone know how to setup shorewall for a VPN
using  Openswan and the Netkey stack in kernal 2.6?

Cheers,
John

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Shorewall-users mailing list
Shorewall-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642
Permalink | Reply | 0 comments |
headers
Keith Mitchell | 1 Jun 2006 21:46

RE: Openswan 2.2.0 using the the 2.6 Netkey stack(not KLIPS)

I've found that openswan works most excellently following the
http://www.shorewall.net/IPSEC-2.6.html instructions for the shorewall side (you can ignore the
stuff about racoon and setkey - Openswan handles both for you), and following the OpenSwan instructions
for setting up  then tunnels.  Works like a peach for me.

-----Original Message-----
From: shorewall-users-admin <at> lists.sourceforge.net
[mailto:shorewall-users-admin <at> lists.sourceforge.net] On Behalf Of info <at> kws-netzwerke.de
Sent: Thursday, June 01, 2006 11:46 AM
To: shorewall-users <at> lists.sourceforge.net
Subject: AW: [Shorewall-users] Openswan 2.2.0 using the the 2.6 Netkey stack(not KLIPS)

With this links you should find some hints configuring FREESWAN/OPENSWAN

http://www.shorewall.net/VPNBasics.html
http://www.shorewall.net/IPSEC.html
http://www.shorewall.net/IPSEC-2.6.html

I´ve running many tunnels with this and the docu gives answer to all the questions you should have and more...

-----Ursprüngliche Nachricht-----
Von: shorewall-users-admin <at> lists.sourceforge.net
[mailto:shorewall-users-admin <at> lists.sourceforge.net] Im Auftrag von John Serink
Gesendet: Donnerstag, 1. Juni 2006 19:42
An: shorewall-users <at> lists.sourceforge.net
Betreff: [Shorewall-users] Openswan 2.2.0 using the the 2.6 Netkey stack(not
KLIPS)

Hi All:

Here is what I am running:
rx1000test:~# uname -a
Linux rx1000test 2.6.8-16-486-rx #1 Wed Mar 15
15:33:23 UTC 2006 i586 GNU/Linux
rx1000test:~# shorewall version
2.2.3
rx1000test:~# ipsec version
Linux Openswan U2.2.0/K2.6.8-16-486-rx (native)

Ok, I've been through the docs for shorewall 2.2.3 and they have a section on setting up for IPSec but its
using the racoon user space tools, not Openswan. The section on Openswan assumes the use of the KLIPS stack
rather than the 2.6 kernel's NETKEY stack or internal stack.

Does anyone know how to setup shorewall for a VPN using  Openswan and the Netkey stack in kernal 2.6?

Cheers,
John

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around http://mail.yahoo.com 

-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Shorewall-users mailing list
Shorewall-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642
_______________________________________________
Shorewall-users mailing list
Shorewall-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642
Permalink | Reply | 0 comments |
headers
Keith Mitchell | 1 Jun 2006 21:54

Shorewall and Aliased Interfaces.

I'm currently trying to clean up my shorewall rules as they've gotten so
cluttered I don't know which way is up.

Question:  In the
http://www.shorewall.net/Shorewall_and_Aliased_Interfaces.html document,
there is a delineation between port-forwarding to DNAT'd virtual
interfaces and one-to-one NAT'ing along with different rules handling
for one vs. the other.

Is there any advantage of one methodology over the other for internal
hosts one would want to map distinct Public IP's for a few specific
services on each virtual interface?  From the above document, it seems
that the only real difference is whether the virtual interface setup is
handled by the OS (the DNAT example) or Shorewall (the One-to-One NAT
example).  Am I reading that correctly?

Keith Mitchell
CTO
Productivity Associates, Inc.
5625 Ruffin Rd STE 220
San Diego, CA 92123
858-495-3528 (Direct)
858-495-3540 (Fax) 

-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642
Permalink | Reply | 2 comments |
headers
Jan Mulders | 1 Jun 2006 22:52
Picon

Re: Shorewall and Aliased Interfaces.

I believe that the way it was intended to work, was if you only want a few ports forwarded you use DNAT, but if you want to forward everything and *then* control what ports etc to permit, you use one-on-one and ACCEPT. The advantage of DNAT is you don't need to add one-on-one NAT rules in, or worry about default-accept policies etc, as you're only allowing certain "lanes" of access, compared to opening the whole motorway, and putting up roadblocks.

Think of it as port forwarding (DNAT) versus DMZ'ing (NAT)

DNAT's characteristics:
- works great for simple "I need 3 ports" scenarios
- allows sharing of a single IP amongst multiple servers
- only one rule to add per server/service (DNAT source_ip, dest_ip, port....)
- traffic to the zone in question goes out from the server's actual IP (unless told otherwise)

one-on-one NAT's characteristics:
- works great for more general "I need this server accessable from the Internet" scenarios (think DMZ)
- does not allow sharing of a single IP amongst multiple servers
- rules to add per server (NAT public_ip, private_ip) and per service (ACCEPT source_ip dest_ip, port...)
- traffic to the zone in question goes out from it's NAT'ed IP

Hope this helps you.

Jan

On 01/06/06, Keith Mitchell <keithm <at> paisd.com> wrote:
I'm currently trying to clean up my shorewall rules as they've gotten so
cluttered I don't know which way is up.

Question:  In the
http://www.shorewall.net/Shorewall_and_Aliased_Interfaces.html document,
there is a delineation between port-forwarding to DNAT'd virtual
interfaces and one-to-one NAT'ing along with different rules handling
for one vs. the other.

Is there any advantage of one methodology over the other for internal
hosts one would want to map distinct Public IP's for a few specific
services on each virtual interface?  From the above document, it seems
that the only real difference is whether the virtual interface setup is
handled by the OS (the DNAT example) or Shorewall (the One-to-One NAT
example).  Am I reading that correctly?

Keith Mitchell
CTO
Productivity Associates, Inc.
5625 Ruffin Rd STE 220
San Diego, CA 92123
858-495-3528 (Direct)
858-495-3540 (Fax)


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmdlnk&kid
Permalink | Reply | 0 comments |
headers
Keith Mitchell | 1 Jun 2006 23:33

RE: Shorewall and Aliased Interfaces.

Thanks Jan, that actually helps me greatly!

From: shorewall-users-admin <at> lists.sourceforge.net [mailto:shorewall-users-admin <at> lists.sourceforge.net] On Behalf Of Jan Mulders
Sent: Thursday, June 01, 2006 1:52 PM
To: shorewall-users <at> lists.sourceforge.net
Subject: Re: [Shorewall-users] Shorewall and Aliased Interfaces.

I believe that the way it was intended to work, was if you only want a few ports forwarded you use DNAT, but if you want to forward everything and *then* control what ports etc to permit, you use one-on-one and ACCEPT. The advantage of DNAT is you don't need to add one-on-one NAT rules in, or worry about default-accept policies etc, as you're only allowing certain "lanes" of access, compared to opening the whole motorway, and putting up roadblocks.

Think of it as port forwarding (DNAT) versus DMZ'ing (NAT)

DNAT's characteristics:
- works great for simple "I need 3 ports" scenarios
- allows sharing of a single IP amongst multiple servers
- only one rule to add per server/service (DNAT source_ip, dest_ip, port....)
- traffic to the zone in question goes out from the server's actual IP (unless told otherwise)

one-on-one NAT's characteristics:
- works great for more general "I need this server accessable from the Internet" scenarios (think DMZ)
- does not allow sharing of a single IP amongst multiple servers
- rules to add per server (NAT public_ip, private_ip) and per service (ACCEPT source_ip dest_ip, port...)
- traffic to the zone in question goes out from it's NAT'ed IP

Hope this helps you.

Jan

On 01/06/06, Keith Mitchell <keithm <at> paisd.com> wrote:

I'm currently trying to clean up my shorewall rules as they've gotten so
cluttered I don't know which way is up.

Question:  In the
http://www.shorewall.net/Shorewall_and_Aliased_Interfaces.html document,
there is a delineation between port-forwarding to DNAT'd virtual
interfaces and one-to-one NAT'ing along with different rules handling
for one vs. the other.

Is there any advantage of one methodology over the other for internal
hosts one would want to map distinct Public IP's for a few specific
services on each virtual interface?  From the above document, it seems
that the only real difference is whether the virtual interface setup is
handled by the OS (the DNAT example) or Shorewall (the One-to-One NAT
example).  Am I reading that correctly?

Keith Mitchell
CTO
Productivity Associates, Inc.
5625 Ruffin Rd STE 220
San Diego, CA 92123
858-495-3528 (Direct)
858-495-3540 (Fax)


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmdlnk&kid

Permalink | Reply | 1 comment |
headers
Tom Eastep | 2 Jun 2006 01:30
Favicon

Re: Shorewall and Aliased Interfaces.

Keith Mitchell wrote:
> From the above document, it seems
> that the only real difference is whether the virtual interface setup is
> handled by the OS (the DNAT example) or Shorewall (the One-to-One NAT
> example).  Am I reading that correctly?

One clarification in addition to what Jan has posted -- virtual interface setup
is always handled by user space utilities. In the One-to-one NAT case, Shorewall
can run the utility -- in the DNAT case, you must rely on your distribution's
networking startup scripts to run the utility.

-Tom
--

-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep <at> shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key
Permalink | Reply | 0 comments |

Gmane