@hessie:

I wonder that there is so little interested for that.

I think there's a lot of interest in NAT VPN but those of us who are interested don't bother posting. We look to see if it is supported and if not we call up and order a router that has it. "natip" as Fortinet uses it is an essential feature for getting into big installations where conforming is not an option. I have no chance of dictating policy to large companies.

Fortinet Outbound NAT examples

Just tried this but it wouldn't work for me, just as if the tunnel was ignored. Anyelse tried this?

Thanks for your answers!

Renumbering the client networks is virtually impossible since we'd like the mobile users to be able to connect from anywhere so you never know what subnet you'll encounter.

Renumbering our own subnet is also tricky because we're in an Active Directory with six sites and a load of servers (Exchange, DC, fileservers, cvs servers, webservers, etc.). So while it's not impossible it will most likely be quite a feat to renumber our own network. It grew so historically and I inherited it from my predecessor.

Still I think changing our own subnet is the most sensible thing to do. Thanks for your input.

Perhaps too late, but I'll post it here anyway.

You need to allow these things in your firewall:

UDP port 500 for IPSec

protocol ESP (or AH if set that way)

UDP port 4500 for NAT-T

Worked perfect! Followed the tutorial and all was up working. Thank you wery much for you work.

I have tried wireless and from remote to mine with rc1 no issues here.  Just make sure you have all the patches loaded.

I am running 1.2.3.

RC

With Mobile IPSec, you generally hardcode a client's IP address in the client configuration, so you'll have some idea of which one is which.

If you have the Dashboard package installed, I've fixed it so the IPSec status widget properly shows the status of mobile clients which are connected. It will list the peer IP address as well as the VPN IP address for the client. Unfortunately, as far as I can tell there is no way to see which client is which based on the identifier. I'd really like the ability to match them up that way as well.

I'd say you should check out OpenVPN, but I don't think that it has a means of getting that sort of information either, at least on 1.2.x.

Ouch!!!!

@Phil:

Solved… See http://forum.pfsense.org/index.php/board,16.0.html

I have exactly the same problem as you described, but the link you posted does not work.

Can you tell me how you solved your problem?

\Ronni

@jimp:

Multiple subnets w/IPSec are possible in 1.2.x in a non-obvious way, and there are some issues, but you can try it to see if it works for you:

http://doc.pfsense.org/index.php/IPSec_with_Multiple_Subnets

It didn't work for me, but I think that was mainly due to the fact that I was using a mobile tunnel and not a static site-to-site tunnel. The parts of my VPN that needed multiple subnets got moved to an OpenVPN tunnel and have been working happily ever since.

Parallel tunnels works.  You have to make sure ALL settings (except the network) are exactly the same, but it works.  I have this between pfSense <-> pfSense and pfSense <-> Cisco.

Roy

@jimp:

A little late, but better late than never:

Yup!

I read over it briefly. It looks good to me. It's been a while since I set it up from scratch and maybe some things have changed since 1.2.2 but everything seems to be there.

Thanks for updating.

hmmm … i'd think that the problem is, that mobile IPSec clients behind a NAT router can't conntect to your pfsense IPSec Endpoint (which should be connected direct to the internet - no NAT)!

I simply can't believe it !  ??? ??? ??? This morning, without changing anything, the tunnel is up ! ??? ??? ??? Is it necessary to wait before the tunnel get up ? How many time ?

Anyway, this looks like a good news. I will continue my exploration. Thanks for your help !  ;D ;D ;D

Someone had posted a bounty for NAT over IPSec, the post is still there in the Bounty Forum on this site. I'm not sure this actually has a distinct name, but some people call it "NAT over IPSec", "Policy NAT for IPSec", etc. This functionality does not currently exist in pfSense, though with enough interest (and perhaps bounty money) it could be added.

Basically what you need to do is NAT before the traffic enters the tunnel, and/or after it leaves, like so:

Site A: 192.168.1.x <1:1 NAT> 10.0.1.x <–- IPSec ---> 10.0.2.x <1:1 NAT> 192.168.1.x :Site B

Site B uses the 10.0.1.x addresses to talk to Site A, and Site A uses the 10.0.2.x addresses to talk to site B. It will appear to each side and though the other end does not, in fact, share its same subnet.

If only one-way communications will be initiated, you only need to do NAT on the far side, so when you try to talk to the address your system will know to send it to the tunnel and not try to reach it locally.

Some have had success with bridging networks via OpenVPN, so both sides can have addresses in the same subnet, but I believe in that case they still can't conflict, just use separate areas of the same larger subnet. Someone else more familiar with this OpenVPN tactic may be of greater help in this area.

Tried the suggestion and modified the vpn.inc file but it still is unable to bring the tunnel back up.