The pfSense Store

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.

Topics - JeGr

Pages: [1] 2 3 4
General Questions / pkg source switches from legacy to current
« on: November 14, 2017, 07:51:53 am »

we have multiple systems that are currently forced to stay on legacy-2.3 patch until all kinks are worked out. I have them set to Legacy via the WebUI fine, but noticed, that quite a few have switched back to 2.4-current without anyone changing that (even audit log and backup history shows that change was 10/30 and today, but nothing the last days).

As we have written a simple and small check script that we run via NRPE, I'm trying to understand if that check script has something to do with it. But the only things it does is:

1) pkg-static update (to refresh the local package archive and see if there are new pfSense versions without anyone having to login to the dashboard)
2) pkg-static info pfSense (plus a few greps, sed's etc. to check the installed version of pfSense via the pfSense meta package)
3) pkg-static search pfSense (plus greps etc. to check the new pfSense version via their meta package version number)

As all of these are non-changing pkg-static calls, I don't see how they could trigger a upgrade/downgrade of the followed version. But I've clearly spottet change in the syslog by:

Time   Process   PID   Message
Nov 14 14:25:01   pkg-static      pfSense-repo downgraded: 2.4.1_3 -> 2.3.5_3
Nov 14 09:31:52   pkg-static      pfSense-repo upgraded: 2.3.5_3 -> 2.4.1_3
Nov 13 10:33:20   pkg-static      pfSense-repo upgraded: 2.3.4_14 -> 2.3.5_3

As no one logged into the system then myself at 14:20 the newest "downgrade" is me setting the device back to the legacy update path. But somehow it seems it has checked not only gotten the new 2.3.5_3 change yesterday but also switched to 2.4.1_3 today without anyone telling it so.

Hopefully someone can shed some light into that behavior :)


General Questions / WebUI, PHP & xDebug
« on: November 07, 2017, 08:55:15 am »
Hi there,

just wanted to ask, if there's a specific reason xdebug module in PHP is loaded on stable releases (like 2.3.5, 2.4.0/2.4.1). As we have a pretty big configuration running (many VLANs, rules etc.) the WebUI can get laggy or slow (or even temporarily non-responsive) so since debugging a bit deeper, we found xdebug running. Disabling and restarting PHP-FPM made those 2 big hosts run way smoother than before, even if they still get laggy, performance has been way better.

So just asking if that was a simple oversight from some development version that made it into stable or if there's specific reason to run it?


Packages / OVPN Client Export automagic
« on: October 16, 2017, 10:50:08 am »

while this was working for quite some time, I can't get any of the automagic settings of the openvpn client export package to work. There are multiple DynDNS names configured that work correctly, OpenVPN is configured for 1194/localhost and a port forwarding is set up on UDP/1194/wan address to localhost/1194. If I manually reconfigure the exported ovpn file and manually enter der "remote" line, the config and setup work as intended.

But as I try to automate the use for more users than just mine, it's a real PITA that every time I export a config it has an empty line where the "remote" line should be.

Anyone any idea why that creeps up? pfSense 2.3.4-p1 (latest 2.3) with current openvpn-client-export package. It is running behind another router in front (transfer net with private addresses in between) so we try to use "automagic ddns" for that to work.


Installation and Upgrades / Packages locked in v2.3.x?
« on: October 13, 2017, 03:17:18 am »

as far as I remember 2.3.x was told to be supported further down the road for a few reasons, so upgrade to 2.4 is encouraged but not mandatory or essential, or is it?
Just wanted to upgrade two packages on a 2.3.4_p1 installation with error

WARNING: Current pkg repository has a new OS major version.
         pfSense should be upgraded before doing any other

So any package update incoming is locked until the unit is updated to 2.4? Have I missed an announcement?


OpenVPN / OpenVPN using wrong Gateway to connect?
« on: March 09, 2017, 08:58:15 am »

we have a setup with a client who is using 5 Dial-In connections as WANs. So WAN, OPT1, OPT3 and OPT4 are DialUp Lines that connect via a router in front, so those networks have pfSense configured as .2 and the dialUp Router as .1 (, etc. you get the picture).
Only difference is OPT2. This one has a modem in front and is using a VDSL line via PPPoE directly and he gets a static IP on that one!
As the customer also runs a package like siproxd which relies on said static IP of OPT2, he made OPT2 the default gateway. All other WAN Links (WAN, OPT1, OPT3, OPT4) have their corresponding .1 as gateway set up correctly.
Now we configured 5 OpenVPN tunnels to a single server which is also running pfSense. All Tunnels are configured to use their specific Interface (WAN, OPT1-4) to connect to that server.

