Roadwarrior issues
-
I have multiple pfSense installs that I manage, a few of which have IPSEC point to point tunnels up that work great.
I now have a client who has one of these point to point tunnels who wants to have a few employees use the VPN from their home. I've had a number of issues (following the guide on the wiki closely, many times).
Point A (the primary location) is a 1.2.3-RC1 install. Point B is a basic 1.2.2 install. Point A was previously a 1.2.3-Prerelease and had other issues with this same setup where raccoon would simply tell me "no configuration found" with no other errors when attempting road-warrior logins. Now that I changed over to RC1, this is what I see when attempting a roadwarrior login to Point A:
May 29 13:12:22 racoon: ERROR: phase1 negotiation failed due to time up. a085ceb9bd045a2f:5560d8ec85229d4b
May 29 13:11:32 racoon: [Unknown Gateway/Dynamic]: INFO: Hashing 66.218.xx.xx[500] with algo #2
May 29 13:11:32 racoon: INFO: Hashing 67.124.xx.xx[500] with algo #2
May 29 13:11:32 racoon: INFO: Adding remote and local NAT-D payloads.
May 29 13:11:32 racoon: INFO: Selected NAT-T version: RFC 3947
May 29 13:11:32 racoon: INFO: received Vendor ID: DPD
May 29 13:11:32 racoon: INFO: received broken Microsoft ID: FRAGMENTATION
May 29 13:11:32 racoon: INFO: received Vendor ID: RFC 3947
May 29 13:11:32 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
May 29 13:11:32 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
May 29 13:11:32 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-01
May 29 13:11:32 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
May 29 13:11:32 racoon: INFO: begin Aggressive mode.
May 29 13:11:32 racoon: [Unknown Gateway/Dynamic]: INFO: respond new phase 1 negotiation: 66.218.xx.xx[500]<=>67.124.xx.xx[500]On the Shrewsoft/client side it looks good, says "tunnel enabled" and then shortly after says "negotiation timeout occurred" and shuts down the tunnel.
I'm pretty sure my settings are the same on both sides and shadow the how-to. I've tripple checked everything, tried from multiple outside networks, etc.
Do I need to just downgrade back to 1.2.2 at this location? I've been running the newer releases because I can keep a close eye on this particular location (have a key, live next door, etc) and it's been stable/good, but if I can't get the VPN going that's a no-go for me.
Any suggestions? This has been a bit of a pain in the ass for me because I mostly work from inside this network so testing isnt super easy.
-
Can you try the most recent 1.2.3-RC full update based on FreeBSD 7.2 to see if the problem goes away?
http://snapshots.pfsense.org/FreeBSD_RELENG_7_2/pfSense_RELENG_1_2/updates/pfSense-Full-Update-1.2.3-20090529-0106.tgz
Starting last night, a newer revision of ipsec-tools was introduced which fixed some other bugs, but it's possible that it introduced others.
-
So I went ahead and updated to the new release via the link you listed…
I havent had a chance to try the roadwarrior login but the Tunnel between Point A and Point B hasn't come back up. I have a few messages like this on the 1.2.3-RC box now though:
May 29 16:42:05 racoon: ERROR: bind(sockname:/var/db/racoon/racoon.sock): No such file or directory
May 29 16:42:05 racoon: INFO: Reading configuration from "/var/etc/racoon.conf"
May 29 16:42:05 racoon: INFO: @(#)This product linked OpenSSL 0.9.8e 23 Feb 2007 (http://www.openssl.org/)
May 29 16:42:05 racoon: INFO: @(#)ipsec-tools 0.8-alpha20090525+natt (http://ipsec-tools.sourceforge.net)Creating the /var/db/racoon DIR and then starting the Racoon service fixed this issue...
On a side note; Holy crap this box's web interface is slow now! I'd say about 1/10th the speed it was with the previous RC I was using. It takes at least a few seconds per page to populate, often more. For example my Rules page displays about 2-3 rules every second or so, and about ~10 seconds total to load.
It is far faster on VPN over a fairly high latency (200ms) via remote desktop to see Point B's page load (1.2.2).
-
Yeah I hit that missing directory, too, I'll pass that along.
In the meantime, there were some other unrelated issues with the build system last night, too, which may have caused some of your problems. It has worked fine for me.
Try this update, see if it's any better:
http://snapshots.pfsense.org/FreeBSD_RELENG_7_2/pfSense_RELENG_1_2/updates/pfSense-Full-Update-1.2.3-20090529-1838.tgz
-
I updated the box last night to the current RC you linked… the slowness became a lot better (not quite as snappy as it once was, but certainly not nearly as slow as it had become w/ the day before's RC).
I am still not able to connect via shrewsoft:
May 30 15:48:25 racoon: ERROR: phase1 negotiation failed due to time up. 700243c50e2cca0e:1c865d2483a985ad
May 30 15:47:35 racoon: phase1(agg R msg1): 0.032722
May 30 15:47:35 racoon: [Unknown Gateway/Dynamic]: INFO: Hashing 66.218.xx.xx[500] with algo #2
May 30 15:47:35 racoon: [Unknown Gateway/Dynamic]: INFO: Hashing 66.127.xx.xx[55077] with algo #2
May 30 15:47:35 racoon: INFO: Adding remote and local NAT-D payloads.
May 30 15:47:35 racoon: alg_oakley_hmacdef_one(hmac_sha1 size=332): 0.000016
May 30 15:47:35 racoon: alg_oakley_hmacdef_one(hmac_sha1 size=20): 0.000011
May 30 15:47:35 racoon: alg_oakley_hmacdef_one(hmac_sha1 size=1): 0.000011
May 30 15:47:35 racoon: alg_oakley_hmacdef_one(hmac_sha1 size=165): 0.000013
May 30 15:47:35 racoon: alg_oakley_hmacdef_one(hmac_sha1 size=165): 0.000013
May 30 15:47:35 racoon: alg_oakley_hmacdef_one(hmac_sha1 size=145): 0.000018
May 30 15:47:35 racoon: alg_oakley_hmacdef_one(hmac_sha1 size=36): 0.000020
May 30 15:47:35 racoon: oakley_dh_compute(MODP1024): 0.015321
May 30 15:47:35 racoon: oakley_dh_generate(MODP1024): 0.015600
May 30 15:47:35 racoon: INFO: Selected NAT-T version: RFC 3947
May 30 15:47:35 racoon: INFO: received Vendor ID: DPD
May 30 15:47:35 racoon: INFO: received broken Microsoft ID: FRAGMENTATION
May 30 15:47:35 racoon: INFO: received Vendor ID: RFC 3947
May 30 15:47:35 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
May 30 15:47:35 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
May 30 15:47:35 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-01
May 30 15:47:35 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
May 30 15:47:35 racoon: INFO: begin Aggressive mode.
May 30 15:47:35 racoon: [Unknown Gateway/Dynamic]: INFO: respond new phase 1 negotiation: 66.218.xx.xx[500]<=>66.127.xx.xx[55077]The Shrewsoft client seems to think i'm connected for the ~50 seconds between the beginning of the connection and the timeout, but pings show a "General Error" from Windows cmd prompt.
Any more suggestions?
Thanks,
Pheleven -
Just noticed something that is probably key…
My firewall logs show it blocking the remote (roadwarrior's) IP, port 4500 a large number of times between these timeouts, like so:
May 30 15:48:13 WAN 66.127.xx.xx:4500 66.218.xx.xx:4500 UDP
-
It may not be automatically adding the NAT-T rule like it should.
Try adding a rule by hand to allow traffic to your WAN IP on udp/4500, which is the standard NAT-T port.
-
Yep, not adding the rule. This is working, but the users are highly likely to be using various IPs, so this isn't a practical solution for all of them. I'm curious if disabling NAT-T on the client end will actually cause me headaches or not. Maybe i'll try that first.
-
I'd advise keeping NAT-T on in that situation.
Hopefully the code to automatically add the NAT-T port rule should be in the next snapshot or the one after. It's just a matter of me tracking down a dev with access to the locked-down 1.2.x tree and time to fix it up.
-
Hello,
I appear to be having a similar issue.
I have 3 PFsense boxes that i manage. All are running 1.2.3-rc1
All 3 firewalls are connected by ipsec tunnels over the internet and have mobile IPsec (road warrior) setup. I am using the shrew soft vpn client on win xp sp2If i try to VPN using shrew soft to one of the other sites from behind my pfsense box i get the "negotiation timeout occurred" message. If i disconnect pfsense from my modem and plug my computer directly to the public net i can connect fine.
This happens at all 3 of my sites so i am assuming that there is a setting that needs to be tweaked in the outbound settings of whatever pfsense box i am behind to allow the connection out.
Any ideas on what i can check?
