No directly, no. If you run ping there be sure to specify a count. Any commands run there must have a limited time or output set. Steve

@stephenw10 said in PFSense VLan: Some switches set that for you when you set a port untagged on a particular VLAN. While true - from the entry level smart switches I have played with from netgear, dlink and tplink this not the case.. More fully managed switch do set the pvid for you. I would validate the pvid is set.. Example - I plugged in netgear gs108eV3 I had on the shelf testing something for another thread. I put port 6 untagged into vlan 9 - it did not change the pvid. [image: 1657111056755-vlan9.jpg] Now when I tried to remove vlan 1 I did get a warning.. [image: 1657111098646-warning.jpg] Which is good... But that it let me put port 6 untagged both in vlan 1 and vlan 6 in the the first place is bad.. So yeah validate the ports you put untagged in vlan X, that the pvid has also been set to X and that there is only 1 untagged vlan on the port..

When you have fresh installation of pfSense, there are no rules for WAN, but there are 2 rules IPv4, IPV6 in LAN interface that allow traffic.

@kpucko No, there is only a single OpenVPN log for all. However, you can find out the client or server instance by checking the PID details.

@stephenw10 Hey stephen, I was able to track down the issue to the Dynamic DNS service. I use NoIP to track my ISP changes, so it seems that the Dynamic DNS service was rotating the new IP address and the old IP address which is weird because it only started after I upgraded. Which explains why the connection to the server was intermittent. Thanks for your help.

Definitely not a FireFox issue. The 502 Bad Gateway error message was a bit misleading and, initially, made me suspect our pfSense appliance. I did some further testing and discovered that my host computer would not communicate with the outside world using command-line utils such as: ping tracert nslookup From the ping command, I received the following error code: Ping Transmit Failed Error Code 1231 I found the following Microsoft article on how to reset the TCP/IP stack due to this error code: https://answers.microsoft.com/en-us/windows/forum/all/ping-transmit-failed-error-code-1231-windows-vista/0b3216d3-481e-43ca-b222-e55faf56cac2 So, I issued the commands from the article, then re-booted the computer. FireFox now successfully accesses the pfSense areas: Boot Environment User Management without the getting 502 Bad Gateway error. I have no idea how the TCP/IP stack on my host computer got corrupted and why the corruption only affected FireFox and not Chrome...??? Thank you everyone, for your help!

There is no good way to do that. The only VIP type that uses a different MAC is CARP and that uses a special MAC type the ISP may reject. It also must be configured as static, it cannot be DHCP. The only way I've seen this done is to create a single interface bridge on the WAN. You can then assign that and spoof the MAC and it will pull a new IP via DHCP. However that is a hack. pfSense it not intended to operate like that, you should not have more that one interface in the same subnet. Steve

That is a known bug: https://redmine.pfsense.org/issues/12817 It's fixed in 2.7 and the patch is in the recommended patches list in the System Patches package. Just install that and apply the patch. Steve

Probably this: https://redmine.pfsense.org/issues/13154 Steve

Check the DHCP logs, you may need to enable debug mode. Are you actually being passed a delegated prefix for LAN to use? The gateway Sky send you may not respond to ping. Try setting an external monitoring IP like 8.8.8.8 instead. Sky may require advanced send options as shown here: https://forum.netgate.com/post/1049718 Steve

Yup, a route must exist both ways.

@zkab said in UPS & NUT strategy: @dennypage OK ... I disabled SNMP in pfSense In APC UPS I don't have public community - have entered my own community string (read-only) Running SNMP v1 Go back and make the ro community “public”. You can use a different community later, but for now stay with public. Edit: And please confirm functionality with snmpwalk before attempting anything else: snmpwalk -v 1 -c public 192.168.1.12

Hmm, what if you set a source IP like: [22.05-RELEASE][admin@3100.stevew.lan]/root: ping -S 192.168.18.1 localhost PING localhost (127.0.0.1) from 192.168.18.1: 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.278 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.089 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.085 ms ^C --- localhost ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.085/0.150/0.278/0.090 ms