Now the strange part: I see every tunnel connecting and working BUT: WAN and OPT2 are connected via OPT2s static IP :o Somehow the OpenVPN tunnel configured on WAN isn't using its corresponding gateway but instead uses OPT2 to connect. As he uses those 5 lines to up his bandwith to said server, this is contra productive as now traffic on WANtunnel and OPT2tunnel are sharing the same interfaces (OPT2) bandwith instead of using WAN. Strange enough, all other Uplinks (OPT1,3-4) are working without hiccups and are shown with other IPs as remote IPs on the status page of the server's pfSense Dashboard.

We actually got it right about 2 times after we killed both connectivity on wan and opt2 and re-dialed PPPoE on OPT2, but after a while if you check you see WAN back with the same remote address as OPT2.

Is there anything to force OpenVPN to use a certain gateway outbound to connect? Or any clue about why only WAN is using OPT2 instead of its own gateway?


Installation and Upgrades / 2.3.3 Patchnotes question
« on: February 21, 2017, 02:13:38 am »
Hi all,

I'm curious about

Do not sort interface menu entries for consistency with other GUI instances #6753

and the info in the corresponding bugtracker item.

As I read the last messages in redmine, I was under the assumption that

Commit reverted.

would indicate, that the change was rolled back and not be brought into the 2.3.3 Update.
It may seem trivial to most users, but we run datacenter clusters with multiple VLANs in the range of 20-40 interfaces and that change would be really quite annoying. We named the project VLANs according to their VLAN-ID and project name vXXX_name and would now have to "search" in the menu opposed to the normal sorted order, where you find an interface quite easily. We already were hoping the ticket would result in e.g. the Firewall Rules Dropdown (that only appears if there are too many interfaces for tabbing) be sorted accordingly, as this is hard to search in day to day operations.

As it states in we have quite similar setup, where VPN interfaces added to projects are sorted to their project interface by naming it accordingly. I can see the initial thought behind not sorting as the order of the interfaces is relevant with CARP setups, but as the interfaces/assignment screen already shows the "true" order - that IMHO is irrelevant in other day to day operation usage - I'd really like to see some sort of switch in the UI to activate sorting of the main menu as well as e.g. the rules dropdown or other dropdown menus that include the interfaces to sort for better overview.

If someone could clarify the last message of this ticket (change reverted) to the changelog of 2.3.3 that'd really be appreciated.
Thanks a lot for the hard work!


OpenVPN / Problem with tap tunnel to VMware App
« on: February 04, 2017, 02:46:44 pm »
Hi all,

as much as I don't like it, I'm forced to setup an OpenVPN tap tunnel between a client's network and an isolated VLAN inside our own infrastructure. Our side is running a virtual vmware appliance (the pfSense OVA image), the customer's side is hardware. Both sides need to run with the same IP address range, so a bridge-style tunnel is the only thing that will work.

What we did:

Server side (our side):
- setup virtual pfSense
- created WAN / LAN interfaces
- LAN IF is only activated, all other things to none
- created OpenVPN tap Server
- added the ovpns interface and activated like LAN interface (only active, all other things to none)
- created bridge interface with LAN and VPN interfaces as members
- activated bridge interface and bound local IP to 10.x.y.17/24
- added firewall rules to bridge0 to allow any traffic

Client side
- configured WAN/LAN interfaces on hardware
- LAN IF is only activated, all other things to none
- created OpenVPN client setup
- added the ovpnc interface and activated like LAN interface (only active, all other things to none)
- created bridge interface with LAN and VPN interfaces as members
- activated bridge interface and bound local IP to 10.x.y.14/24
- added firewall rules to bridge0 to allow any traffic

The OpenVPN tunnel is signalled as up.

What is working:
- After enabling promiscous mode on our virtual vmWare VLAN, a test-client attached to the VLAN net, that is bridged to VPN is able to ping the .17 on the bridge of the server.
- PC on Client side is able to ping the bridge interface's .14 IP

But that's as far as it goes. Neither test client is able to ping the other (we have .122 on one side and .222 on the other side to test, neither one is able to ping or access http/s on the other client, nor ping the remote bridge interface).

Is there anything special perhaps in the VMware part that is still blocking and not working as it should?
Any other help in setting up a TAP-style tunnel between two LANs?
The solution is only temporary but needed badly! Any help'd be appreciated.


IPsec / IPSEC Tunnels restarting when adding VLAN or interfaces?
« on: February 02, 2017, 07:25:17 am »
Hi there,

