@cheech:

Running with floppy config a tunnel went down and would not come back up. I checked the configs and somehow the lifetimes had been cleared on both sides. Not a user error I have saved the configs and they clearly specify the key lifes.

The storage medium of config.xml has absolutely nothing to do with this.

@cheech:

WRV54G will not re-establish tunnels to pfsense if the tunnel goes down without resetting the tunnel on this Linksys device. It has no problem re-establishing tunnel to other devices. I'm going to replace this with a pfsense box anyway…

System -> Advanced -> Prefer old IPsec SAs  -> check it.

No support lol. I am more interested in learning/understanding how this works or doesn't work. I setup another VPN at home and this works on and off. I realize this is nothing to do with pfsense and is a general networking/windows issue. What I come up with is that the application relies on the browser service. If I do a net view and see all the PC's then everything is fine but this is up an down for some reason:

In addition to acting as the local master browser, the primary domain controller also acts as the domain master browser, which ties subnets together and allows browse lists to be shared between master and backup browsers on separate subnets. This is how browsing is extended to function beyond the local subnet. Each subnet functions as a separate browsing entity, and the domain master browser synchronizes the master browsers of each subnet. In a Windows-only network, browsing cannot function across subnets unless a Windows NT/2000 PDC exists on the network.

Most VPN routers do allow the use of a FQDN to identify an endpoint. The domain would have to be hijacked + the key obtained. Is specifying an IP only and not FQDN a "feature" of pfsense security or just something that hasn't been implimented / considered for implimentation? Fortunately my dynamic IP's stay until modem is reset. I might just replace those devices with pfsense boxs anyway…

Make sure the router the pfSense is behind doesn't break things. You should have the pfSense directly at the WAN.

Done.

No progress has been made.  1.0 is being released without this support.

In your "roadwarrior" scenario you can either use PPTP, IPSEC or OpenVPN. The easiest to set up is probably PPTP as every Windows has a build in PPTP Client (since w2k).

You can find a walkthrough at http://doc.m0n0.ch/handbook/pptp.html (it's the same for pfSense for these settings).

IPSEC and OpenVPN needs a client you have to install at your notebook. For IPSEC there are only few free clients (see http://pfsense.com/index.php?id=33 ) and OpenVPN is even harder to setup as you need to generate certificates and also install client software first. I think what you are looking for is PPTP.

I have some mobile IPSEC scenarios where clients or other pfSenses and m0n0s join as mobile clients as they have dynamic IPs. I don't see any issues with these. I also have a colleague using SSH-Sentinel to join with his notebook his homenetwork (it even works with a dyndns account at the pfSense at his end).

Can you get us some logs of both ends (pfSense systemlogs and clientlogs though I don't know this client)?

Also make sure that your client is behind a device that supports IPSEC Passthrough and there are no restrictions to use IPSEC. IPSEC uses some special protocols that have to be handled correctly.

Yes, it will be present in the upcoming version 1.1 of pfsense, not in 1.0.

Already exists in -HEAD.

LAN A–-----------------LAN/pfSenseA/IPSEC-----------------------IPSEC/pfSenseB/LAN---------------LAN B

Don't get confused that it looks like a seperate Interface up there. IPSEC is completely transparent between the two pfSenses once established, it doesn't cross the WAN interfaces even (seen from the packetfilters view).

As I said you only can control incoming connections on an interface. So the rules at the LAN interface of pfSenseA determines what can move over the IPSEC to pfSenseB. pfSenseB can't block connections incoming over IPSEC as it's not an interface seen by the packet filter. The same applies for the other direction. Rules at LAN interface of pfSenseB can pass/block traffic going through the IPSEC to pfSenseA only.

I hope this makes it a bit more clear.

check the ipsec logs of both sides (client and pfsense). You might find a hint there.

can i create rules in open vpn ?

@hoba:

That's actually not a real error. it just tells you that there already was a policy for this connection but it got replaced when you edited the tunnel. It should simply work. I have the exactly same config using a pfsense with static IP and another pfsense and a m0n0 joininng with dynamic IPs. It's working for more than a month already without any glitches.

It´s working. Just like the tutorial show. I´ve solved some bugs in my configuration and that´s all.
Thanks everyone.
Diego

@diegote:

I´ve tried to connect 2 PC using IPSEC tunnel. This is correct? or one has to be Mobile client?? Somebody could create a tunnel?? I`ve tried so many configurations and nothing (in SAD nothing, in SPD always show 2 records, for incoming and outgoing policy).

It works!!!! in a private LAN.
Im trying to connect an ADSL (mobile client) to a Static IP. I´m using the configuration show in the tutorial with the FQDN (email & secret key) but doesn´t work. Ive copied LAN private configuration (for de phases, not the Network config).

The funny thing is, I could create a tunnel using ADSL IP like static IP, and the real static IP on the other side.

THANKS A LOT FOR EVERYTHING!!!!

I answered that at the m0n0 list a long time ago in a galaxy far far away: http://www.m0n0.ch/wall/list/showmsg.php?id=160/29
It's the same situation with pfSense atm. Using static routes across VPN-Tunnels doesn't work yet.

Problem ist the default MTU Setting from D-Link DFL-1100.

after change the MTU from 1424 to 1472 Filetransfer and also intranet websites will work now.

http://forum.pfsense.org/index.php?topic=927.msg5562#msg5562

Why MTU 1472 ? I try on a workstation behind pfsense to ping a workstation behind the D-Link.

ping 172.16.170.8 -f -l 1472

Ping wird ausgeführt für 172.16.170.8 mit 1472 Bytes Daten:

Antwort von 172.16.170.8: Bytes=1472 Zeit=47ms TTL=126
Antwort von 172.16.170.8: Bytes=1472 Zeit=48ms TTL=126

ping 172.16.180.8 -f -l 1473

Ping wird ausgeführt für 172.16.180.8 mit 1473 Bytes Daten:

Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

Ping-Statistik für 172.16.180.8:
    Pakete: Gesendet = 2, Empfangen = 0, Verloren = 2 (100% Verlust),

Looks like user error was to blame as I was able to get my IPSec tunnel up with my workplace's NetScreen firewall.

Thanks,

– Phob