Yes, MTU was one of the first things I'v suspected, so I run MTU at 1300 almost from the start (when I installed the tunnel).
I just don't know anymore.. but I will probably end up changing hardware all together just to rule out some "issues", but if this fails,
it will left me clueless with a Dunce cap somewhere between the two peers. And belive you me - not a pretty picture.
It's not a good news. But many thanks for your testing.
Today, I updated pfsense to RC2h. And I made some tests and found some strange things. I hope it will help you to find the problem on IPSec at OPT1.
1. I disabled the IPSec and made below two tests, a and b.
a. DHCP on WAN and OPT1 - I can access Internet through OPT1 when I leave the LAN rule at default gateway.
b. Static on WAN and OPT1 - I cannot access Internet through OPT1 when I leave the LAN rule at default gateway. But I can access Internet after I change the LAN rule's gateway to OPT1's gateway.
2. I enabled the IPSec at OPT1.
a. DHCP on WAN and OPT1 with the LAN rule at default gateway - I cannot even see SPD on IPSec staus page.
b. Static on WAN and OPT1 with the LAN rule at default gateway - I cannot access to Internet. But I can see SPD on IPSec staus page and I found some IPSec logs that IPSec tried to establish tunnel and it failed. Below is the IPSec log.
Sep 3 02:21:57 racoon: ERROR: phase1 negotiation failed due to time up. 28cde7f46500a3aa:0000000000000000
Sep 3 02:21:28 racoon: INFO: delete phase 2 handler.
Sep 3 02:21:28 racoon: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP 210.109.xx.xx->210.106.XX.XX
Sep 3 02:20:57 racoon: phase1(agg I msg1): 0.102666
Sep 3 02:20:57 racoon: oakley_dh_generate(MODP768): 0.089224
Sep 3 02:20:57 racoon: INFO: begin Aggressive mode.
Sep 3 02:20:57 racoon: INFO: initiate new phase 1 negotiation: 210.106.xx.xx<=>210.109.xx.xx
Sep 3 02:20:57 racoon: INFO: IPsec-SA request for 210.109.xx.xx queued due to no phase1 found.
c. Static on WAN and OPT1. I changed the LAN rule's gateway OPT1's gateway - Now I can access to Internet through OPT1. And I can see SPD on IPSec status page. But I cannot find any logs that IPSec tried to establish tunnel even after I ping to remote subnet.
For more accurate test, all tests was made when WAN disconneted.
Otherwise the traffic won't be encapsulated into the tunnel as it doesn't match the tunnel definition.
Hmm, are you totally sure about this? I don't have any positive contrary evidence, but I successfully run an IPSEC VPN like this:
Local Net Remote Net
Even though the remote net is technically a subnet of the local net, I have had this work without issue. Note: it was not totally intentional, originally.
The next step:
If one expanded this into:
Local Net Remote Net
Now you can send traffic bound from each remote net to another to the localnet.
This will work. Nobody said it wouldn't. If you can sum up your networks this way it will work. I have a 10 location setup running this way with 8 of the locations coming from dynamic IPs. The thing you can't do is add a static route across the tunnel.
Thanks for the tip!
I've tried serveral values in the 1400ish range and am not having much luck.
I am able to make voip calls b/t the two sites, which tells me that traffic is at least flowing in both directions.
looks like I spoke too soon…. lowering to 1300 seems to have fixed the VNC issue.
Thanks for the tip!
Works fine for me. I would blame the problem on running in vmware maybe. I actually have configured a multi site (9 sites with dynamic IPs) to headoffice (static IP) setup today where all sites are connected through the mainoffice (traffic from site a to site b runs through the tunnels via mainoffice; site a and b don't share a tunnel). While I set up this the LANs of the firewalls were not connected but the tunnels were established automatically and stayed up. I even rebooted the mainoffice and the other machines dropped in in a few minutes. After 5 minutes the last machine joined again and everything was up and stayed up. I also have a similiar setup running since month where I have running voip through the tunnels. No issues. Please try this with some real machines.
Use the DHCP Server of the pfSense to assign the clients the pfSense as first DNS Server and the remote DNS Server behind the tunnel as second DNS. Also if you have a WINS server in the remote LAN assign this as well. This works for me for pretty everything.
We did some IPSEC improvements in RC2 but they shouldn't affect establishing of a tunnel. I just wondered what your specs are as we had some funny effects with 64 MB RAM hardware at the hackathon where racoon exited too due to full memory but that shouldn't be the case with your boxes then.
Actually, the openvpn trafic orignating from pfSense cannot take advantage of the load balancer.
In order to have a functionnal(FAIL-OVER ONLY) setup on a single box, here's what we did:
If the tunnel goes down, add a route to direct OpenVPN trafic to the other gateway (ISP2)
In the openvpn client configuration, add to the custom options:
Idealy, the script should be linked to the load balancer (for the monitor IPs)
So, there is follow-up in http://forum.pfsense.org/index.php/topic,1650.0.html for the load balancer scripting…
We don't support old versions. Upgrade to the latest RC1 snapshot. If the problem still exists raise your voice again. The version you are using is outdated since month and a lot of things have been changed that might resolve your issue.
Yeah, had sth like the mentioned question at some customers location. That was really weird, as you sat in the net of, let's say #2 and #1 transferred large amounts of data thorugh #2 to subnet #3. The guys'n'gals at location #2 always wondered, why their net connection is that damn lame ;)
For the sake of bandwith you should really consider Hobas recommendation :)
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.
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…
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.
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.
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.