@cmb:

If the described route is there, it should go out the tunnel as that'll determine its source IP selection. I don't recall anything with DHCP relay that's any different.

The ICMP redirect you're describing would not happen with the described route. It does cause an ICMP redirect to be sent, but it's one that tells the client "to reach the remote IPsec network, hit my LAN IP", which is what they're doing anyway so it effectively does nothing. You can disable the ICMP redirects under System>Advanced, Tuning, if you don't need or want them in general. But that description makes it sound like the route wasn't right to begin with.

Yeah, it did seem weird to me, so I checked it several times, and had a colleague check it for me as well just in case someone spiked something I drank, but the route was fine and that's the redirect the host got. In either case, installing the FreeBSD package mentioned in this post it worked without the route. The only difference I see between the two of them network wise is that the "unofficial" relay binds to a specific address as well as the interface, while the included daemon binds to * on the selected interface.

When checked, the server takes the list of networks on the mobile Phase 2 and sends them to the client as a "net list" or "split network" list, so that only the networks provided will be sent across the tunnel and others go to the Internet directly, rather than tunneling everything.

It's up to the client to obey that setting. Some don't support it at all and always require a manual list, others respect it, others ignore it on purpose and send everything no matter what you do.

OK, it looks like the problem was with the COX router.  We where getting routed to a level 3 network that, was throttling our traffic.  The new path is still throttling our traffic but at only at ~20, which is enough to do our replication in about 8 to 10 hours, which meets our business requirement.  It would be nice if we could get the full 50, but it's not as high a priority now.

That e-mail about the service level guarantees got the ball rolling again.  Thanks for the help.


Just to let you know…

after tinkering with rules and testing, I just came up with this:

One rule, Lan to IPSec Subnet in the LAN tab.
The other rule, any to any in the IPSec tab.

and I just got the DHCP ip helper address working...so I'm using my DHCP server. :D.

First guess, wrong subnet mask on the affected hosts (/16 instead of /24, so it thinks the remote network is local).

The general purpose network availability monitoring system you use to monitor servers, switches, routers, firewalls, etc. A ping to the remote end would suffice.

Hi Mykey,

Did you connect pfsense 2 your ISP using L2TP?

On my (retired, now openVPN) IPsec tunnels I had:

My identifier: My IP address
Peer identifier: Peer IP address

…and some higher encryption as the main difference to your setup for phase 1, on first glance

THIS thread also has problems with IPSec and CARP. Likely the issue is related.

That seems like a routing issue. The IPsec tunnel will probably not know where the 10.0.0.0/8 network is, and so it can't send any traffic there.
You will probably need to add another phase 2 setting to propagate 10.0.0.0/8

Check your settings again. The ZyWall and the pfSense are compatible, I have a tunnel working.

Anything I could try?

I have never been able to get a successful ipsec connection, but openVPN is working.

It doesn't.

Thank you
this noted for the future use !

I solved.

I'm not sure that is this the problem but now is working.

Change the My identifier with CARP IP.