Default rules on LAN, only the one rule on OPT. A device on LAN is unable to ping a device on OPT. A device on OPT can ping a device on LAN. Lan: [image: 1579993565420-lan-rules.jpg] Opt: [image: 1579993610540-opt-rules.jpg] Devices on both LAN and OPT are able to ping a host on the internet.

@hamidjutt97 You could look here: https://docs.netgate.com/pfsense/en/latest/book/bridging/index.html

@peterwilson_69 For anyone else reading this post, I also had to update my switch settings to accept tagged (VLAN) traffic on the relevant ports of my switch.

@JKnott I think you misunderstood. [image: 1579857661249-nat-problem.png] The 192.168.1.0/24 is 1 lan over a layer 2 tunnel, so using the same IP's in 2 different net does not cause the problem. Connecting from the same place. I can connect to the server 192.168.1.53:8080 I cannot connet to the server 192.168.1.50:3389

I have no where close to the amount of into about what your trying to do... I suggest you consult https://docs.netgate.com/pfsense/en/latest/firewall/virtual-ip-address-feature-comparison.html But yes normally that type is what you would use.

I did at one point have the same fqdn in 2 aliases, however after removing one instance of the duplicate it didn't help. The one thing I'm doing that maybe it doesn't like is have 2 fqdn's that may at times equate to the same IP. I did see a post about the multiple FQDNs and I tried the adding individual aliases, and then one alias that referenced the other aliases and after a restart my tables looked better and had correct IPs, but I ran into another issue where it was now blocking my connections for some reason. And I had multiple rules, one for the combined alias, and another similar (different port forward) for one of the single alias items, and still another one another of the single aliases for another port and none of them were working. These were rules that were working a day before and the only change was the source address alias used. I may try the upgrade to 2.4.5 when I get a chance, but i'll have to see what's involved.

What dns do you clients point to - do it there! Are you currently using squid? On pfsense?

In the Unbound Advanced Settings: [image: 1579612090157-selection_763.png] The logs will get VERY busy when you enable that so you will need to check them immediately after trying to connect. Steve

I guess you already have a working LAN adapter on pfsense and OPT1 is your additional lan network. if that is the case then please create a new firewall rule to allow packets to pass(which you told you created already) and then in your newly created firewall rule , try changing/selecting the protocols which should be set as any by default).

@FoolishlyWise I haven't used multi WAN. However, IPv6 supports having multiple ULA prefixes on a network. If done with separate routers, you can assign a priority to one. Perhaps you could set up 2 instances of pfSense in virtual machines, each with it's own tunnel. Then you could set the priorities on the Router Advertisements page. IPv6 has a lot of improvements over IPv4 but, unfortunately, the widespread use of NAT has created a lot of bad habits.

well yeah if your using a pppoe connection you would have to create vip on your wan (physical) interface to let pfsense know it can talk to that 192.168.100 network, and nat to its 192.168.100.2 say address to talk to it.

Thanks jimp. was just looking for additional firewall protection for a legacy bespoke FTP device. I'll see what I can do with Suricata rules.

I have somewhat of same issue, a bit different. I am able to block my IOT LANk from accessing my home LAN but for some reason cannot prevent devices on the new IOT LAN from accessing PFSense GUI/ssh-22. (the 3rd rule in the list below, where all the other rules there do work, just not the 3rd one) [image: Untitled-1236550.png]

Just remove those tplink devices from your network - I do not trust them at all to understand isolation of vlans... When they will not let you remove vlan 1 from a port.. But let you assign another untagged vlan to the port - they do not understand how vlans are suppose to work. Don't buy their products is the only way to get them to understand it seems.

Thanks for the quick reply! I have created Feature Request #10186. I'm afraid I missed to set the category and I do not seem to have the rights to change it after pressing create. It looks as if the solution that you propose could be implemented with a small change to filter_generate_user_rule($rule) in filter.inc around the lines if (!empty($rule['tagged'])) { $aline['tagged'] = " tagged \"" .$rule['tagged']. "\" "; } A small change to the input validation in firewall_rules_edit.php would also be required to allow the value of the "tagged" field to start with an exclamation mark. I will likely spend a few moments to write the code and patch my current installation of pfSense to enable this feature. Would it be of use to you if I clone the GIT repository and send in a patch file (of pull request) with my changes?

I suspect the available options depend on a lot on the size and type of infrastructure that you have as well as what you want to achieve. If you have a relatively small infrastructure with managed switches, you should be able to tack down where the offending device is connected. Start by identifying the MAC address of the device (e.g. by pinging the IP from a computer on the same network and inspecting the ARP table of the computer you pinged from). Then track down the device by looking for the MAC address in the forwarding tables of your switches. You may end up at a WiFi access point, but then at least you know that the offending device is connected by WiFi and should be able to find out a little more about the device from your WiFi access point admin interface. Another, possibly simpler, option could be block the MAC address in your switches and access points, effectively removing the device from you network. This should remove the problem (provided that the device does not change MAC address). It is also likely that the user/owner/administrator of the device will sooner or later turn up to get help with his/her network connection, thus helping you find the device. Disclaimer: I am not a network or pfSense expert - these are just my 2 cents. Hope it might help nevertheless.

Does Customer A actually need to talk to Customer B ? No, my bad, still figuring things out. Your advice of giving the customer net access to the customer address seems like the best solution, thanks! BTW you can drag screenshots into the chat window. Didn't know that, thanks. I solved the routing to the servers by giving the customer VLANs access to the proxy host. Seems more elegant than routing it out via the internet and back. I'm open for other solutions. Final customer rules as follows, please feel free to suggest enhancements. [image: 1579025654591-screenshot-2020-01-14-at-19.14.09-resized.png]