Yes you can "bridge" interfaces to somewhat simulate a "switch" It is going to SUCK performance wise and completely over complicate the configuration. Are you filtering on each member, are you filtering just on the bridge interface, etc. Oh did I say it SUCKS before compared to an actual switch port - right? If you have a switch - there is ZERO reason to contemplate WASTING a very useful router interface that could be used for you know another network so you could actually firewall between your networks/vlans on your "router" vs using it as a switch port ;) If you need/want a switch on your router/firewall - then buy hardware that actually as built in switch ports. The sg3100 for example, or the 7100.. Pretty sure their other new models coming will also include actual switch ports. Yes you can bridge - No you have no reason to do it.. Is like you CAN if you really wanted to poke yourself in the eye with a stick.. But normally people tend to think this a bad idea.. Same goes for using router interfaces as switch ports via bridging them ;)

Let this thread serve as an example of seeing the problem, setting a maintenance window, and renumbering. It can be a MUCH better path than trying to NAT all the things because you decided to deploy 192.168.1.0/24 or, much worse, 10.0.0.0/8.

@kom It actually seems they made some sort of changes since the last time I did testing over a year ago. I did some new testing before the bandwidth upgrade and noticed these changes.

@derelict Thank you. How to suppress these error messages? This IP is not down, and the device is under our control.

Well i got it to work. installed package "ShellCmd". This package is to simply run the following command at every bootup of the router so that the arp entry is always there. shellcmd: command: arp -s 10.0.0.254 ff:ff:ff:ff:ff:ff where 10.0.0.254 is the broadcast IP of my network ff:ff:ff:ff:ff:ff is the MAC broadcast address. Use this as is! Finally setup NAT port forwarding to 10.0.0.254 and the port you want to use for WOL, eg UDP 9

@sunnyg "What's even more odd is that if I ping the external FDQN when connected to the VPN the packets respond back from the external IP address, so I am pretty that something on pfSense is blocking the request." If that's true, then while connected to VPN, you should be able to browse the FQDN (public IP) of your pfSense box on port 7001, and the target webserver should be there. Unless... your work firewall is blocking port 7001 outbound. Sounds like you'll have to choose... access your internal server or be connected to work (or use a different machine). It's pretty normal to not be able to do both.

@jimp Thanks. I had gotten this sorted out. now im banging my head against setting WOL (wake on lan) to work over WAN(internet). I have that working in my oepnwrt router but im new to pfsense so dont know much. Is that something you know about :) Thanks again.

So you just need to setup a VPN to Azure so the board can connect to an instance there? Steve

@horse2370 i figured it out, i had to set the static lease for freenas and plex also opened port 32400 in the firewal

SCLR is still in development, we will reveal more information about it over time.

You can listen on 1000's of ports if you want on pfsense, you can forward 100's of them... Doesn't matter if your wan rules do not allow for the traffic then they would not be open from outside.

I can see number of lost packets in Wireshark analysis. The ratio between lost and all packets is something like 30/150000. PF shows 0 packet loss during the capture period. This is an example of one sample of course. So.. even if PF detects few lost packets and wireshark displays few dozen, I can't tell which one of those is actually detected by PF. And furthermore should I be worried about lost packets detected by PF anyway? At least some of the lost packets detected by WS I was able to link to one workstation.

Click on the ... and flag post for moderation