Hello iamzam,

thanks for your reply. I've added the rule to allow AH but it also didn't work.

…and with that response, I honestly figured it out.  Sheesh!  Why didn't I remember to allow UDP across my tunnel?  DNS works fine now.  Thanks!

Follow up:
When debugging and redacting previous post I've disabled a second IPSec tunnel (one for point-to-point VPN, not mobile clients) and now mobile client access seems to work just fine (using Shrew Soft VPN Connect software and builtin iOS client).
("Unknown Gateway/Dynamic" log message is still there though)

I'll look into the settings of this second tunnel later (time to confirm that at least everything is OK with one tunnel).

@kapara:

Been doing some research on AESNI and it looks like even using a corei5 proc can provide significant improvement.  Anyone test AESNI on pfsense yet?

Yes, don't bother.  AES-NI makes no difference at this point, though I wouldn't buy a CPU without it as better support is in the pipeline.

I would suggest checking that you have correctly specified the Search Scope and Base Containers properly.

PM me if you still have troubles - I have the Microsoft AD part of IPSec working, but now I'm getting asymmetric routing I suspect. :(

Aye, that may be. We've got a heavily virtual environment so for us its zero marginal cost to spin up another VM for that purpose. Though I am intrigued by OpenVPN. That it can export a setup executable is really cool. I might just go with that instead.

Other thoughts?

If you want to be sure that command changed attributes correctly:

-rw-r–r--  1 root  wheel  schg 193 Aug  1 09:20 filename

After, if you need to change it again, it will be sufficient to remove protection attributes with:

Do both of your WAN interfaces have the same gateway, perhaps?

I am having the same problem with this, it will not re-establish from CISCO side, no problem from pfsense to CISCO site

I lately had repeated problems with IPsec tunnel (well doing over months), that after the provider did some "service" the tunnel was not functional (no ping, no data passing) for some hours, although the tunnel was successfully established according to racoon protocolls on BOTH sides.

Strange, strange, maybe NSA had no capacity to handle more man-in-the-middle? :)

I've put accept on all interfaces and log, but no logging of drooped or accepted udp packets.

At closer look to the UDP packets I could see that the frame header has the 802.1Q part with VLANID 0.
The old router accepted this packets, but not pfsense.

I'm honestly surprised that they can block OpenVPN. We have ours setup so it tries UDP on a weird port –- If that doesn't work it will revert to TCP port 443 so it is very difficult to distinguish from HTTPS.

Even if you can't make a tunnel with SSH, I'm sure you can make an SSH tunnel back to a server that can handle SSH tunnels. Honestly we stopped handling OpenVPN on PFSense due to everyone being disconnected when the firewall fails over.

@craggy:

I've tried everything I can think of but no way can I get this to work.
no matter what I do I cant get a second phase 2 to come up when it uses a subnet that doesn't directly exist on a wan or lan interface.

is this a bug in pfsense 2.1 or am I doing something stupid?

please can someone help, I really need to get this working.

Another way to do this would be to use a larger subnet on the first Phase 1 of the WAN.

I.E.

You have 3 networks:

192.168.100.0/24 A
192.168.101.0/24 B
192.168.102.0/24 C

So when you setup the phase 2 for A to B, on the B side you set the remote WAN to 192.168.0.0/16

Worked perfectly!
A thousand thanks for your help!

Kind regards
Beach

First of all turn OFF the Windows firewall, then test something.

Hmm, that looks like a fairly dead end…

Well, i'll have to go with openVPN then.

Thanks.