Hello!

I just ran into quite the same troubles. I cannot set an mtu bigger than 1492 an my pppoe-wan.
Are there any news on the efforts in this matter?

Thank you
Epek

Hmm, I've been testing some more with the "Fri Jan 02 14:57:04 CST 2015" build, and I have not seen the same issues as I did previously today. Must have been a wierd coincidence where "tunnelbroker.net" experienced issues at the same time as I upgraded the FW. I have never exerienced having issues with "tunnelbroker.net" before.

Anyway, everything seems fine now.

It gets stranger, though, when I try to start tincd from the command line for debugging, I get this:

[2.2-RC][root@host.domain.tld]/root: tincd -dD Cannot open config file /usr/local/etc/tinc/tinc.conf: No such file or directory Failed to read `/usr/local/etc/tinc/tinc.conf': No such file or directory [2.2-RC][root@host.domain.tld]/root: ls -las /usr/local/etc/tinc/ WARNING-ENTIRE_DIRECTORY_ERASED_ON_SAVE_FROM_GUI hosts/ rsa_key.priv tinc-up* tinc.conf [2.2-RC][root@host.domain.tld]/root: cat /usr/local/etc/tinc/tinc.conf name=pvd-gateway-tincd AddressFamily=ipv4 ConnectTo=pws-gateway

Now, while it's perfectly possible that the configuration isn't correct, the error message that "No such file or director" exists, is bit off, given that the .conf file even has some content.

@DiskWizard:

2.2-RC (amd64)
built on Fri Jan 02 05:25:48 CST 2015
FreeBSD 10.1-RELEASE-p3

Suricata is back again ! :)

I had the pfSense Team recompile the Suricata binary so that this parameter should now say "no" instead of "yes" –

GCC march native enabled:                yes

You can see this by executing

suricata --build-info

from the command line.

This can be a problem on some platforms where the native CPU does not match up closely with the CPU of the package builder systems on the pfSense Repository side.  When this parameter is set to "yes", the C compiler attempts to auto-detect the compiling machine's CPU and optimize the produced machine code.  This is generally OK except for when there are some differences in supported instructions (for example, compiling on a Xeon but running the produced code on a Pentium).  The Suricata binary from upstream defaults to enabling this parameter.  It works fine so long as you compile and then run Suricata on the same hardware.  In a package repository environment where the binary packages are built on one CPU architecture but then potentially executed on several different architectures, there can be issues.

Bill

@doktornotor:

Looking at this thread, you just have badly unstable IPv6 connectivity. Nothing to do with pfSense really and messing with various snapshots definitely will not help.

I was not aware the package repository resolved to IPv6. After disabling the WAN6 interface, I can once again access the packages.

Thanks!

@dstroot:

Just curious - are you using the full version or the nano version?

full

if anyone else is installing full on an SSD, make sure to enable trim
Hit CTRL+c during installer shutdown or boot into single-user mode

/sbin/tunefs -t enable /dev/ada0s1a

I also added the 'noatime' option to the /etc/fstab entry

Many many thanks for the quick response. It works again everything was perfect. Thx

Fair enough.
I'll go for an external AP, and I'll plan to migrate on a APU later.

!

Question is closed. thanks to Jimp.

to sum up:
Alix appliance are not strong enough to handle N wireless properly. The solution is to have an external AP or to migrate on a stronger platform like the APU.

!

Still good after a full reboot as well…

Maybe something in the latest snapshot fixed it.

What is the error message in the logs or from the GUI when it doesn't work?

I haven't noticed anything unusual on my ALIX running 2.2 aside from an occasional panic.

Something you might try setting is to add this to /boot/loader.conf.local and then reboot:

hint.ata.0.mode=PIO4 kern.cam.ada.write_cache=0

Those will (1) disable DMA, and (2) disable write caching. These were off on 2.1.x and before but the sysctl OIDs changed. They may or may not even be necessary these days. As far as I can tell on my ALIX it is already using PIO4 without any extra settings in place.

@thermo:

It's working as expected. One radio can operate at either 2.4 or 5ghz - not both simultaneously. If you want concurrent dual band then you need a second card/radio installed.

Hi, Thanks for the info, however, I was under the impression this particular card had 2 radio's, I'll have to confirm that, maybe the dmesg output is a little misleading then, specifically:

ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0

So I just had the lockup happen.  I'm now wondering if its something related to OpenSSL.  When I got locked out of the UI I was still able to access the internet; I also noticed that all of my VPN tunnels went down and wouldn't come back up, once again…rebooting fixed the issue.  It seems like openSSL puked and everything related to SSL stops working (OpenVPN tunnels and web UI).  After reboot I notice these entries in the logs:

Dec 29 22:46:41 openvpn[18854]: SIGUSR1[soft,tls-error] received, process restarting
Dec 29 22:46:41 openvpn[18854]: Fatal TLS error (check_tls_errors_co), restarting
Dec 29 22:46:41 openvpn[18854]: TLS Error: TLS handshake failed
Dec 29 22:46:41 openvpn[18854]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec 29 22:46:29 openvpn[19405]: send_push_reply(): safe_cap=940
Dec 29 22:46:28 openvpn[19405]: Initialization Sequence Completed
Dec 29 22:46:27 openvpn[19405]: [firewall1] Peer Connection Initiated with [AF_INET] xxx.xx.xx.8:48947

So, I think there are some negotiation problems.

I got now in phase 2 AES256-GCM/128, no hash and PFS group 18 working.
However, there seem to be issues negotiating terms, because if there are multiple options available, it can seemingly take forever until that comes up. So now, I don't give any wiggling room, and it's faster.

Phase 1 still has issues:
a) when I change Key Exchange version from Auto to V2 => no go
b) when I change DH Key group above 18 => no go

So I got it to work with Key Exchange auto, AES-256, AES-XCBC, DH-8192, NAT-T-Auto, Main-mode, PSK.

Changing things to V2 => no phase 1 completed
Changing things to DH Key group 24 => no phase 1 completed

Thanks for the info.
Hmm in this case how can I check if my drive is starting to fail? It's just a simple ATA drive.
The good news is that I bought 2 spare disk recently :)

Romain

It appears that Android may have a bug in it relating to NAT traversal. In android, I get the following errors when attempting to connect:

12-31 13:16:07.482 I/Vpn    (799): Switched from [Legacy VPN] to [Legacy VPN] 12-31 13:16:07.485 D/Vpn    (799): setting state=IDLE, reason=prepare 12-31 13:16:07.486 I/Vpn    (799): Switched from [Legacy VPN] to [Legacy VPN] 12-31 13:16:07.487 D/Vpn    (799): setting state=IDLE, reason=prepare 12-31 13:16:07.487 D/Vpn    (799): setting state=CONNECTING, reason=startLegacyVpn 12-31 13:16:07.497 V/LegacyVpnRunner(799): Waiting 12-31 13:16:07.502 V/LegacyVpnRunner(799): Executing 12-31 13:16:07.504 D/Vpn    (799): setting state=CONNECTING, reason=execute 12-31 13:16:07.520 D/racoon  (10824): Waiting for control socket 12-31 13:16:07.721 D/racoon  (10824): Received 9 arguments 12-31 13:16:07.735 I/racoon  (10824): ipsec-tools 0.7.3 (http://ipsec-tools.sf.net) 12-31 13:16:07.747 I/racoon  (10824): 10.0.203.120[500] used as isakmp port (fd=6) 12-31 13:16:07.747 I/racoon  (10824): 10.0.203.120[500] used for NAT-T 12-31 13:16:07.747 I/racoon  (10824): 10.0.203.120[4500] used as isakmp port (fd=7) 12-31 13:16:07.747 I/racoon  (10824): 10.0.203.120[4500] used for NAT-T 12-31 13:16:07.747 I/racoon  (10824): initiate new phase 1 negotiation: 10.0.203.120[500]<=>69.135.168.176[500] 12-31 13:16:07.747 I/racoon  (10824): begin Aggressive mode. 12-31 13:16:08.594 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:10.631 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:12.689 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:13.781 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:16.870 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:19.859 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:19.934 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:23.022 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:25.144 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:28.246 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:31.339 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:32.872 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:34.958 E/racoon  (10824): ignore the packet, received unexpecting payload type 20. 12-31 13:16:37.962 E/racoon  (10824): phase1 negotiation failed due to time up. 118a955695bcb745:0000000000000000 12-31 13:16:37.962 I/racoon  (10824): Bye 12-31 13:16:38.024 I/LegacyVpnRunner(799): Aborting 12-31 13:16:38.024 I/LegacyVpnRunner(799): java.lang.IllegalStateException: racoon is dead 12-31 13:16:38.024 I/LegacyVpnRunner(799): at com.android.server.connectivity.Vpn$LegacyVpnRunner.execute(Vpn.java:1213) 12-31 13:16:38.024 I/LegacyVpnRunner(799): at com.android.server.connectivity.Vpn$LegacyVpnRunner.run(Vpn.java:1092) 12-31 13:16:38.024 D/Vpn    (799): setting state=FAILED, reason=racoon is dead

Googling the error, there is this bug report for strongswan: https://wiki.strongswan.org/issues/255

And it was actually my idea to begin with ;)

well its the same from past many pfsense major releases, but power failure are a rare thing in my location so i was living with it and few other newer alix boxes i installed globally later on came with the cmos battery so they didnt suffer this untill a few of my full installs had a failed battery and the location they were in had frequent power failures so it ended up like a nuisance so i thought of bringing this up because i wasnt sure if it was the battery or some other rare bug with state tables because i was seeing this issue more often in the full installs so tried the same on my alix and i was convinced to get this fixed once and for all.

now that we know its the battery i hope it gets fixed soon

bytheway it takes ages on the alix to recover, full installs still recover quicker. config was same from the last 3 major releases and all have this issue, it happens only after like 5-9mins when booting from power failure and rest of the components work fine without any issues when time jumps