Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - yarick123

Pages: [1] 2 3 4
Russian / Re: CARP ip-TTL или что пошло не так?
« on: February 09, 2018, 09:08:46 am »
есть большая локалка, два провайдера и две железки... [skipped]
ping ...[skipped] на любой WAN проходит нормально...

Подозреваю, имелось в виду, по одному CARP на WAN. И под "железками" тут, скорее всего, имелись в виду устройства с pfSense, а не маршрутизаторы, как я в начале подумал.

So, disabling check-sums offloading seems to bring a new behavior.

I would try another virtual NIC or maybe another version of VirtualBox.

P.S. For this test configuration the "==== WAN ====" rules are not necessary.

As far as I understand, if you configure OpenVPN on pfSense, there is no port forwarding at all.

I think, if the pfSense GUI and Internet can be accessed from the physical LAN, the problems with port forwarding can be caused not only by the check-sums.

Do you see on WAN outgoing forwarded packages from LAN hosts?

I had problems, similarly to yours, as I had not correct routing + outgoing NAT configuration. It can be also something wrong with the Virtual IPs configuration. Or are you forwarding the firewall ports?

Questions: Do i have to do ethtool -K <interface> tx off only on the LAN bridge assigned to pfSense or also on the real interface the bridge is defined on? Is it enough to do this on the LAN interface or also on the WAN or on all interfaces within that host machine? Tested some combinations but no luck.. And: Do i also have to switch off hardware offloading for rx and maybe other stuff?

For test purposes I would disable check-sums offloading on all possible physical/virtual NICs.

if hosts from LAN can ping (what does traceroute show?), I would say, that somewhere there is a rule, which blocks tcp connection to port 80 (443?) or the all-allowing rule does not work.

  - I have a rule on both the WAN and LAN to allow any protocol, on any port to and from any address and port.

Do you mean a floating rule? Is it configured as a quick rule?

I would not use floating rules at all for your purposes, just "disable all" rule on WAN, "enable tcp dest. ports 80, 443" then "disable all" rules on LAN.

BTW, if the configuration is correct, your pfsense box should be fully accessible from outside. Are you sure, that this is what you want?

P.S. There was also an issue with check-sums, but I am not sure, if this problem happens on VirtualBox too. Look at

Installation and Upgrades / Re: Cannot update 2.3.2_1 i386 on 4GB nanoBSD
« on: January 21, 2018, 02:50:10 pm »
# df -h
Filesystem           Size    Used   Avail Capacity  Mounted on
/dev/md0              38M    164K     35M     0%    /tmp
/dev/md1              58M     19M     34M    35%    /var

you need more space in /var.

Just go to System/Advanced/Miscellaneous: RAM Disk Settings (Reboot to Apply Changes), increase size of /var (I have set 800 MB), reboot the system and try to upgrade again. I have also increased size of /tmp to 60 MB.

P.S. I have two firewalls. One of them could finally upgrade, the second could not upgrade the kernel and I had to reinstall the system.

But in this case the ppp connection should be configured for the interface. You did not say anything about it. Have you configured ppp[oe]?

Installation and Upgrades / Re: Using pfSense on a single NIC
« on: January 14, 2018, 09:11:23 am »
pfSense needs as minimum two network interfaces to do something useful. As far as I remember, pfSense cannot be configured if there is only one.

You could use VLANs to make more logical network interfaces from a physical one. In this case VLANs must be supported by your primary router. If not - I do not see any possibility to do what you want on the existing hardware, sorry.

P.S. I suppose, you do not use any switch between the primary router and pfSense.

After just waiting some time, the version number in the dashboard was updated.

But, "pfSense-upgrade -d" upgraded pfSense-kernel-pfSense_wrap_vga: 2.3.5 -> 2.3.5_1 [pfSense-core].

The system as rebooted. Now all versions are correct. "pfSense-upgrade -d" does not try to upgrade anything.

I cannot just believe, that the firewalls are now up to date...

I have just reinstalled pfSense NanoBSD i386 2.3.5, restored the configuration and started upgrade to 2.3.5-1. There was a small problem:

Code: [Select]
[35/41] Fetching pfSense-kernel-pfSense_wrap_vga-2.3.5_1.txz: 139418100:error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac:/usr/local/poudriere/jails/pfSense_v2_3_5_i386/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s3_pkt.c:518:
.......... done

Starting the upgrade the second time solved the problem. Everything was updated without any problem. But the system shows, that the version is still 2.3.5 instead of 2.3.5_1. As usual, in the update dialog, it shows, that we are already on version 2.3.5_1.

