Right after I posted yesterday I thought I would try using the same PSKs, so far they have both stayed up for about 18 hours, so it is looking like that fixed it. Thanks!

Unfortunately, FreeBSD (and thus pfSense) can't combine NAT and IPsec (yet?).

Gave up on trying to do this. Instead created tunnel interfaces on the ciscos and am letting MPLS failover to GRE tunnels. Working surprising well. Doing port forwarding for GRE for the IP of hte router. Wanted to keep all the router IPs behind the firewall.

Gah, thanks for the clue-bat!

In order for a VPN router like that to work, it would either need to be the gateway for all of the systems behind it, or you'd need a static route to your remote VPN client subnet on every server (or their gateway) that would point traffic at the VPN router.

So it could work, but it takes a bit more effort to get it going.

@dapriv:

You can't just add a static route to the router?

Nope.  This is a colo setup, so no, we don't have access to the router.  Just another line to stash in our default rc.conf…

@egarcia:

I'm trying to replace actual TZ170 with pfSense appliance.
Actually I have a IPSec tunnel between offices using two TZ170 firewalls.

I did something similar, and it was actually the easyest ipsec I ever setup.
(but, funny thing, and I'll post later on this) as soon as I ENABLE IPSEC on the pfsense, the access from the LAN to the BRIDGED DMZ stops, completely.

Sure you can. You'd just need a static route on the OpenVPN router that directs traffic for the IPsec subnets at the IPsec router, and a static route on the IPsec router that points traffic for the OpenVPN subnet back at the OpenVPN router.

Not sure why that might be. Does it go up if you increase the timeout?

The timeout may just be a 'maximum' and rekeying earlier is actually better (more secure) than letting the keys fully expire.

We don't set a data timeout or I'd suspect it might be triggering another limit.

What shows up in the logs when it expires?

no, personally i don't think you have to worry, it's just like saying i hang my stuff 30 feet high so no one could reach it (under normal circumstances, before someone tells me, yes, but if..) and then saying it would be more secure to hang it 35 feet high.

openvpn has no flaws like lets say pptp with it´s weak password hashing or poor encryption keys..

to me it would be fine if everybody (universities, big networking companies, OS-Providers, etc..) would do SSL-VPN's as their standards, but unfortunately they don't. i.e. of iPhones which don't support installing third party devices (tun, tap) you don't have much choice, or if you have to connecting to third-party-vendor-stuff…

it depends, on implementation (i heard, IPSec with NAT-T is too not an ace either), on technology being used, on the usecase, on so many things.. but i'm glad that pfsense does them all.

Hi jimp,

Yup I fully understand :)

What I'm trying to prevent, is that compramised remote endpoint gaining access to some of my hosts that only other IPSEC tunnels have access to. It boils down to the fact that IPSEC is firewalled by one interface, and all filtering is done by IP. But if you say that it's impossible to pass traffic for a different subnet than a tunnel is configured for, unless both end agree to it, I guess this is safe enough (As my box would need compramised as well).

Thanks

It depends on how sensitive the transfer type is to failure, and how long the renegotiation takes.

If it's a quick renegotiation, and it drops a couple TCP packets, it should pick back up.

I don't think there is a fix for this in 1.2.x

In 2.0 it's a moot point since you can have multiple phase 2 networks in a single tunnel so they'd have the same name anyhow.

Sorry about the lack of ipsec logs, but IPsec seems to be fine now and I'm nowhere near the computers in question.

I've made some progress with this on other computers, but I haven't got it to work yet.  I followed the tutorial in http://www.pfsense.org/mirror.php?section=tutorials/mobile_ipsec/ on two fresh installs of pfsense and two systemrescuecds running as clients.  I've got a VPN tunnel (SAs, SADs and SPDs OK) established between the two pfsenses, but the traffic can only go from the dynamic site to the static site and not in reverse.

If I ping the static client from the dynamic client, I can see the ping echo requests arriving on the static client (tcpdump icmp), and I can see it trying to send replies.  I've set logging on the both firewalls, and I can see the ping reply arriving on the LAN interface of the static pfsense – but nothing is getting back to the dynamic client.  Pinging from the static client goes nowhere.

Also, when the static side times out the VPN connection, it refuses to allow the dynamic side to reestablish it (without me rebooting it).  The dynamic side says 'none message must be encrypted' in the ipsec.log.

Sorry for changing the subject, but it seems to be closer to a working solution.

@jimp:

That isn't a bug. The time zone will never take full effect system-wide until you reboot.

No problem jimp

Cheers

Hi Jimp,

i got it to work with Pfsense 1.2.3. After some debugging we corrected Phase 2 remote network settings.

Tunnel is up and working like a charm.

cya

:CLOSED