Is this just a dupe of your other ticket? https://forum.netgate.com/topic/160507/pfsense-and-openvpn

@stephenw10 thanks.

@stephenw10 Hey Steve, Thanks for your answer. No, we do not have any VIPs define on that box. The host is connected to vtnet1 arp: 10.1.0.50 moved from 00:5d:73:1e:58:98 to ea:b5:54:89:1c:9c on vtnet1 arp: 10.1.0.50 moved from ea:b5:54:89:1c:9c to 00:5d:73:1e:58:98 on vtnet1 Ah and thanks for your hint: I was false, the mac is not the interface itself but the cisco asa interface. So i think I know where to search. Prox-arp on cisco This is what the routing is like. Default 10.1.0.50 (ea:b5:54:89:1c:9c ) -> 10.1.0.1 Cisco ASA routed 10.1.0.1 (00:5d:73:1e:58:98) But on 10.1.0.50 we do have a route for 10.1.25.0/24 via 10.1.0.2 which is vtnet1 on the pfsense. So the package from 10.1.0.50 should arrive on the pfsense via vtnet1 and should not pass the ASA. So it should be the proxy-arp on cisco which reply for arp query. There is a NAT rule on the ASA pointing to 10.1.25.2 on which i will disable proxy arp now for testing. This should resolve the problem and proxy-arp is not deeded since I use different networks on each segment. Thanks for your advise.

Yup that^. You can't make that page work for https as long as you have any sort of sane security in your browser. Steve

While I don't see UPnP as an enterprise feature ;) Since + will be free for home/lab use.. In that sort of network I can still seeing people using it. I wish the protocol in its present form should just die to be honest. It was and is a horrible solution..

@overcon The web server will send responses to the default gateway. So if the USG is set as default gateway response packets will not be returned to pfSense and you will have an asymmetric routing issue which breaks TCP connections. You can either set pfSense as default gateway on the web server and some other devices you want to use it, or you have to do SNAT on packets going to theme, so that pfSense traslates the source IP into its own LAN IP (masquerading). However, consequently you're not able to determine the real source IPs of accesses on these devices, which may be desireable though on web servers and alike.

@comet424 @azdeltawye do you set that script to run like every hour? No, that simple script just runs continuously. No crontab needed. The loop timer is set to 300 seconds which is 5 minutes. Five unsuccessful pings takes 25 minutes, reboot of the modem is another 5 minutes, so 30 minutes total for a full reset cycle. You could change the timer settings to whatever works for you, I just picked 5 min because it seemed reasonable... I still run that script on a RPi now but my ISP seems to be much more reliable and it hasn't had to reboot the modem in over a year now. Originally when I first implemented that setup I was being subjected to 70+ outages per year...

How are you connected to your work vpn? On your device? What does that have to do with running a vpn server on your router? So your running a ssh tunnel through your work vpn, to be able to get back to your home network?

@johnpoz Oh yeah Thx for inspiration!! Awesome... Not gonna play with config.xml

@stephenw10 That makes a ton of sense. Will try it out today.

@stephenw10 - I already knew what was blocking it, but it's not dropping anything in the log that helps much unless it's going through google analytics on the way... If it is, I'll live without it....

@amaanx5a said in pfSense becomes unresponsive: The firewall still has to read that traffic, process it and send it back out on all the interfaces. All of that requires CPU cycles. Even if I use a switch? No, if you use a bridge as a switch. There is a common misconception that bridging somehow requires less CPU cycles and won't affect firewall performance for some reason. Not really sure where that comes from but just to be clear it does. If you use a switch the traffic never goes through the firewall and it can happily use all it's CPU cycles for more important things like VPNs. And, yes, use OpenVPN for remote access if you can. It the very least move your webgui to a different port to reduce the drive-by connection attempts. https://docs.netgate.com/pfsense/en/latest/recipes/remote-firewall-administration.html Steve

Ok. Yes, no way to do that as far as I know. Steve

