@Phonebuff: Is the team working on some issue , or is just that ipSec is not getting an love these days ? The forum is community support. So there is no guaranty that you'll get help. If you want direkt help from the pfSense team you'll have to go here: https://www.pfsense.org/get-support/ and pay up.

@Derelict: Why wouldn't you just use a switch with a mirror port there and do whatever you want with the traffic? Wireshark, tcpdump, etc. Certainly easier than trying to be transparent with a proxy. You don't need to hammer a square firewall into that round hole. This or a LAN TAP such as a Throwing Star LAN TAP

I've narrowed the issue to Suricata on the LAN Interface, can a mod please move this thread to the relevant section? I've disabled Suricata on the LAN interface, and it appears to be working fine now, what gives?

Thanks for the responses everyone.  I went back and tried a different NIC and it works.  The Intel 1219-LM NIC is the issue.  I installed Intel's ANS driver software to enable multiple VLANS but it doesn't work correctly.  It even blue screened my Windows 10 Lenovo P51 at one point.  The Intel driver software at the URL below supposedly should allow multiple VLAN assignments on Win10 using the Intel 1219-LM NIC but I'm not having much success. Intel ANS for Windows 10: https://downloadcenter.intel.com/download/25016/Ethernet-Intel-Network-Adapter-Driver-for-Windows-10 I ended up testing with a Plugable USB3-E1000 NIC and specified the VLAN and it worked.  I'm currently working with Plugable to see if they have driver software similar to Intel's ANS so that I can assign multiple VLANs on the same NIC.  If anyone knows how please let me know.  I am using a Plugable USB3-E1000 running the latest drivers.  Plugable had me install the latest driver software located at https://plugable.com/drivers/asix/windows/latest/  but I still do not have the ability to create multiple VLAN's via the Plugable adapter's settings menu.

@captainjackla: I am running 2.4.2 version.  I would like to setup 2 subnets, such as 192.168.1.x and 50.x. Do I need 2 LAN interface cards?  And If I get 2 subnets working, can they still communicate to each other?  Such as connecting a PC or Mac to a printer? Thanks. You either need another dumb switch to hang off an additional interface on the router or you need a VLAN capable switch and create vlans on pfSense and your VLAN capable switch. I carry 6 networks on one interface using VLANs. https://forum.pfsense.org/index.php?topic=142930.msg779126#msg779126

You can achieve this by bridging WAN and LAN interface. But this way you can only use the public /29 subnet on LAN. pfSense is still able to filter traffic, but not to forward anything, of course. If you don't have special reasons for bridging it isn't recommended.

@johnpoz Yes we can take 2 connections from same ISP. My doubt : Since Its a broadband connection 150 Mbps dn & up both ways ,  the contention ratio  is expected to be  1:16  & having same gateway  unlike  a Leased Line Connection  with contention ratio  1:1  or  1:2 . Are  there any issues  that you perceive    &  foresee to crop up . . . ? regards, Ashima

Hi All, Anyone at all?

Thank you, Grimson.  I found my mistake. I failed to map the PPP setting to the correct interface.  In fairness, I thought the list of four interfaces (what the device I am using has), was all that was showing in the selection box…until I discovered there was one entry below the pick box (hidden)...which was the adapter with the VLAN tag bound to it.  For the longest time, I thought when I created the VLAN itself that the parent interface reference was sufficient to make things work...I was wrong. Thanks again!

Agreed.  More details are needed to offer any troubleshooting help. By default, PFsense allows all outbound connections regardless of OS.  My guess is you have either a networking or DNS issue… or possibly both.  However, we won't know anything until more details are provided.

Thanks muppet. So it should be working better, good to get this confirmed. I suspect the firewall, but i will do some testing as you suggests. :)

Fine. put a gateway and a monitor IP address on LAN but don't set a gateway on the LAN interface itself. If it is showing down that means it is not responding to ping. You can only monitor addresses that reliably respond to ping.

All I can say is check again. It is pretty much impossible to have an inside MAC address on a WAN pcap without some sort of layer 2 connectivity between inside and outside.

There is a catch22 regarding the idea to contact Netgate. To contact them I need to open a ticket. Well, no.  As you have already discovered, the Netgate staff are quite active in these forums.  Your problem has already been addressed.

thanks, never worked with bin logs before. But found the problem, pfsense was only running on 443 and somehow the internal CA was missing nginx couldnt load. Changed via viconfig to enable port 80 http, recreated a cert and done. solved -

The openvpn client (at least with PIA) typically does not show the real gateway automatically. If your client / interface got assigned a (e.g.) 10.10.30.5, it may show 10.10.30.6 as the "gateway", which will typically not be pingable. You can manually change the monitor IP to something like 10.10.30.1 or something else on the internet that you know will respond to pings. Global DNS providers (google, openDNS are an example). HTH.

I'm a bit new to this, so let me give this a shot… Please let me know if there are more specific items I need to list. I'm using 2.4.2-RELEASE-p1, DNS resolver with forwarding enabled to Google DNS ipv4 and ipv6 with interfaces set to its default of ALL. Physical setup is a Qotom fanless box with i3 4025u + 4GB ram and quad intel i210 nics as follows: Cable modem > pfSense WAN >|> pfSense LAN+SPAN > Netgear GS108T managed switch (LAN) + Monitoring PC (SPAN) which is separate from my main PC. Packages installed are Snort, pfBlockerNg, ntopng, nut, openvpn-client-export. I tried powering off my main PC to see what how the traffic changes, and 127.0.0.1 now correctly resolves to the hostname of the device that performed the resolution; the target MAC address is still the same however. Originally 127.0.0.1 was resolving to gearssdk.opswat.com regardless of the device performing the resolution.