On Fri, Mar 07, 2014 at 04:35:45PM +0000, Andy wrote:
> Hi
>
> On Thu 06 Mar 2014 23:03:58 GMT, Zach Leslie wrote:
> >On Thu, Mar 06, 2014 at 08:16:34PM +0000, Andy Lemin wrote:
> >>Hi, haven't read your original email but if my assumptions about your setup
> >>are correct is the VPN tunnel dropping every now and then?
> >
> >Thats correct. Daemons start up quick, negotiations happen, and then
> >periodically the tunnel is just not available, despite the SAs being
> >available on the masters and the slaves. Disabling -S on isakmpd and
> >turning off sasyncd makes the tunnel stay up for much longer, 7 hours
> >and counting.
> >
> >>You need the static route to point to the internal interface to make sure
> >>that packets generated by the firewall itself have a source IP set to the
> >>internal net thus allowing the IPSec policy route to be used (as it defines
> >>both the source and dest net, not just the dest net like a normal route).
> >
> >This I have, and packets flow. Still unclear about which route takes
> >precedence, encap or inet.
> >
>
> encap (I tried to add a route for the remote net on the firewall pointing to
> the internal switch, which would bounce the packet back to the CARP IP, thus
> getting packets from the backup to the master and over the VPN. But it
> doesn't work, the encap route is used first and so the tunnel drops).
I suppose I should be more explicit. For packets generated by the host,
it seems to use the inet routing table. Perhaps thats because the
source IP is not in the flow.
> >>We had to modify all our monitoring scripts to not 'phone home' if the box
> >>is a backup. Only the master firewall can use the VPN.
> >
> >I've ended up monitoring the host using internal interface, which in
> >turn tells me the tunnel is available.
>
> I had to disable monitoring of the internal interfaces of both remote
> firewalls, as it killed the VPN when you ping'ed the backup firewall. The
> packets get there, but the reply is sent back directly from the backup and
> not via the master.
What do you mean killed the VPN? As in you saw packet loss, or the
tunnel went down completely, or just that those packets did not return.
> To fix that I added a NAT rule, and could then monitor and connect to the
> internal interfaces of both remote firewalls again..
> (These pf.conf examples and files below are from our remote office
> firewalls. carp0 = external, carp1 = internal);
> match out on $if_lan from { $hq_lan } to ($if_lan:network) nat-to (carp1)
>
> pass in quick on enc0 proto ipencap from { $ext_ip_hqfw } to { (carp0) }
> keep state (if-bound)
> pass in quick on enc0 from { $hq_lan } to { $if_lan:network } keep state
> (if-bound)
>
> pass quick on $if_lan from { $hq_lan, (carp1) } to { $if_lan:network } queue
> (_wan_vpn,_wan_pri) set prio (2,5)
I've not implemented this NAT yet, simply because the packets in my case
do get returned. I have a route on both firewalls to the remote network
to point at the carp address shared between them. Though your mention
of the VPN going down sounds familiar.
> PS; Also don't forget to restrict the MTU of VPN traffic so it doesn't
> fragment (needed on both sides naturally);
> match in on $if_lan proto { tcp, udp, icmp } from { $if_lan:network } to {
> $hq_lan } scrub (no-df max-mss 1400)
> set skip on $if_pfsync
I'll add this shortly and test.
> Yea they sort the startup, shutdown and also ensure a prompt the failover. I
> wrote them during 5.2 so may not be so important but they add a level of
> failsafe otherwise.
> Keeping the tunnel up should simply be a case of making sure the backup
> *never* sends encaped packets itself..
Committing them to source seems reasonable if they are an improvement on
what is there.
> /etc/sasyncd.conf
> peer 192.168.30.253 <- The other IP on the PFSYNC interface (cable directly
> connected between firewalls)
> interface carp0
> group carp
> listen on 192.168.30.252 inet port 500 <- This PFSYNC IP etc..
> sharedkey 0x<long-hash>
> flushmode startup
> control isakmpd
My sasyncd.conf looks different, so I'm going to try some of this now.
Enabling sasyncd and adding -S to the isamkpd causes serious instability
right now. Disabling it makes everything stable again, so I'm hoping
its just a configuration issue. So this means that you have PFsync and
sasyncd going over the same directly attached interfaces, correct?
I'll report back when I've implemented the changes.
Thanks for the advice.
--
Zach
