so if i'm reading you right, if you are on 102, trying to get to a non 140 address, it fails? I'm no expert on IPSec by any means, but perhaps it's going something like this. 120 crosses the tunnel to get to 140, that works properly, 102 tries to get to 120, it doesn't have a route, it doesn't know to cross the tunnel to get there, which makes sense, because the tunnel is serving 102 to 140. maybe set a route at the endpoints of the tunnel? I'm picturing something like this: 102 tries to reach 120 –> route 102 to 140 -> ---tunnel--- 140 route to 120 120 talks back to 102 -->  route 120 to 140 -> ---tunnel--- 140 route to 102

Cheers for the reply. Tried that, and I thought I had a MTU problem as could ping but could not connect on RDP - Turns out had a routing issue. Simple resolution: Replace current gateway with pfsense. Now I have an issue where I need to route some traffic via IPSEC, thats to a second LAN - When the endpoint is the first LAN. I know that having another IPSEC should work, but these draytek 2600's keep locking up when two IPSEC connections are up to the same end.

Thanks cmb I will try setting it as a mobile, and I agree it is not ideal. But in Mexico a static IP is spendy so the client said no to doing this properly

http://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0 That exact config works for me with Android 2.x, 4.0, and iOS. Note that you need IPsec+xauth on Android, not IPsec+L2TP.

Most IPsec clients/servers will expire the connection at about 2/3 or so of the limit to be sure it gets rekeyed before it would expire on the other side. As far as I can see, racoon doesn't have a parameter to control whether or not xauth is re-forced when the Phase 1 expires. What you set for your p1/p2 times may be getting overridden by what the client is requesting on connection (that's what setting 'obey' will do, generally)

Wow interesting. I WAS using Cisco VPN client. Since you posed the question, I had not thought it could be the client since I was able to connect okay. Anyway installed Shrew soft, imported the same profile and I seem to be able to RDP to an internal host…etc just fine now. :) Thanks!! Cheers.

@jedblack: I think you may need to provide a Phase2 PFS group to the clients. check the box "Provide the Phase2 PFS group to clients ( overrides all mobile phase2 settings )" and select "Group 2" from the drop down menu See if that works for you… Thanks, I'll give that a try.

Hi, didn't read all the story, but can you then connect to printers if you VNC to the host in that another subnet and try to access with browser? If you can ssh to the other ends firewall can you then use proxy to connect printers?

Yes it seems to be hard to get an answer out of anyone on this forum. Not sure why, but whatever  Anyway that you can reconfigure devices and send them out for a coordinated change over? check these out http://store.netgate.com/ALIX2D2-Kit-Red-Unassembled-P1028C86.aspx very easy to install and configure

That means one of your packages broke its dependencies somehow. Just installing the 2.0.1 update file via System>Firmware, manual update, will fix.

Generally speaking, only two things would prevent traffic from moving. 1. The tunnel isn't actually up (check status > ipsec) 2. Firewall rules on the IPsec tab (Firewall > rules) are not allowing the traffic

Made a liar out of myself just now… Attempted an IPsec PSK+Xauth connection again and it worked. Perhaps one of the several firmware updates since the last time I tried it made it work.

Try going to System > Advanced, on the Misc tab, and toggle the checkbox for "Prefer old IPsec SA" It sounds like when one SA is expiring, it isn't getting fully dropped/rebuilt as expected by both sides. Also, disable NAT-T.

Probably the CPU… Celeron's aren't exactly known for their high-speed cryptography performance... :-)

@cmb: you have to have a phase 2 matching the OpenVPN tunnel IPs for it to go across the tunnel. Tnx, now work :-) Manuel

Reloading (updating its config, as must be done since IPs, etc. can change) is different from restarting (wiping out the SAD, SPD), so no.

yes it's only a ping. You just need to initiate any traffic that matches the second phase 2. Then if it doesn't come up, check the IPsec logs to see why.