pfSense cannot bridge PPPoE to DHCP. Snort cannot effectively see inside the PPPoE stream. Or at least the signatures are not intended to match that so it doesn't see the traffic as expected. Your options here as I see it are either to not run pfSense transparently. Put the Mikrotik in a private subnet on it's WAN. Or move the pfSense box behind the Mikrotik where it can be setup transparently and still see the traffic outside the PPPoE. Or lose the Mikrotik entirely and using the pfSense as the PPPoE client and router/firewall/IPS etc. Steve

@stephenw10 The past two have been the same. Im going to try different ram.

Yes, you can do that. You would need other ports for the two WAN though. Try adding an additional vitual NIC and connecting that to an internal VM. Then try assign that as LAN in pfSense and accessing from there. You probably have a mistake in the NIC pass through if you cannot access the webgui via whatever is LAN currently. Only the LAN interface has pass rules to allow access by default. Steve

Relevant crash report parts. Backtrace: db:0:kdb.enter.default> bt Tracing pid 11 tid 100003 td 0xfffff8000721c000 kdb_enter() at kdb_enter+0x3b/frame 0xfffffe0228ae2520 vpanic() at vpanic+0x19b/frame 0xfffffe0228ae2580 panic() at panic+0x43/frame 0xfffffe0228ae25e0 trap_pfault() at trap_pfault/frame 0xfffffe0228ae2630 trap_pfault() at trap_pfault+0x49/frame 0xfffffe0228ae2690 trap() at trap+0x29d/frame 0xfffffe0228ae27a0 calltrap() at calltrap+0x8/frame 0xfffffe0228ae27a0 --- trap 0xc, rip = 0xffffffff80cd5353, rsp = 0xfffffe0228ae2870, rbp = 0xfffffe0228ae2870 --- runq_add() at runq_add+0x43/frame 0xfffffe0228ae2870 sched_add() at sched_add+0x150/frame 0xfffffe0228ae28b0 intr_event_schedule_thread() at intr_event_schedule_thread+0xa0/frame 0xfffffe0228ae28e0 intr_event_handle() at intr_event_handle+0xce/frame 0xfffffe0228ae2930 intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfffffe0228ae2960 lapic_handle_intr() at lapic_handle_intr+0x3e/frame 0xfffffe0228ae2980 Xapic_isr1() at Xapic_isr1+0xd3/frame 0xfffffe0228ae2980 --- interrupt, rip = 0xffffffff803f18c2, rsp = 0xfffffe0228ae2a50, rbp = 0xfffffe0228ae2a90 --- acpi_cpu_idle() at acpi_cpu_idle+0x342/frame 0xfffffe0228ae2a90 cpu_idle_acpi() at cpu_idle_acpi+0x3f/frame 0xfffffe0228ae2ab0 cpu_idle() at cpu_idle+0x94/frame 0xfffffe0228ae2ad0 sched_idletd() at sched_idletd+0x476/frame 0xfffffe0228ae2bb0 fork_exit() at fork_exit+0x83/frame 0xfffffe0228ae2bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0228ae2bf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Panic: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xffffff378335cdc8 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff80cd5353 stack pointer = 0x28:0xfffffe0228ae2870 frame pointer = 0x28:0xfffffe0228ae2870 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 11 (idle: cpu0) trap number = 12 panic: page fault cpuid = 0 KDB: enter: panic Do all the crash reports you see look like that? If you had a hardware issue like RAM I would expect random crashes. Steve

It's not the firewall, as you say. Both the client and server are in the same subnet so traffic goes between them directly through switch 1. pfSense never sees that traffic at all. Check for a bad subnet mask on something. It would have to be a very small mask though to include, for example, the server and gateway but not the client. It sounds like you have some asymmetric traffic. When you start pinging you get an ICMP redirect sent that then allows replies until it expires. Steve

Like any rule; match the traffic you need, traffic to not NAT here, then set the 'do not NAT' option. https://docs.netgate.com/pfsense/en/latest/nat/outbound.html#disabling-outbound-nat Here you probably don't want to NAT anything leaving the LAN so your rule can be source: any, destination: LANnet or similar. Steve