I just noticed, that pfSense (2.3.latest) is always restarting all IPSEC VPN Site2Site tunnels when I'm adding an interface or new VLAN. Even if the interface/VLAN has nothing to do whatsoever with the configured IPSec networks or interfaces. The service is configured on WAN which we don't touch at all, so I'm curious why it always stops and restarts all tunnels? OpenVPN tunnels or roadwarrior servers aren't affected at all, so I find the kind of strange behavior.


Deutsch / Neues Hardware Sticky Topic
« on: January 23, 2017, 07:14:00 am »

ich habe die vorhandenen 2-3 HW Themen hier "abgehängt" (da dort auch schon länger nichts neues mehr geschrieben wurde), aber um die Hardware Themen nicht in Vergessenheit geraten zu lassen, ein neues Sammeltopic geschaffen. Dort sind die vorhandenen "Megathreads" hinterlegt mit Link und kurzer Beschreibung. Dort sind auch bereits zwei neue hinterlegt, die neu hinzukommen werden (wie mir zugetragen wurde). Sollte jemand das als Ansporn auffassen, seine Lieblingsplattform näher und detaillierter vorstellen zu wollen, bitte gerne. :)
Bitte dann aber das Thema entsprechend benennen und mit [Hardware] Prefixen, dann kann ich das Thema später gern mit in den Thread aufnehmen.


Deutsch / [Hardware] Sammlung von Tests, Beschreibungen & Tipps
« on: January 23, 2017, 07:04:25 am »
Um die einzelnen Hardware Topics hier nicht überwuchern zu lassen und die Themen aber nicht in Vergessenheit geraten zu lassen, verlinke ich sie hier in diesem "Master"-Posting, so dass jeder was dazu finden kann. Vielleicht spornt das ja den ein oder anderen hier ebenfalls an, mal einen Thread zu Hardware/Appliance X zu starten, bei dem dann diskutiert werden kann :)

APU2 Sammelthread:
Fakten, Erfahrungen, Details

APU1 Sammelthread:
Fakten, Erfahrungen, Details

FW-7525D Sammelthread:
Testbericht, Bilder, Fakten, Details
-> coming soon

<Neues Gerät> Sammelthread:
Testbericht, Bilder, Fakten, Details
-> coming soon

NCA-1010B Sammelthread:
Testbericht, Bilder, Fakten, Details

Routing and Multi WAN / best practice with multiple subnets on WAN
« on: November 23, 2016, 10:45:54 am »

a customer installation got additional IP ranges (/28s and /29) for their setup. Problem is, the ISP won't route them to their already existent /29 subnet but configured it by using the first IP as their GW address. As WAN and default GW are now on the first /29, how can we best catch those additional subnets/IPs and route them back via their own gateway?


General Questions / two nodes with v2.3.2 - ssh faulty on one?
« on: September 23, 2016, 05:20:31 am »
Hi all,

as per topic title we installed two new nodes with pfsense 2.3.2 (latest stable) and imported our configuration. Besides a few minor problems with VIPs or packages from the old version, this went fine.
We have a third machine installed with Ubuntu 14.04LTS which is configured to SSH into both nodes with a specific user and via SSH key. That was running smooth for the last 3 years. After the two new nodes were brought in and replaced the old machines, I now have a strange effect:

The new node fwl01 is working fine. The server (crimson) is ssh'ing into it and scp'ing some files. Great!
The other node fwl02 is working - 1 out of 10 times. :O If I manually hop onto crimson and just call a simple "ssh fwl02" I get a connection at about 1 out of 10 times. SSH debugging mode didn't work either, the server simply doesn't get a response from pfSense on the other end. pfSense itself logs that access with a strange SSH failure:

Sep 23 11:40:11 fwl02 sshd[94279]: fatal: Fssh_ssh_dispatch_run_fatal: Connection from <IP> port 38615: Operation not permitted [preauth]
Sep 23 11:43:29 fwl02 sshd[28060]: fatal: Fssh_ssh_dispatch_run_fatal: Connection from <IP> port 58669: Operation not permitted [preauth]
Sep 23 11:59:00 fwl02 sshd[66932]: Accepted publickey for nbackup from <IP> port 58670 ssh2: RSA SHA256:9OtuB6wUUNpHyZSNB/B+BG2nlFUr9WvGDoGw9caQY7Y
Sep 23 11:59:00 fwl02 sshd[67355]: Received disconnect from <IP> port 58670:11: disconnected by user

