You should be able to do this on a Cisco router, I've done it on ASAs.
Quick google turns up this, which may help:
http://www.cisco.com/c/en/us/support/docs/routers/3800-series-integrated-services-routers/107992-IOSRouter-overlapping.html

Just when you think there's no options left you solve it on your own ;-)

I ended up setting up another pfSense just for IPSec and 1:1 NAT all ports/protocols for IPSec from the primary pfSense to it. I added a second network interface with an IP in the 100.72.13.160/29 subnet to the new pfSense vm and created the IPSec connection like I did before.

We then set up another database VM with its primary network interface also in that subnet and the IP of the new pfSense as gateway. Everything was working as expected from then.

I ended up having a lot of TCP:RA drops and blocks from another remote location connected via OpenVPN on another VM (but in the same VLAN) which was solved by setting the firewall mode to conservative.

Any idea why that is needed?

It turned out that the internet connection I use from home already employs IPSec/L2TP to create a tunnel via die wireless services the ISP uses, so instead of figuring out which PMTU, icmp and MTU and whatever else to use, the tunnel was simple established from my Mikrotik router instead of from my laptop, which works 100%.

If I'm on the road then the tunnel from my laptop works fine.

I was considering that but really don't want to go back. In addition, it's a Hyper-V VM which 2.2 works well on. I remember on a previous build of pfsense I had to use "prefer older SAs" Somewhat stumped at this point as the logs just don't show any pertinent errors. Tunnels marked as up. Weird.

@itm_2015:

What´s about: "Removing interfaces_use from strongswan.conf makes the problem go away."?

I had the same problem. Whenever the WAN link got disconnected/reconnected the VPN tunnels did not reconnected.
Removing the 'interface_use' indeed fixed the problem.
To remove this key from strongswan.conf I edited /etc/inc/vpn.inc around line 370 there is this:

{$accept_unencrypted}
cisco_unity = {$unity_enabled}
{$ifacesuse}

I changed this to:

{$accept_unencrypted}
cisco_unity = {$unity_enabled}

{$ifacesuse}

I also edited the file /var/etc/ipsec/strongswan.conf and commented out the 'interface_use' line.  (gets overwritten when WAN is disconncted).

This is a hack that worked for me, I have no experience in linux/freebsd and don't know if it has any side effect. Alternative is go back to old version or wait for 2.2.1 update.

Lex

I Solved the problem. I just created a routing entry under Routes

/System/Routing/ then Routes Tab

Create a new Route and insert the IPsec Mobile Clients IP subnet and then chose the WAN2 gateway address.

Now my remote users can connect over Wan2

example:
Destination Network:      10.0.10.0/24
Gateway:                      Wan2 198.34.55.21
Description                    IPsec Mobile Clients

You normally have assigned the GRE interface so for sure you need rules for that!

@jvangent100:

Would there be a nicer way ?

Set [Interfaces: LAN] MTU 1492 too.

@cmb:

This is the expected end result given we don't add exclusions for the LAN IP anymore. That'll return in some manner in the future, likely automatically as previous versions did it for 2.2.2.

So does this mean I cannot have a remote gateway over IPsec anymore until the exclusions are added again?

(for example as explained in https://doc.pfsense.org/index.php/Routing_internet_traffic_through_a_site-to-site_IPsec_tunnel)

Hmm, that kind of sucks… Using the instructions described in the link above cause the local LAN to 'disappear' in a way that even clients cannot reach it anymore (and thus cannot access the internet via the IPsec tunnel). Anyone knows a workaround for this?

cmb, thank you for information. Yes, I'm using IKEv2, for security. I didn't know that switching to IKEv2 also [accidentally] activates MOBIKE.  It doesn't seem to have been mentioned in the 2.2 release notes.

From pftop status display (below), I can confirm that ESP tunnels between pfSense firewalls with public IP addresses remain pure ESP, not UDP-tunneled. It's just the IPsec status page that displays misleading information.

Thanks again!

pfTop: Up State 1-100/17675, View: default, Order: dest. port PR    D SRC                  DEST                STATE  AGE  EXP  PKTS BYTES esp  I xxx.xxx.11.62:0      xxx.xxx.84.122:0      2:2  38661    59 8936K 8989M esp  O xxx.xxx.84.122:0      xxx.xxx.227.40:0      2:2  41009    60  228K  40M ... tcp  I 74.125.82.172:33980  192.168.0.75:25      10:10  106    11  491  340K tcp  O 74.125.82.172:33980  192.168.0.75:25      10:10  106    11  491  340K tcp  I 192.168.19.4:4261    192.168.12.20:42      4:4  39727 86274  194 20994 tcp  I 192.168.16.3:1087    192.168.12.20:42      4:4  37625 84775  186 19694 udp  I 192.168.12.26:56079  8.8.8.8:53            1:2    15    15    2  352 udp  I 192.168.12.26:55595  8.8.8.8:53            1:2    12    18    2  276 udp  I 192.168.12.16:56447  23.5.165.172:53      1:2      7    23    2  152 ...

It's also worth mentioning that when I reboot my router, ipsec shows connected, but I am unable to use reach any of the remote subnets. Only after manually stopping then starting the connection through the web ui am I able to use the tunnel. I read in the forums that it may be related to having multiple phase 2 entries, but I am unsure as to how I can reach multiple subnets without multiple phase 2 entries. Any suggestions would be appreciated.

hm,

i cause my problem with x509 authenticated IPsec i tried an site-to-site tunnel between PFsense 2.2 and Cisco IOS with PSK and fix IP on both side.

There i have the similar problem.
This site-to-site only get established, when a client behind PFsense initiates the tunnel to the cisco.

When the tunnel is established also the router is able to transfer traffic over the tunnel, but not before.

I assumed: the Cisco IOS has about 5 different Phase1 policies, the PFsense has only one.
But i don't know how to define only one Phase1 policy for a specific client, also Cisco-Support told me that's not possible, I am unsure if should trust cisco in this statement (had already fights with the cisco support, what is possible and what isn't)

best regards
Thomas

Hi

i am currently fighting with a similar problem.

I have an IPsec site-to-site tunnel with x509 authentication.

client(192.168.1xx.45) –> pfsense 2.2 (192.168.1xx.4) --> Internetrouter(192.168.1xx.1) --> Internet --> cisco886 IOS (217.zzz.zzz.105) --> Server 192.168.2yy.5

When i try to ping from client 192.168.1xx.45 the server at 192.168.2yy.5 the tunnel gets established on both sides.
but i can't transfer any data.

also the encryptioncounters on the cisco ios stays at 0.
I had the same issue with PFsense 2.1.5 so i assume a bug at the cisco IOS router here.

best regards
thomas

Bump.  Is this just a limit of the config?

@benw01:

@jimp:

Did you add the special TCP-specific rules with the extra settings (Any flags, sloppy state) mentioned in the guide?

I hadn't done this! Once I added a TCP rule for L2TP Out with the Any flags and sloppy state it's working.

Now I just need to get it so that I can connect with Windows and OSX. If I set the DH Key group to 2 (1024), OSX can connect & works fine, but Windows 7 doesn't connect (Error 788). if I set it to DH group 14 (2048), Windows 7 works fine but OSX won't connect. Yay VPNs.

This is my post for this problem.
https://forum.pfsense.org/index.php?topic=83321.msg496600#msg496600
You can set it to 3DES/SHA1/DH group 2, it'll work for both Mac/Win.