I guess my mechanical brain wanted to see a hardwire to a port that was a physical public IP. That was probably the issue that would not let me see/understand the virtual IP solution.
The Pfsense firewall has 7 interfaces, all bridged under 1 interface called BridgeLAN with BridgeLAN running the DHCP server. I wanted to let only 1 host out the internet without VPN because of GEOIP apps that requiring my country location.
viragomann gave me great direction any I tried his rule direction on every interfaces, what I found out that the BridgeLAN VPN rules superseded all other rule entrys because all the other interfaces are bridged inside the BridgeLAN Interfaces .
So I created the same rule to open that host above the VPN rule in the BridgeLAN rule and it worked as I wanted.
I know there is better ways to do this, and I will take any advice.
Probably the helpdesk service often has to deal with someone not doing his homework, so they probably insisted that my config wasn't ok (despite what I wrote during a whole week of emails ...)
The problem is that this behavior make you a lot of work and steals your time, when you're not really a network expert.
But after reading this thread probably someone gave up in front of your reputation and ... ta-da! ... this morning everything is working fine ( "A change has been made to the receptive antenna, so please check again if remote access is now possible.").
@johnpoz I get the same address it seems. Is there a script command or something that I could use to release the address, wait five seconds and then renew the address? I'm pretty sure doing that at say 04 every night would solve the whole thing, since it's solved by doing that manually.
Or even better, an HTTP command I could send from my home automation (with POST message) that will do it? In that case I could also have a button in the living room so my wife could press it whenever NRK1 isn't working, and then the system would do the rest?
Thank you for the insight and pointing out my miss configuration. I didn’t see it till you said something. Where I had loop back 127.0.0.1 I should’ve had IOTWiFi addresses.
I used the net gate recipes for redirecting DNS and applied it to NTP.
Have a good weekend
Ich habe den Fehler gefunden ! Meine Fresse was ein Staatsakt. Beim Paketmitschnitt sind mir Pakete aufgefallen die zu groß waren für UDP.
Screenshot 2022-01-21 at 14-00-00 pfSense home arpa - Diagnose Paketmitschnitt.png
Das SIP Protokoll ist extrem empfindlich gegenüber Änderungen. Da die Datenpakete zu groß waren wurden diese in zwei Pakete aufgeteilt. Dadurch wurde die SIP Nachricht ungültig und auf der Gegenseite verworfen. Ich habe zuerst mit den MTU Werten der Schnittstellen gespielt. Das hatte aber nichts gebracht. Die stehen nun alle auf 1492. Erfolgreich war die Einstellung der MSS Werte der Schnittstellen auf 1299.
Der Wert soll für verschiedene Scenarien ein guter Mittelwert sein. Hauptsache es läuft erstmal. Feintuning kommt später.
@aihysp those services are a vpn, a vpn is really just an encrypted tunnel.
I am not aware of those 2 supporting inbound traffic through the vpn. But there prob is some services that provide that service.
As to speed through a vpn - yeah not very likely that you would see any sort of speed increase - more likely to see a pretty drastic hit on performance if anything..
As to circumventing geo restrictions to watch services like netflix, etc. While sure that might work for a while, at some point they will prob block whatever IP range your using for the vpn, and have to change to a different pop or even vpn service. Your going to be playing wack-a-mole for sure with that sort of circumvention.. It might work for hours, it might work for days or weeks, or shoot it might work for a year, etc. But more than likely they at some point will block the IP your coming from via a vpn..
@javen Several of us are experiencing and have complained about this issue. Here is my thread on it. I gave up trying to fix it for now so still have to restart unbound after every reboot. Here is a pointer to my thread which may have some additional info for you…
@patch I am learning how to use Haproxy's reverse proxy and using private domain (secret TLS/SNI) to help make the PBX more secure in the DMZ...very interesting...I'll post in the proxy section questions I may have.
si on choisi un routeur avec wifi : ce matériel a de grands avantages
si on veut utiliser un firewall, on a intérêt à disposer de 2 matériels : une box ou un routeur simple, et une borne wifi (de préférence un access-point).
Quand vous avez choisi ce matériel, vous ne saviez pas les contraintes avec un firewall. N'utiliser que la fonction WAN Adsl+sim 4G, ou à l'inverse que la fonction Wifi est dommage et onéreux ...
that is if running 2.6 or 22.01 I take it.. I am looking forward to it myself for my VMs - since my nas virtual machine is qemu based.. I not sure why I had those openvm tools installed - might of been habit from when I ran esxi ;) I have now removed it. And think might update that vm to 2.6 to try out the qemu tools - now maybe my dashboard will show the IP of pfsense, and will be able to shutdown vs having to halt the system from inside the vm.
Well I updated to 2.6, and installed the package and then ran it and now I see IPs on that vm
@dlrqdm You would have to adjust your outbound nat to not nat..
Here to do an example... I created a special outbound rule for my test interface to not be used for nat outbound using hybrid mode.. With my test interface IP 192.168.200.1, set unbound to only use the test interface for outbound.
Sniffing on wan while I do a dns query, which never get answered of course you can see the traffic going out with my 192.168.200.1 address.
You would have to adjust to use your vpn interface, etc..
Well, after a few days using WireGuard in a site to site VPN configuration, I see no adverse affects from the few errors showing on the interfaces (even if they are ticking up slowly). It also looks like the errors aren't necessarily proportional to total traffic / total packets transferred either. For instance, I ran some iperf3 tests through the tunnel recently and didn't see the errors tick up materially during the tests, so perhaps it's only certain traffic that causes errors now and then.
Overall though, I'm quite happy with the performance I'm seeing from WireGuard. I was able to achieve almost 900 Mbit/s transfer speeds through the tunnel using a single iperf3 stream (each site is using a 1 Gbit/s fiber internet connection) - very impressive.
@johnpoz hehe, only my friends and my home systems (Home Automation). My friends know better than go looking for Pron on my systems, they've been redirected to some of the more 'interesting' sites. ;-) They still can't unsee that.
If you went the bare metal way with inline IPS as I recommend, you would get full line rate with no sweat.
Do you have any suggestions where I can get a start on sourcing info to head in this direction?
I appreciate your input @bmeeks and you taking the time out of your day to give me guidance on this matter.
First, you will need to get comfortable working with either FreeBSD or Linux at the command line interface. Both are more or less the same. I would tilt towards FreeBSD simply because that is what pfSense is based on, and FreeBSD is said to have the better network stack.
Install FreeBSD (or Linux) on suitable hardware. As I mentioned, you will need three NICs to make things easy. One is your managment interface and should get an IP address from your LAN. The other two get no address assigned. They are simply going to be input and output ports running in promiscuous mode.
Next you install Suricata on the machine. On FreeBSD, there is a package in the ports tree. For Linux, there are also suitable packages available for installation.
One last thing I will mention is that administering an IPS is a big challenge and requires quite a bit of knowledge and experience. If you are new to this, prepare to be very frustrated initially by false positive blocks. For that reason, you really should run a setup in IDS mode for a month to see what alerts get triggered on your network. You then selectively "tune" your rule set to get rid of false positives. Only then should you turn on the blocking of traffic using IPS mode.
hmmm, I see what you are saying they route between the interfaces. In our small network, we have those vlans listed above with end devices spread out on different switches. I have the Eth 2, and 4 used to ensure routing. Yeah I should have the switches connected but they are not top of the line, and with the costs and this being a nonprofit it is hard to spend that money and even to get the money. I was hoping to utilize the SFP+ ports like I did on the Ubiquity UDM Pro of which we replaced.
I like this unit Netgate, so much better, though...I am now recommending this to everyone.
ass Pfsense nicht checkt, dass die disconnected sind und will kein HandShake machen.
Bezweifle ich stark. Wireguard ist da sehr sensitiv. Wenn du keinen Input vom Client bekommst, sieht er das. Aber da am Cryptorouting nichts geändert wird, macht für mich da ein Neustart auch keinen wirklichen Sinn. Das hört sich eher nach Gegenseite an also die Thin Clients, ansonsten würden das ja alle Clients auf der pfSense haben und nicht nur die.
Zudem ist WG da eigentlich extrem gesprächig. Sobald der eine Verbindung aufbauen kann wird ers auch versuchen. Im "Client" Szenario wirds aber eher das Problem sein, dass der Server den Client eh nie erreichen kann weil hinter NAT, also MUSS der Client die Verbindung wieder reconnecten.
Eventuell irgendwo "verboten", dass sich die IPs ändern dürfen (Verbindung von dynamischen IPs aus nicht erlaubt)?