Hey jimp, I noticed something this morning - the IPSEC to the dynamic dns site had been down a few hours. Thing is the lifetime on both phases was set to 1 hour. Is this still part of the bug in 2.0? I could be wrong but I thought that if the SA was set to 1hr then PfSense would try to re-establish the connection after the lifetime expired even with the DPD bug.

in 1.2.3, IPsec is just IPsec, no l2tp. In 2.0 it should be possible to use l2tp+ipsec.

I have seen this setup before, it was with a Cisco IPSec VPN client, thought maybe it was possible with shrew. I will setup OpenVPN later today and give it a try.

You can't route IPsec, so it's really a question of IPsec Phase 2 settings.

You would either need two separate tunnels, one for each subnet present on the side with the DMZ network, or they would have to be close enough in numbering that you could just specify a subnet mask that would cover them both (but not the network at the other site).

Or just ditch the IPsec tunnel, put in OpenVPN site-to-site shared key, and route however you like without the headache of IPsec. :-)

It's easier on 2.0 though with IPsec, you can just specify multiple networks under a single tunnel.

Hi pad,

U tried to start racon in debug mode for more details? Are there any firewall events?

hit me if im wrong but v 1.2.3 dont support nat-t for mobile vpn. In order to work ur vpn client needs a official ip.

Limitations

* NAT-T is not supported until version 2.0, which means mobile clients behind NAT are not supported. This limits pfSense's usefulness with mobile IPsec clients. OpenVPN or PPTP is a better solution.
    * Some of the more advanced capabilities of ipsec-tools are not supported until 2.0, including DPD, XAuth, NAT-T, and others.

cya

Try connecting to with the pc just outside the pfsense firewall. You want to test it with nothing but a switch in between them. If the vpn passes traffic you may have same issue that i have. It looks like either a Nat issue or MTU problem I can't tell which because i get no other log output. other than microsoft fragmentation problem..

You dont have to define a default gateway for the ip just as long as you have defined the network that is behind the firewall as the remote network.
If the client is connecting but not passing traffic. Try setting the client on the public segment with a public ip, so that there is not other devices between the firewall and the client and then connect. If the vpn passes traffic you have a nat or mtu issue of some kind if you still cant ping etc.. make sure you have a rule ie * <–> * any any on the ipsec interface for vpn traffic.

Ah! I'll set that up monday and get back to you!
Always something simple!

hi jim, yes, 2.0 always latest snapshot, but i don't believe it has something to do with 2.0 especially, therefore i didn't post it there over..

i have tried to do mss clamping on vpn traffic (tried a few adjustments) around 1300 bytes. i tried before a few settings on wan's mtu around 1500 and mss clamping on wan around 1300-1350, letting space for around 150 bytes of overhead. but i don't know really if my thinking is right..

still, when i adjust the mtu of the ipsec client it does establish the connection and traffic passes through it. on the same line with i.e. osx or iphone client, it fails with logs posted above, even tried connecting through umts, no way. windows & linux clients working fine. tried to adjust clients lan interfaces mtu too, but that didn't helped neither, and seems to be bad practice..

i don't even know, if i'm talking absolute rubbish here, so given that, thank you for bearing with me..

ROOKIE AT WORK.

this warning  just means that random numbers are generated trough software and not trough a i.e. vpn-accelerator-card. but i don't think it has anything to do with your dropped tunnels, like XIII said, post your config and ipsec-logs…

try changing negotiation mode to aggressive.

IPsec doesn't route in that way, unless you're talking about IPsec in transport mode with something else like GRE on top.

You'd have to setup IPsec with a remote network of 0.0.0.0/0 in order to direct all traffic to go through the tunnel. It's been discussed before, search the forum and doc wiki for more info.

@franken:

Can you please provide a link please :)

http://www.lobotomo.com/products/IPSecuritas/howto/m0n0wall%20HOWTO.pdf

If you were using pfSense 2.0 beta you might be able to do something with IPsec in transport mode + a GRE tunnel riding across that, but I haven't set that up before. IIRC, the ASA should support that (but you'd have to check on that first)

@jimp:

And pfSense is the gateway for the workstation you are pinging from?

What if you try to ping from the web interface (Diagnostics > Ping) with the LAN interface selected?

Yes is the gateway.
ipconfig :
Konfiguracja IP systemu Windows
Karta Ethernet Połączenie lokalne:

Sufiks DNS konkretnego połączenia : local
  Adres IPv6 połączenia lokalnego . : fe80::140c:40e9:35df:1d6%13
  Adres IPv4. . . . . . . . . . . . . : 192.168.1.140
  Maska podsieci. . . . . . . . . . : 255.255.255.0
  Brama domyślna. . . . . . . . . . : 192.168.1.254  !!!

ping result is in txt file

ping-from-webgui.txt

i had some similar behavior recently…. i found the rule going from one vpn lan to another needs to have the gateway set to "default" otherwise i can ping from pfsense but not from a host.

i previously had 1.2.3-rc1 connecting to a 2.0 box. after upgrading the old version to 2.0 I now get a consistent 50kbytes/sec which is a slight improvement but no where near where it could be.

i setup the same versions in an ESXi box. the ESXi system housed 2 pfsense gateways  (including the one doing 50kbytes/sec) and a third system which servered as the vpn client system:

real host <-> pfsense A <- vpn -> pfsense B <-> virtual host

the real and virtual host can send/receive 5mbytes/sec to eachother… pfsense A is the same system doing 50kbytes/sec with my other host so it's not the config, infact it's a default config. i don't change any phase 1/2 options except the PSK.

i'm going to blame this on QoS going on on the shared network connecting to pfsense A which is beyond my control. from the virtual testing and the lack of other people complaining about IPsec, I would hazard a guess that pfsense ipsec is pretty fast.

hi,

i make this with dyndns ip.
I put my dyndns client in a lan machine, and i use loadbalancer in pfsense to load balance the webaccess of this lan machine.
if wan1 up then webaccess use wan1 else wan2. so my dyndns ip is the UP ip.

then i use this dyndns ip to create my vpn.

pf1.dyndns.org <–----- vpn -----> pf2

when my first wan is down my dyndns ip is update by my lan machine to my wan2 ip,  and  so the pf2 come from my wan2 to re UP my vpn channel.

hope that 's help !