IOS 6 - DEBUG: no remote configuration found.
I'm attempting setup a testing environment for PFSense 2.0.2 on my local VMware ESXi Server to evaluate its suitability as a IPSec VPN Server for IOS devices out in the field. The basic setup is as follows.
WAN Interface is tied to a real network card on my local 192.168.1.0/24 sub-net.
LAN Interface is tied to a virtual network card on a virtual switch assigned to several Windows based VMs.
LAN sub-net is 172.20.1.0/24 with DCHP disabled.
Appropriate gateway is assigned to the WAN Interface and the LAN side VMs are able to access the internet through PFSense.
IPSec Mobile was setup with the following guide http://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0.
iPad is on the same network as the WAN and can successfully connect and acquire an IP address from the virtual pool on the mobile client setup tab.
Virtual Pool IP address is on a different sub-net than the LAN and an appropriate allow any to any firewall rule has been setup under the IPSec tab of the firewall configuration.
Clients on the LAN sub-net cannot ping the IPSec sub-net and the iPad cannot ping the LAN sub-net.
I have verified from the firewall logs that ICMP packets are not being blocked by the firewall.
I have tried with nat-t disabled, enabled and forced.
After enabling debug for racoon I see the following errors but not other errors.
racoon: [192.168.1.38] DEBUG: no remote configuration found.
racoon: ERROR: no configuration found for 192.168.1.38.
racoon: ERROR: failed to begin ipsec sa negotication.
Research on this forums shows multiple posts with this error and no solution. Is this a bug?
I wanted to come back and let everyone know I figured out the problem though I'm still not exactly sure why it caused everything to behave the way it did. It seems that if your trying to connect to the VPN from the same sub-net as the WAN then the WAN can't have a default gateway assigned to it. I would have assumed that since the WAN was on the same sub net as the device that it wouldn't try to send the return traffic through the WAN's gateway but it appears to be doing just that.
If you are in the same subnet, the WAN rules have reply-to on them which sends the data back via the gateway. That breaks what you're trying to do.
You can disable reply-to in the advanced options on the firewall/NAT tab.