There are legitimate reasons for bridges such as bridging two interfaces to create a transparent proxy. That is a legitimate purpose (and it works just fine). You are attempting the equivalent of driving a screw with a carrot. Your switch is a perfectly good screwdriver and it's right over there.

Hi, What are your LAN firewall rules ? Is the rule you showed the LAN interface ? WAN firewall rules ? Floating rules ? DHCP on LAN works - you got an IP ? /mask ? / DNS ? / Gateway ? Why are you hiding lines in your log file ? Are some LAN devices working well = having normal 'Internet' access ? Default settings will work. Did you try the classic solution : save the config. Switch to default. Everything will be fine. Now rebuild your settings 'by hand' and you know now what step not to repeat. Also : Where did you get that version from ? ( to get that one, I have to 'borrow' if from the local ancient science museum )

@johnpoz said in Lan errors in with vlan: " the TPLINK TL-SG108PE itself that emits the bogus packet. Something about the way this device drops the tagged 802.11q packet causes the packet to be transformed in such a way as to be seen by as this rouge/bogus packet." Of course, TP-Link is well known as an expert on VLANs.

@Raffi_ thanks for that. I've been advised to try disabling the pfblocker snort rules elsewhere som in trying that now. If it doesn't work I'll try this next :)

add this to /boot/loader.conf.local and reboot # allow multi queue support on vmx hw.pci.honor_msi_blacklist="0"

Thank you. Now I can log in again.

Yes, and knowing how to do that and what it looks like if you're in that situation is a useful skill that may well save your ass! They other situation I see it in commonly is when a network is switching subnets, because the previous one was too small and couldn't enlarged or it conflicts with a remote subnet over a VPN say. Both subnets may be run for some time during the switch over because there are always some systems that have some issue. Still better to avoid it if you can. Steve

There is a bug in pkg that you may be hitting in 2.4.5p1 where the pkg process never closes preventing subsequent packages installing after a restore. Only some packages hit it, notably Squid and FRR may. You can get past it by either killing and package process that has frozen or making a change in the package settings. It should then continue to install other packages. https://redmine.pfsense.org/issues/10610 It's fixed in 2.5. I restore stuff all the time and only occasionally hit that though. If you want complete filesystem backups consider installing ZFS and using snapshots. https://www.freebsd.org/doc/handbook/zfs-zfs.html#zfs-zfs-snapshot Not a GUI option, yet. Steve

@kiokoman I tried that editing directly. It worked, but did not survive a reboot. But this did work: at the very end of "/etc/skel/dot.tcshrc" I added: ... if ( id -u != 0 ) then /etc/rc.initial endif thanks for your help, done!

@johnpoz said in Losing internet since this morning, packet loss and gateway offline: To access your modem, you may need to create a vip on your modems network, say 192.168.100.2 and use that vip via outbound nat to access the modem status page. [image: 1602852028639-vip.png] That source in mine is my local lan 192.168.9/24... So when client on my lan wants to connect to the modem status page pfsense nats that traffic to the vip IP set.. So modem sees traffic from 192.168.100.2 You may or may not need to do that.. Really depends on the modem, etc. Didn't know about this setting. In my case, I had to add an Alias IPV4 address under the interface to access my 4G LTE modem GUI. [image: 1602860010506-cfd5e601-d2c9-4131-8883-494e7da82aa3-image.png]

Same here

Hi, did you find solution for it ? Or I just have to use tcp_outgoing_address directive in the custom options and manually rewrite IP in case of primary wan fail ?

Pfsense and wireless not a good fit, not so much because of anything in pfsense. But freebsd have never really be good fit. If what you want is speed, you want something designed to be a bridge.. There are options to that unifi building to building I linked too. I would never suggest you do anything with a wireless card in pfsense, other than maybe a link to be used as failover wan, or as some sort of out of band access. BTW - you didn't cause anything really, me and @JKnott love to tangle words all the time.. Just friendly button pushing ;)

[image: 1602793762710-1a3034a0-a3b0-4adf-be66-231891d71266-image.png]

@ashima said in OpenVPN tun mode with LAN IP: Are there any security caveats in doing so ? The rule as suggested above led the server believe that the access is coming from within its subnet, exactly from pfSense and it works only if the the source is one of your vpn clients and if you additionally specified the destination port, only for that one application. So if you say, your vpn clients should have access to it anyway, there are no security drawbacks. You also may further restrict access by a firewall rule.