Bad luck :( It seems to be a sign to move away from NanoBSD. So many troubles with the upgrade I did not ever have.

It seems to be a problem of the VirtualBox 5.2.

The same behavior I see for pfSense NanoBSD i386 2.3.2, 2.3.4 (2.3.3 was not tested).

Amd64 builds are working without problems.


I have the simplest VirtualBox 5.2.4 virtual machine configuration:

Code: [Select]
1GiB RAM, 1 CPU, PIIX3, no paravirtualization, no hardware virtualization,
48MB display RAM, no GPU acceleration,
IDE PIIX 3: IDE Primary Master: pfSense-CE-2.3.5-RELEASE-2g-i386-nanobsd-vga.img,
no audio,
adapter 1: Intel PRO/1000 T Server, bridged with the host NIC, cable not connected,
adapter 2: Intel PRO/1000 T Server, host-only adapter, cable not connected,
serial port: COM1, \\.\pipe\com_1,
no USB

The first booting works like a charm. After rebooting (option 5 from the console), BTX is halted, see pictures.

Have only I such a bad destiny?

I tried "pkg install -yf pkg pfSense-kernel-pfSense" and got a segmentation fault on the integrity checking stage.
Re-fetching the packages did not help...

Code: [Select]
[2.3.5-RELEASE][]/root: /usr/sbin/pkg install -yf pkg pfSense-kernel-pfSense
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        pfSense-kernel-pfSense: 2.3.5_1 [pfSense-core]

Installed packages to be DOWNGRADED:
        pkg: 1.10.2 -> 1.10.1_1 [pfSense]

Number of packages to be installed: 1
Number of packages to be downgraded: 1

The process will require 17 MiB more space.
17 MiB to be downloaded.
[1/2] Fetching pkg-1.10.1_1.txz: 100%    3 MiB 444.1kB/s    00:06
[2/2] Fetching pfSense-kernel-pfSense-2.3.5_1.txz: 100%   15 MiB 416.7kB/s    00:37
Checking integrity...Child process pid=89665 terminated abnormally: Segmentation fault

Are you sure, that you get a WAN address from the router?

I mean, be sure, if the router can and works in the bridge mode or just does not make NAT. Normally home routers provide LAN addresses. In this case it will be double NAT-ing. (It is not bad).

Try to configure pfSense WAN interface "IPv4 Configuration Type" as "DHCP" and change  to e.g., because many home routers use as LAN.

 Hi pfSense Team, thank you for the superior product!

I am updating the rest firewall node from 2.3.4_1 to 2.3.5_1. Everything was ok, there were no problems during the updating. After restarting I noticed, that the kernel was not up to date:

Code: [Select]
[2.3.5-RELEASE][]/root: uname -a
FreeBSD 10.3-RELEASE-p17 FreeBSD 10.3-RELEASE-p17 #10 6da131e75c7(RELENG_2_3_3): Wed Mar  8 14:27:02 CST 2017     root@ce23-i386-builder:/builder/pfsense-233/tmp/obj/builder/pfsense-233/tmp/FreeBSD-src/sys/pfSense_wrap  i386

Then I tried to update once more. The disk slice was duplicated and it was said, that pfSense-kernel-pfSense_wrap package would be updated:
Code: [Select]
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        pfSense-kernel-pfSense_wrap: 2.3.3_1 -> 2.3.5_1 [pfSense-core]

Number of packages to be upgraded: 1
>>> Locking package pfSense-pkg-FTP_Client_Proxy... done.
>>> Unlocking package pfSense-pkg-FTP_Client_Proxy... done.
>>> Setting secondary partition as active... done.
Upgrade is complete.  Rebooting in 10 seconds.

Unfortunately after the system restarted, the situation repeated. I tried many times to update the system, but it was an infinite loop: updating the system (updating the kernel); restarting; checking, that the kernel was old; updating the system (updating the kernel);..

NanoBSD Previous Upgrade Log shows:
Code: [Select]
2.3.5_1 version of pfSense is available

I have attached complete log file.

Could you please suggest, what can be done to update the kernel too?

Thank you,
Best regards

Hi jimp,

thank you, the simplest solution #3 (
3. Wait until 2.3.5-p1 drops later this week and attempt to update again then and see if it corrects itself.
) has succeeded!

Now the correct version is shown everywhere! :)

I noticed one strange thing during the upgrades (2.3.4_1 -> 2.3.5 and 2.3.5 -> 2.3.5_1). After the first upgrade, everything were upgraded except of the kernel. Rebooting did not help. The kernel was upgraded only after executing the upgrade process the second time. The disk slice was duplicated, and the possibility to go back to the previous version was lost. :(

Best regards

Pages: [1] 2 3 4