Site-tosite, pfSense on 3G modem(NATed by carrier) to a normal WAN address
I have a problem.
Testing pfSense 2.1.4 site-to-site with IPSEC over 3G.
All testing is done @ home.
Two pfSense installations: One with a pure all-open WAN IP-address(the home), and one behind(the remote) a NAT:ed address by the 3G carrier.
What I'm after:
Remote side connects to home as soon as something at the remote site want's to reach my home network.
My home should not do any connecting to the remote site(due to the NAT by the carrier).
So bi-directional connection possibility's are not need, only one site does the connecting, and then the data can flow in both directions, basically E.T phone home.
pfSense @ home won't let the remote site connect(I get a racoon: [188.8.131.52] ERROR: exchange Identity Protection not allowed in any applicable rmconf.), unless….
If I add the IP-address that is showing up in the logs @ the home site to the "Remote gateway" field @ the home site.
The Negotiation mode is "main" @ both sites. I even tried "aggressive".
The problem is that the remote site changes WAN IP-address every time it connects(due to connection problems etc.) to the Internet, and pfSense only see's the carriers internal IP-address.
I tried manually changing "My identifier" from "My IP address" to a 172.x.x.x IP-address that I made up, but no go :(.
Is this a limitation in the IPSEC protocol?
Or have I setup something wrong?
I even checked pfSense The definitive guide, the one that came out late 2009, but no go.
Getting a static address or a non-nat:ed IP-address on the 3G connection is sorry to say, not an option :(.
The issue here seems that you have no static iP on the 3G end.
Your best bet here would be to set up dynDNS or similar on the 3G end and connect to that vs using the IP. IPSEC doesn't work well with changing (dynamic) IPs.
Also you may want to check if your carrier provides non-NAT addresses – most do, but you have to use a different APN to the one you'd normally use.
Thanks breakaway for your reply.
It looks like you are correct.
The problem seems to be that racoon does not accept wildcards(ran racoon with verbose and debug in a terminal) regarding incoming connections when matching with the PSK(running PSK during tests).
There is a simple patch for allowing wildcards, but once I compile it, it won't start on pfSense due to something missing.
It looks like I will need to get a older FreeBSD that matches pfSense 2.1.4 and try to compile on that.