@stephenw10@bingo600@stephenw10 The issue is fixed now, what I did is I went back to the console and reassign those interfaces to their respective static mappings and rename those three interfaces to random names and renamed them correctly and same thing with their DHCP ranges.
Sure but not configured in pfSense. The firewall has to allow the incoming connections from the VPN client to the VM and once that connection is open the customer can do whatever the server allows.
You need to configure the server to allow uploads only.
db:0:kdb.enter.default> show pcpu
cpuid = 3
dynamic pcpu = 0xfffffe007f12e380
curthread = 0xfffff8020ef64740: pid 67417 tid 100250 "unbound"
curpcb = 0xfffff8020ef64ce0
fpcurthread = 0xfffff8020ef64740: pid 67417 "unbound"
idlethread = 0xfffff80004340740: tid 100006 "idle: cpu3"
curpmap = 0xfffff8020e6cc138
tssp = 0xffffffff83717758
commontssp = 0xffffffff83717758
rsp0 = 0xfffffe004d5b6cc0
kcr3 = 0xffffffffffffffff
ucr3 = 0xffffffffffffffff
scr3 = 0x0
gs32p = 0xffffffff8371df70
ldt = 0xffffffff8371dfb0
tss = 0xffffffff8371dfa0
tlb gen = 589816
curvnet = 0xfffff8000408ba80
Tracing pid 67417 tid 100250 td 0xfffff8020ef64740
kdb_enter() at kdb_enter+0x37/frame 0xfffffe004d5b65b0
vpanic() at vpanic+0x197/frame 0xfffffe004d5b6600
panic() at panic+0x43/frame 0xfffffe004d5b6660
trap_fatal() at trap_fatal+0x391/frame 0xfffffe004d5b66c0
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe004d5b6710
trap() at trap+0x286/frame 0xfffffe004d5b6820
calltrap() at calltrap+0x8/frame 0xfffffe004d5b6820
--- trap 0xc, rip = 0xffffffff80f712cc, rsp = 0xfffffe004d5b68f0, rbp = 0xfffffe004d5b6900 ---
in_pcbdetach() at in_pcbdetach+0x3c/frame 0xfffffe004d5b6900
udp_detach() at udp_detach+0x93/frame 0xfffffe004d5b6930
sofree() at sofree+0x245/frame 0xfffffe004d5b6960
soclose() at soclose+0x30d/frame 0xfffffe004d5b69c0
_fdrop() at _fdrop+0x1a/frame 0xfffffe004d5b69e0
closef() at closef+0x23e/frame 0xfffffe004d5b6a70
closefp() at closefp+0xa0/frame 0xfffffe004d5b6ac0
amd64_syscall() at amd64_syscall+0x387/frame 0xfffffe004d5b6bf0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe004d5b6bf0
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x800c8f47a, rsp = 0x7fffffffd978, rbp = 0x7fffffffd990 ---
The msgbuf.txt file in your redacted archive appears to be damaged, I can't check it.
That backtrace is not one I'm familiar with. It would be useful to compare that with the backtrace from other crashes. If it's close to identical it's probably a software issue. If it's a hardware problem they will be far more random.
It depends entirely on what bandwidth you need over the VPN.
Really I would suggest just testing it yourself as everyones traffic is different. Start small and go up. OpenVPN is single threaded so you may find the smaller instances work fine for you and larger instances don't give you much.
Usually it's because after completing the wizard ntp kicks in after a few minutes and the session cookie then becomes invalid and it expires the session. You should be able to just reconnect but the CSRF check will complain.
and made sure to set the MAC address in pfsense to 63:e3.
That seems suspicious. You should not need to set the MAC address if it's using a dedicated NIC (pass through). If you did it implies something else is using that MAC and spoofing it in pfSense will break layer 2. It sounds like you may have ended up with ESXi using that MAC.
Yes, it is still the plan. Unfortunately it has taken longer to get the required pieces in place and tested that originally expected. It's hard to guess a time scale with any accuracy at this point. It will happen!
To isolate devices on a Netgate router with switched ports, you can set the ports to act like separate ports. Each is its own network. Then devices connected via those ports are isolated unless you set firewall rules allowing them to talk to other networks.
At 100 Mbit/s I'd fully expect the 2100 to be fine, running IDS. At 2000, I'd expect it to have problems. Not quite sure where the middle ground is but I'd guess around 300-500 Mbps.
IDS (Snort/Suricata) is set up on an interface on the router. So it can be set up on one of the ports, generally LAN.
re: IDS with VLANs, see this thread. So if you run Snort on LAN it should function for any of the VLANs that are set up on any of the LAN ports as well.
Without the GUI, it's almost impossible to see real issues.
WITH the GUI, the problem quickly became visible:
Long ago, I created a final FW Rule on WAN allowing me to control logging of dropped packets.
New Port Forward configs create FW pass rules on WAN... and places them at the end. Which means the above block rule means none of the port forward pass rules do anything ;)
You can just port forward the public IP to it for the required VPN ports. Or use 1:1 NAT for all ports. You could easily end up with some asymmetric routing though if the Firebox doesn't handle it correctly.
Do you actually need a /16 on that LAN interface?
Do you actually need those LAN side gateways defined in pfSense?
They would only be required so that pfSense can access 192.168.0.0/24 for example.
The isolation works as expected. When logged in to regular or Guest SSIDs I cannot ping or discover devices on the other network. That thread you referenced is a couple of years old. Apparently I bought my ORBI and satellites (last year) after the isolation issue was resolved or it was resolved in an update prior to my using the Guest SSID.
And thanks for your answer to my previous question about using a separate NIC interface for WiFi on pfSense. Doing so I’ll be able to ensure control and isolation for my IoT devices and leave my Guest SSID just for….. guests.
Thanks Steve, I'll do some more tests. I understand now I don't need DHCP but using it ensures portable clients will get the PfSense DNS resolver and not their default network settings. When they get on another network they will get their IP address and DNS as normal. I think this has been my problem - Knowing when DNS lookup is coming from PFsense or from the VPN private DNS servers direct. My Windows setup is using my preset fixed IPs and specified DNS servers which are Google or the ISP. Big mistake! I hadn't thought about DHCP with static lease mappings but I'll research. I don't know if that will allocate the IP address I want unless PfSense can use client MAC addresses. When I do a DNS leak test, all my external IPs show as the VPN provider along with their DNS addresses looking similar to their IP address. I don't see Google!
Without using the wrong network speak I'll explain what I and many others may want to achieve:
Small home networks using standard ISP supplied routers can be compromised by the addon 'Smart' clients that people are now just plugging in without considering DMZs or sub nets. Some U.K TV streaming (BBC & Netflix) and bank sites look for the public IP address and geolocation to allow access to their services. VPN providers using shared and rotated IP addresses are often blocked. In a family home network the ability to block websites or non-approved connected clients is important.
My pfsense setup at the moment is:
Local Lan for PCs using fixed IP addresses. A small block of IP addresses is assigned to 2 firewall Aliases - 'Pass to VPN' or 'Bypass VPN' to WAN public IP.
A DMZ interface with an IP address range for Smart TV, Media box and internet connected hard disc recorder. The DMZ accesses my Public IP. Any packets to or from the LAN are blocked. I regard the DMZ as low security.
A wifi interface connected to the LAN on a fixed IP using VPN.
This works for routing, blocking and allowing traffic, but I can't achieve DNS filtering. If I use DHCP fixed static mapping wouldn't there be uncertainty that another client could get the wrong IP? I may be dumb but it seemed to me that unless Pfsense could get a client MAC address it can't reliably use the rules set for it? I think that's why I concluded each client would need a fixed IP address and the pfsense DNS server address. On a small home network that's easy to configure for each client unless a wired laptop on a fixed IP moves elsewhere and won't connect wired to a DHCP router. WiFi connections aren't a problem because each connection on Windows defaults to DHCP. I'd like to use DHCP on PfSense, but I can't yet see how I can achieve selective routing?
Alright I am back online after the help from Netgate support (huge freaking kudos to Alexey Prokofiev). He was able to edit my config from the SG-1000 I had and made it work for the SG-3100. Thanks again for everyone's help and recommendations. Office is back online!
Ok, so it occurs multiple times and not just at boot? Some minutes apart?
Does it log that continually?
That's not a sysctl that is applied at boot then. You have something else on that system actively setting something that's no longer valid. Do you have something else running there? Some other custom script or manually added package?
Based on the the advice above from the other two members sendto error 65 has now disappeared, along with the 172.16.12.222 gateway IP.
You are only not seeing that because you disabled gateway monitoring. I would suggest leaving that enabled and just disable the monitoring action so you are still logging the gateway response.
You might also set the monitoring IP to something else since BTs gateways do not have to respond to ping at all. 126.96.36.199 is commonly used.
If it won't respond to ctl+t at the console that is a hard lockup. I would be looking at a hardware issue at that point. Your setup is not unusual.
I just checked the restart frequency and got this result:
Keep in mind that these log files could have been rotated, which means older records have been purged. In that case, you'll find less results.
Always have a look at the file, as log files are there to be looked at.
Mine was rotated last month, on august 13 :
Aug 13 14:36:00 pfsense newsyslog: logfile turned over due to size>1024K
<31>1 2021-08-13T14:36:03.090423+02:00 pfsense.athome.tld unbound 799 - - [799:0] debug: validator[module 1] operate: extstate:module_state_ini>
<30>1 2021-09-28T02:35:18.370449+02:00 pfsense.athome.tld unbound 45024 - - [45024:0] info: generate keytag query _ta-4f66. NULL IN
We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.
Subscribe to our Newsletter
Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.