Heh, I was hoping to get a hint without having to break out Wireshark. But having done it, that traffic seems to be DHCP-related. There is a ton of discovery, requests, offers and NAKs that never end.
[image: cap1.png]
[image: cap1.png_thumb]
If you set a 2.3.x box to see the 2.4.x repos then it won't see packages because the package repos it's aimed at are for 2.4
Understandable. :)
The list doesn't show local packages because of a different bug (fixed on 2.4.2).
Ah! Thank you!
As said above, im curious as why one system of a CARP cluster "automagically" has pfSense-2.3.5 (Meta package) installed while the other still has 2.3.4 (which is correct). Both are still on 2.3.4-p1 as we have to schedule downtimes first with customers. So I don't know where the Meta package change comes from (1) and why the systems (not only this two but 3 others, too) have started changing their update path back to current after 2.3.5 has been released. That's a bit of a mystery ATM as a simple pkg-static update shouldn't change a thing with the selected pkg repo.
Strange…
Thanks a lot for clarifying those other points!
Jens
Actually I've just upgraded a couple test systems here and the xdebug package is removed automatically, so there isn't anything to do manually, just upgrade when it's available.
"However I am unsure as to the level of security it is providing"
In what aspect? Are you trying to control you users outbound access? Are you wanting to look for bad traffic either inbound (that you have opened with a port forward) or your clients talking outbound to something or on your own network between vlans? Like a infected client?
Out of the box all unsolicited inbound traffic would be blocked. To be honest if you feel that deployment of pfsense was an uphill battle.. Advanced security features IPS/IDS is going more than likely just cause you grief other than any added security.. There is a large learning curve on such systems.
"intnet as the internal network for those vms"
This is gibberish… intnet? Not a term...
"but no other machines on the lan"
Pfsense would have ZERO to do with lan devices talking to each other.. Pfsense is a router/firewall - not a switch... Devices all on the same network 192.168.1/24 traffic would not go through pfsense unless it was setup as a bridge..
"but then I fired up another machine on the intnet"
Again not sure where you are getting this term "intnet" it is not a networking term.. Do you mean internal network? internet? What does intnet mean in your context?
Pfsense can for sure just route.. But why would you not firewall as well.. If you want to firewall/route between 2 networks and not NAT (network address translation)… Those would be how pfsense would do it between 2 lan networks.. It would really really help if you drew up your network as you want it to be so we could understand what your trying to accomplish vs using some nonsense term.. Been in the biz 30 some years and I not sure what you mean by intnet.. I would guess either internal network or internet.. But can not be sure from your context, etc.
Oh interesting. In my understanding if there was only one user this attack would not be possible and possibly if the user logging in already has the maximum escalated privileges this attack becomes much less useful. I understand that these are likely small enough use cases they would not warrant mitigation for the login page token expiry.
Thanks for the explanation!
That config means advertise a default route and the correct syntax is
network 0.0.0.0 mask 0.0.0.0
So you were missing the mask and also the entry for the default route.
i_p route 0.0.0.0 0.0.0.0 "IP Address of Default Gateway"_
Actually by default pfSense installs with an "allow all" rule on the LAN interface. This will allow traffic to any other interface on the box. When you add a second LAN you will need to copy the default LAN rule to the new interface unless you want to specifically limit traffic.
If you wish to limit traffic between interfaces you would place the "limiting" rule(s) above any "allow all" rule.
[image: LANrules.jpg]
[image: LANrules.jpg_thumb]
Thank you BlueKobold, but i was hoping to make it work without buying any new devices. But if I buy a Cisco Spaxxx what information do I need from my ISP to configure the Spa.
I pretty sure it will run under special set up conditions and something does the trick for you, but how more often you will
be using such work around then how more often or at one day nothing really will going ahead or still along the road based
on many "special" things. And how more often you will stay or match the most common or well known way, how better it
will be running with all other things besides or on top of this.
I am afraid my ISP wont give much information.
You will be able to speak to him and tell him also your wishes and needs and then he must tell you something
about his doings and work. I would give it a shot to see if it will be more easy to go with or another solution must
be jumping in here.
@Areomayo:
The above did not solve my problem alone rather a combination.
What fixed it for me was uploading a compiled version of realtek driver 1.92 if_re.ko to /boot/kernel/ and in /boot/loeader.conf.local add the following line: if_re_load="YES" then reboot and wupti.
I also however tick the 3 Disable hardware offloadings in System - Advanced - Networking
Heres some links that helped me solve my issue including the compiled if_re.ko, i hope it helps others having same problem.
https://bugs.freenas.org/issues/1850
https://www.ateamsystems.com/tech-blog/freebsd-pfsense-link-state-re0-watchdog-timeout-errors/
How did you upload that compiled file to the /boot/kernel? I'm ready to do this and can't figure it out (I'm new to this – obviously).
Thanks!