@jpgpi250 You don't need to. If pfSense was a file server, or web server, then these packages could expose services exposed to the Internet. This would mean that a known bug could be important for you. Or, pfSense is a firewall, so most if not all vulnerabilities are not accessible. You can make the system even more safe by limiting the admin access on the LANs side to a known interface like LAN, and use other interfaces for all your other local devices, or make the admin interface only accessible to the device you use to admin pfSense. Take one example : the openvpn plugin issue : these plugins are not installed on pfSense. You are most probably not using dnsmasq, as unbound, the resolver is the default. Most, if not all of these vulnerabilities are always known to the pfSense Netgate dev team, as they are the one also the ones that contribute to FreeBSD. If a patch is available, they will rebuild the package and update it in the repository. You can run once in a while option 13, as this will update pfSense FreeBSD packages maintained by Netgate. I've automated the scan for available system packages for pfSense with a script. If a package is up-datable, I'll receive a mail. edit : Btw : I'm just another pfSense user. If needed, 'they' will give more info.

SFP modules and fibre usually work more consistently in my experience and present more options in the NIC. That allows you to get modules tested to be compatible at each end. It's possible to get custom DAC cables where each end is programmed for the device it's connected to but waaaay more expensive! Steve

Ah, well that's a good catch! Hmm, interesting. Nothing there really indicates lagg or lacp directly so I guess enabling that is somehow touching some other code...

Update: Its not PPPOE - its IPOE that my Sky provider uses (my bad :)) Also, I have now got this working to some degree in that I can see the WAN public IP on PFSense WAN port. Just incase anyone else has this issue this is how I have resolved it.. Put the VR600 into bridge mode, make sure DHCP, IGMP, Wireless and Firewall are all turned off. Then under Advanced, networking, remove any other connection, then add a new connection, set as VDSL, and specify a VLANID of 101. Below is a link to show this in more detail. [https://community.tp-link.com/en/home/forum/topic/266902](link url) In you PFSense setup.. Under interfaces, WAN.. Make sure you set as follows IPV4 - DHCP IPV6 - DHCPV6 Next select the DHCP Advanced configuration, then look for Send Options. Under Send Options you specify this below: dhcp-client-identifier "abcdefgh@skydsl|1234567890abcdef",dhcp-class-identifier "7.16a4N_UNI|PCBAFAST2504Nv1.0" Next under DHCP6 Client Configuration Use IPv4 connectivity as parent interface = true Do not allow PD/Address release = true Next reboot the VR600 router, you will notice that at first it presents with a local IP, but after about 20 seconds the public IP will appear. Note that the VR600 router would usually display a satellite indicator icon to show that it is connected to the ISP. This is not the case when you are bridging to it from PFSense, this light will not display even when it is connected. I thought it is worth mentioning this. I hope this helps someone :)

@nguser6947 Yes, that's doable with pfSense for sure. pfSense provise multiple ways to route traffic to specific gateways: default route static route policy routing (can be configured in firewall rules) In your case, as I got it, you want to route any traffic over the VPN except that one from devices connected to the specific OPT interface. So you can use the default route and point it to the VPN server, which might be already done, I guess. (Normally the VPN provider pushes the default route to the client.) For the OPT interface use policy routing to bypass the VPN and direct traffic to the WAN gateway. Read the Policy Routing Configuration chapter in the pfSense book for details. Also obey the Bypassing Policy Routing section with the RFC1918 alias if you need to access local destinations from the OPT interface as well, e.g. DNS access to the pfSense Resolver. Remember that a policy routing rule directs any traffic it's matching to to the stated gateway. I.e. if the rule matches you cannot reach local destinations. Therefore you have to an additional rule for local destinations.

@johnpoz Ok then, thanks once again johnpoz