Hi Zach.
Ah great news!
I noticed your email before the weekend but didn't have a chance to
reply. Please you worked it out.
The remote network routes I use don't point at the local inside CARP IP
but instead at the local inside physical IP (each firewalls own IP just
to set the source).
> Hope this helps,
Thanks, Andy. Once I removed the routes for the remote network point to
the internal carp interface, everything works like I expect. Super
stable. Thanks for your time. I'll mess with the NAT for monitoring
soonish and see if I can get that working.
--
Zach
> 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.
>
> To fix that I added a NAT rule, and could then
On Fri, Mar 07, 2014 at 04:35:45PM +, Andy wrote:
> Hi
>
> On Thu 06 Mar 2014 23:03:58 GMT, Zach Leslie wrote:
> >On Thu, Mar 06, 2014 at 08:16:34PM +, Andy Lemin wrote:
> >>Hi, haven't read your original email but if my assumptions about your setup
> >>are correct is the VPN tunnel dropp
Hi
On Thu 06 Mar 2014 23:03:58 GMT, Zach Leslie wrote:
On Thu, Mar 06, 2014 at 08:16:34PM +, 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, ne
On Thu, Mar 06, 2014 at 08:16:34PM +, 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 j
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?
I had a similar issue with 4 OBSD firewalls (2 at each end), all running
isakmpd and sasyncd to keep the SAs in sync between a pair. With the tunnels
explicitly
On Wed, Mar 05, 2014 at 11:05:11PM -0600, Amit Kulkarni wrote:
> > If PF information is needed, I can provide and obscure, but I didn't
> > expect it to be
> > the issue.
> >
>
> i am no expert on this. but if it is a packet loss issue, you need to post
> the obscured pf.conf
Fair point. I've no
> OpenBSD 5.4 GENERIC#37 amd64
I've just booted the MP kernel on all four systems just to test and I am
still seeing the behaviour. I can prompt the packet loss by generating
load on the CPU. Running Puppet on the machines drives up the CPU usage
considerably, at which point my remote session ha
9 matches
Mail list logo
