It is possible.  Apart from the problem I reported with the wrong addresses in 
the IPsec-related rules, the rules look fine.  I have used CARP and binat 
rules in a similar way on OpenBSD without problems, so I doubt that it is a 
pf problem.   

I have a /29 and the current allocations for public IPs are as follows:

x.x.x.233               Router leading to Internet
x.x.x.234               FW1 real IP address
x.x.x.235               FW2 real IP address
x.x.x.236               CARP-FW address
x.x.x.237               CARP-SRV1       NAT 1:1 to LAN 192.168.10.1
x.x.x.238               CARP-SRV2       NAT 1:1 to LAN 192.168.10.11

There are 3 local interfaces, each of which has a CARP IP which is the default 
route for hosts on the appropriate network - so 6 CARP IPs in total.

Unfortunately, the kit is in a datacentre in London (120 miles away) and the 
FW1 (CARP Master) is now in a crash/reboot/crash cycle.  This is a CARP 
related problem as FW1 will start and run stable if FW2 is not online when it 
starts up.  As I can no longer see both systems running simultaneously I will 
have to wait until I get back to the datacenter to debug further.

Only  debug clue I have is that I have log entries for a bad hash on carp5 
coming up on a regular basis.  Also, when I looked at the Status | CARP 
screen when both systems where last running the info for carp5 was not 
displaying correctly.  (From memory there was no status and the interface 
name was missing).

Sorry to be vague - I hope to be back in London next Wednesday and will try 
and collect some proper information then.  I am not sure if this is a pfSense 
problem or just a dumb configuration mistake by me.  Either way, it would be 
good to figure out what is going wrong, if only for the FAQ.

/Peter
On Sunday 19 March 2006 17:47, Scott Ullrich wrote:
> I am running failover ipsec at home and work with no issues.  I am
> using a public IP as one of the carp ips but I am not running a 1:1.
>  I almost wonder if the 1:1 is stepping on the IPSEC connection.
>
> On 3/19/06, Peter Curran <[EMAIL PROTECTED]> wrote:
> > Scott
> >
> > Let me explain the chain of events...
> >
> > I set up two pfsense boxes as a high-availability pair.  They have a
> > number of CARP addresses configured, the ones on the WAN are mostly
> > passed through to the LAN via 1:1 NAT.  One single address is used for
> > the logical firewall itself CARP-FW.
> >
> > I tried to setup an IPsec tunnel from a remote box to the LAN network
> > using the CARP-FW address as the tunnel end-point address.  I then set
> > this in the Failover IPsec dialog (along with the LAN address of the
> > peer).  I saved this config, but the tunnel failed to come up - Phase 1
> > not completed.
> >
> > I then decided to just setup a tunnel to the real WAN address of one of
> > the firewalls and test this worked OK, then try the CARP approach again. 
> > To do this I disabled the Failover IPsec settings via the tickbox and
> > reconfigured the tunnel endpoint address on both systems.  No luck with
> > this config so I checked the firewall logs, and sure enough incoming
> > UDP/500 packets are being rejected between the tunnel endpoints.  I then
> > used status.php to look at the firewall config 'in the raw' and saw that
> > the rules are like this...
> >
> > pass out quick on em3 proto udp from x.x.x.235 to y.y.y.153 port = 500
> > keep state label "IPSEC: Close Consultants - outbound isakmp"
> > pass in quick on em3 proto udp from y.y.y.153 to x.x.x.235 port = 500
> > keep state label "IPSEC: Close Consultants - inbound isakmp"
> > pass out quick on em3 proto esp from x.x.x.235 to y.y.y.153 keep state
> > label "IPSEC: Close Consultants - outbound esp proto"
> > pass in quick on em3 proto esp from y.y.y.153 to x.x.x.235 keep state
> > label "IPSEC: Close Consultants - inbound esp proto"
> > pass out quick on em3 proto ah from x.x.x.235 to y.y.y.153 keep state
> > label "IPSEC: Close Consultants - outbound ah proto"
> > pass in quick on em3 proto ah from y.y.y.153 to x.x.x.235 keep state
> > label "IPSEC: Close Consultants - inbound ah proto"
> >
> > The x.x.x.235 address is the CARP-FW address (supposedly disabled) not
> > the real FW address.
> >
> > I zeroed all the Failover IPsec boxes and saved the config, the tunnel
> > came up immediately and the firewall rules are just fine.
> >
> > This is BETA-2.
> >
> > Incidentally, this is only one of a small plagure of problems with CARP -
> > I am trying to reproduce some of the problens know so I can document them
> > correctly.
> >
> > Cheers
> >
> > /Peter
> >
> > On Saturday 18 March 2006 18:02, Scott Ullrich wrote:
> > > Not sure what you mean.  Can you show me an example of the rule?
> > >
> > > On 3/18/06, Peter Curran <[EMAIL PROTECTED]> wrote:
> > > > The firewall rules to manage IPsec are being based on the (CARP)
> > > > address entered in the Failover IPsec dialog irrespective of the
> > > > setting of the Enable checkbox in the Failover IPsec dialog.
> > > >
> > > > The only way to stop it doing this has been to remove all the
> > > > entries.
> > > >
> > > > /Peter
> > > >
> > > > --
> > > > This message has been scanned for viruses and
> > > > dangerous content by MailScanner, and is
> > > > believed to be clean.
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to