Ping in one direction between hosts fails to open a tunnel

Ignatius

I'd like to implement an IPSec VPN between two pfSense installations, each behind a Draytek 2820 router. In anticipation of doing it for real, I've set up two VMs using VirtualBox to aid my learning process.

The pfSense installations are the most recent (2.0.2). The "Main Office" LAN is 192.168.3.0 / 24 and the "Remote Office" LAN is 192.168.4.0 / 24 so the respective LAN interfaces of the pfSense boxes are .1. I have an XP VM (192.168.3.2 / 24) and an Ubuntu VM (192.168.4.2 / 24). The WAN interfaces are 69.46.80.101 / 24 and 69.46.80.102 / 24.

I have configured the IPSec and can ping between the hosts, however if I ping initially from the Ubuntu (192.168.4.2), the tunnel comes up immediately and responses are seen from the XP (192.168.3.2) but if I close down the terminals then start the ping from the XP side, it may start or it may not (Request timed out). If I start it soon after successful pings between the two systems, it usually starts immediately but if I leave it for several minutes, the tunnel just won't come up when pinged from the 192.168.3.0 side. As soon as I start the ping from the 192.168.4.0 side, there are responses from both sides. It's as if the tunnel times out and can be opened only by traffic from the 192.168.4.0 side.

When I configured the VPN, in phase 2, I set the timeout to be 3600 seconds on both sides and set it to automatically ping the host at the other end of the tunnel so surely the tunnel should remain open?

I hope I've explained the situation sufficiently. Can anyone suggest what I am doing wrong? As I said, this is a "dry run" for when I do it for real.

Thanks for your time (and patience!).

jonallport

What do you have on your Phase1 proposal checking? If it's 'default' or 'strict' try changing it to 'obey'.

From man racoon.conf(5):

proposal_check level
specifies the action of lifetime length and PFS of the phase 2 selection on the responder side. The default level is strict If the level is;

obey
the responder will obey the initiator anytime.
strict
If the responder's length is longer than the initiator's one, the responder uses the initiator's one. Otherwise it rejects the proposal. If PFS is not required by the responder, the responder will obey the proposal. If PFS is required by both sides and if the responder's group is not equal to the initiator's one, then the responder will reject the proposal.
claim
If the responder's length is longer than the initiator's one, the responder will use the initiator's one. If the responder's length is shorter than the initiator's one, the responder uses its own length AND sends a RESPONDER-LIFETIME notify message to an initiator in the case of lifetime. About PFS, this directive is same as strict
exact
If the initiator's length is not equal to the responder's one, the responder will reject the proposal. If PFS is required by both sides and if the responder's group is not equal to the initiator's one, then the responder will reject the proposal.

The way I interpreted this for my troubleshooting was that if 'default/strict' are in force and the remote end reboots, the local end will ignore then incoming IKE until it own key lifetime expires. Whether that's right or not, it worked for me and the Cisco ASA I was having as spat with!