As can be seen, the first two connects were faulty, the one a few minutes later got through and actually worked. I can reproduce that at will on that server with normal SSH as well as SCP. As Ubuntu 14.04LTS already ships with ED25519 support, new(er) SSH KEX, MACs or Ciphers shouldn't be a problem here. Additionally fwl01 seems to have no trouble at all connecting with crimson. Even if you fire a dozen ssh requests at fwl01, it answers every one of it. fwl02 not so much. As they were both installed from the exact same USB Image and got literally the same configuration (as they are running in a CARP cluster scenario) I'm out of clues whatsoever triggers such a phenomenom. Never had problems with pfSense' SSH implementation at all.

Any clues?


CARP/VIPs / CARP VHID question
« on: September 20, 2016, 08:16:02 am »

just wanted to drop a quick question about using unique VHID. Am I correct in assuming, that VHIDs must only be unique on something like the same physical interface or same logical VLAN?

Background: We have a new cluster setup with two WAN uplinks each (WAN1/2), SYNC, Management Interface and DMZ Trunk. The DMZ trunk are two 10gbps lines (LACP LAGG interface) that has multiple VLANs (~50). As we want to deploy dual homing addresses (IPlegacy and IPv6) that would result in around 53*2 CARP VIPs. As the number of VLANs will add up (every new customer project is getting one) the number of VHIDs won't be enough (255).

So we thought about just using VHID 4 and 6 on those project VLANs on the DMZ as those networks are completely controlled by us and no other VRRP/CARP/Multicast Setup should reside there. It was my understanding that the same VHID only causes havoc when they are discovered on the same network (like same VLAN or interface).

Is that a correct assumption and way to roll? On both WAN uplinks I have to deploy another VHID as the other side uses Juniper Switches also using VRRP so I have to check with them for not colliding. Sync doesn't need CARP. So would it be a viable alternative to run the v4 CARP with vhid4 and the v6 CARP with vhid6 on all those pesky VLANs?


webGUI / form field problems with latest chrome version?
« on: September 20, 2016, 06:59:43 am »

we are using the latest pfSense 2.3.2 and just encountered a weird bug with latest chrome version (

Quite a few form fields like the Source / Destination Address fields in "Firewall / Rules" can't be filled anymore. The thing that tipped us of that it isn't directly related to pfSense but the theme was the error message being a Javacript popup box and being in german instead of english.

Looking into the Chrome Developer Console we saw that it has a problem with the pattern="..." regex and finds it wrong or erroneous. Result is that you can't fill in a IP address or IP network anymore (e.g. and dropdown /24 will provoke the error message attached).

Any news on that? Is that a general bootstrap or chrome update problem?


Deutsch / [Dev] Abfrage aktueller pfSense Version
« on: June 23, 2016, 10:45:43 am »
Hallo zusammen,

da wir gerade selbst vor dem kleinen Problem standen, dass eine Kundeninstallation die wir betreuen "unbemerkt" nicht aktualisiert wurde, haben wir eine kleine Suche betrieben. Zum Teil ist das momentan so, da man die neuen kleinen Patch-Schritte kaum mitbekommt außer durch Zufall im Blog, allerdings wurde 2.3.1_5 zumindest nicht auf den Mailinglisten announced und alle paar Stunden Forum, Blog oder Dev-Tracker schauen ist mühsam. Da man leider auch keine Mail erhält bei einem Update (das wäre noch eine schöne Option), und wir oftmals Kundeninstanzen monitoren, wollten wir was basteln, das den aktuellen und den installierten Stand der pfSense remote auslesbar machen kann. Schlußendlich haben wir das dann auf 2 Befehle runtergebrochen:

Code: [Select]
# new
# just check the meta package but ignore the -builder package
pkg search pfSense | grep Meta | grep -v builder | cut -f 1 -d ' ' | cut -f 2 -d '-'

# outputs

pkg info pfSense | grep Version | awk -F': ' '{print $2}'

# outputs

Beide Befehle können problemlos von einem "normalen"/DummyUser per SSH ausgeführt werden ohne root/sudo zu benötigen und ohne dass zusätzlich ein Paket zur Verfügung stehen muss. Baut man sich dies nun noch zusätzlich so, dass das Ganze via SSH und PrivateKey läuft und legt eine entsprechende Regel auf dem WAN Interface der KundenAppliance an (SSH nur von uns erlauben), kann man auf dem Monitoring System sich recht einfach einen String-Vergleich (oder wer richtig gut drauf ist auch einen Versionsvergleich basteln auf Major, Minor, Release, Subrelease IDs ;)) bauen, um abzugleichen, ob die aktuelle Version noch mit der übereinstimmt, die das System gerade zur Installation anbieten würde.

Vielleicht ist das ja für den ein oder anderen von Interesse, der sich so eine kleine Gedächtnisstütze bauen kann/will, ob seine Systeme noch aktuell sind :)


Pages: [1] 2 3 4