Well lets see this problem you say p1 has.. Other than it doesn't work some times..

Much thanks for your patience trying to understand my ignorance and naivete. Here's my interfaces tab: [image: 1545269228845-741230b4-cf10-4bf9-8a8c-273947d7e03e-image-resized.png] And my VLANS: [image: 1545269273005-b24c3799-d7c2-4795-bc8a-9577fcff12e8-image-resized.png] I presently have no firewall rules on the 'LAN' interface, given my topology, and things basically seem to work. I am just so novice at this (it's like moving from an automatic to a manual transmission, quite simple once you know what you'e doing, but hard when you don't) I'm hoping the experts can help me avoid doing something stupid. From a management standpoint, my original gravitation toward floating rules was based on the idea of applying something in 1 place that affects many, since I have the VLAN segments. My goal with VLAN segments is to allow rigid partitioning of the network and get to a point I have private & guest WIFI access via AP's and that nothing can see anything else. I have no trust for IoT devices, so they end up on their own isolated segment. And I want it all routing through VPN (including DNS and anything else) since my ISP is questionable at best. I pay for service, I am a customer, not a product whose privacy doesn't matter. (stepping off soap box)

Pinging is not TCP... If you want to block access to ping, then use a rule that blocks ICMP or use the ANY vs your tcp setting on your reject rule.

If you were wanting to repair an OLD router - you should have a copy of the install media you used to install the OLD router... I have OLD copies of pfsense going back Years... Since I keep a copy of the ISO's that I installed... How do you think I got my banner profile banner with pfsense version 1.0.1 in the background ;) I fired it up on a VM to use specially when they changed to new forum software and could do stuff like that on your profile..

@cloudonline As netblues said, a schematic diagram would help to understand what you try to achieve. As I understood, 91.223.232.XX is connected to the WAN of pfSense and 192.168.1.X is internal. The devices in 91.223.232.XX use another gateway than pfSense. So to enable communication between devices on these two networks you will need a static route on each device which does not use pfSense as default gateway. Otherwise the packets are directed to the default gateway. If you want to enable communication on many devices it is recommended to setup a transit network between pfSense and the outer gateway instead and add a static route for 192.168.1.X to that gateway pointing to pfSense.

Thanks, For anybody interested in trying this via CLI, here is how I did it by adding mit-ttl 4 to the line below: [image: 1545063409344-48d44bc3-e84e-4ea4-8072-d5abc846f7ea-image.png] less /etc/inc/filter.inc | grep scrub $rules .= filter_generate_scrubing(); function filter_generate_scrubing() { $scrubrules = ""; $scrubrules .= "scrub from any to <vpn_networks> max-mss {$maxmss}\n"; $scrubrules .= "scrub from <vpn_networks> to any max-mss {$maxmss}\n"; /* disable scrub option */ foreach ($FilterIflist as $scrubif => $scrubcfg) { if (isset($scrubcfg['virtual']) || empty($scrubcfg['descr'])) { if (($scrubcfg['mss'] <> "") && (is_numeric($scrubcfg['mss']))) { $mssclamp = "max-mss " . (intval($scrubcfg['mss'] - 40)); if ($config['system']['scrubnodf']) { $scrubnodf = "no-df"; $scrubnodf = ""; if ($config['system']['scrubrnid']) { $scrubrnid = "random-id"; $scrubrnid = ""; if (!isset($config['system']['disablescrub'])) { $scrubrules .= "scrub on ${$scrubcfg['descr']} all min-ttl 4 {$scrubnodf} {$scrubrnid} {$mssclamp} fragment reassemble\n"; // reassemble all directions $scrubrules .= "scrub on ${$scrubcfg['descr']} {$mssclamp}\n"; return $scrubrules; Changes were confirmed by: [image: 1545063486217-dec7e2b4-3b5e-4fd8-8edb-900371f0cc6c-image.png] pfctl -sr | grep scrub scrub on pppoe1 all min-ttl 4 fragment reassemble scrub on em0.5 all min-ttl 4 fragment reassemble scrub on em0.10 all min-ttl 4 fragment reassemble scrub on em0.20 all min-ttl 4 fragment reassemble scrub on ovpnc6 all min-ttl 4 fragment reassemble scrub on em0.50 all min-ttl 4 fragment reassemble scrub on em0.60 all min-ttl 4 fragment reassemble scrub on em0.11 all min-ttl 4 fragment reassemble scrub on em0.40 all min-ttl 4 fragment reassemble scrub on ovpnc2 all min-ttl 4 fragment reassemble scrub on ovpnc3 all min-ttl 4 fragment reassemble scrub on em0.80 all min-ttl 4 fragment reassemble scrub on ovpnc4 all min-ttl 4 fragment reassemble scrub on em0.7 all min-ttl 4 fragment reassemble I am actually going to revert this change and use a separate VM for the multicast reflection and manipulation I am trying to achieve to have a Set Top Box and Speakers in a separate IOT VLAN.

@johnpoz thank you!

@johnpoz said in Is this most likely not a firewall issue?: Yes it needs TCP 32400, not UDP 32400.. Do you not know what those mean? Well I didn't, until I just "googled" it.

@raafat and? Here is missing some information to do a better diagnose. Please mind to write many details of your issue when posting for a query to community. What is kind of browser your use. This happen with other browsers? You don't try to test? And size of page is right? You can trim page size by pressing CTRL and +, or CTRL and - once you get bigger or smaller size of text on page. Bye

@stardust said in SCHOOL QUESTION: Hello everybody, i have 2 subnet in 2 interface, A and B. (one for interface) (no vlan) If I allow all traffic in outbound from A to B, but in B i block all traffic in incoming. In B, the traffic are blocked or not for some reason? Is for school purpose! Thanks! Hi, and welcome stardust. Whatever you like to know, this should be your first read when You need help from strangers on the internet. https://www.pjrc.com/how-to-get-tech-help-from-strangers-on-the-internet/

WAN 10.10.0.0/16 * * * 10.10.226.254 * LAN Network WAN 172.16.0.0/16 * * * 10.10.226.254 * Wireless Our network is behind a larger private network. Interestingly enough I failed over to our backup box and it is working as expected. I may have some hardware or config issue on the primary, but they look the same. Perhaps another reboot will help the situation. A little background... I was having an issue with the backup box not connecting to the web. Updates, packages etc... I thought I had it fixed by natting "This Firewall (self)" to interface address. I have removed that while troubleshooting.

The NIC had 2 addresses and the gateway was set for the secondary address. Utilizing the correct gateway resolved the issue. I appreciate the time you took to respond and assist, that's very kind of you.

@netblues said in Looking for advice for what to do when WAN is behind NAT with RFC1918 block required: Well, its both. Picture this. Someone on the internet can spoof an rfc1918 ip and try to connect to your public ip. Since upstreams don't filter this (and its a big issue) their packet will arrive. Now if it is tcp it will be a syn packet to a port which your nat device may or may not accept and send either an icmp reject, ignore it or reply to the syn with a syn ack Obviously both the icmp and the syn reply won't travel much since target rfc1918 have no valid routes and will be discarded upstream. Now if a udp packet, or something with a strange protocol id and a specially crafted payload reaches your edge, exploiting an unknown bug, it may cause denial of service, or system compromise at worst. (if pushing it to the extreme, the packet payload can cause injected code execution...) so whoever want to send his trash and doesn't want an answer will use rfc1918 addresses as source, because she doesn' t want to be traced. A dos attack is security or performance issue in the end. Since no usable traffic will ever come from rfc1918 on the public internet, blocking it is just a safety measure. (but in reality won't protect you that much...) Thanks! This part was really helpful. I would have never thought of that. After quite some testing I think I have found what I was looking for in the first place. An easy rule to isolate my different networks from each other while at the same time give each of them unrestricted internet access. So far I've come to the conclusion that an 'anything BUT' rule is the best fit for my needs. [image: 1544602216483-f4c4577d-c2b6-4893-92a9-9a6edb5ee238-image-resized.png] If you have any other suggestions I'm eager to hear them. But as my original question is solved I will mark this thread accordingly. Thank you all! Have a nice day!

@gertjan hello I took from default a lot. RULES : for STORAGE INTERFACE Reject ANY TO ANY just for logging and PASS ICMP from STORAGE Net to ANY RULES FOR SERVERS Interface PASS SERVERS Net TO ANY This is a downstream network the FreeNAS is connected to an upstream network 192.168.10.0/24 the gateway and dns servers are set to an upstream network 192.168.10.1/24 the WebGUI IPv4 Address is set to 0.0.0.0 witch mean I can manage the webGUI from any interface or I should be able to do so. the interface STORAGE on the FreeNAS is pointed to a downstream network 10.72.70.0/27 to provide an SMB share for all downstream networks What I was trying to do is start managing it from the downstream network 10.72.70.0/27 because I am going to remove it from the upstream network. I called upstream network but is actually my old 1Gb network and I am moving into a 40Gb and I am transferring all hosts to my new network What else puzzles me host can ping the upstream network but not the other one Thank you

Thank you guys its solved with out adding any kind of route in pfsense . My ip was restricted . Regards

Oh, not at all! The 10.x segment I'm multihoming is coming directly FROM the pfSense firewall, and it's blocked for the Internet except for one port, SMTP (sending warning mails if someting stalls). The only possible vector is the wifi, and that has a very long passphrase in Norwegian that isn't possible to do wit brute force for a few million years. So yeah, there is the WPA-2 vulnerability, but they would have to be very close to the house to access, and my mastiff would probably start barking then.

Please find the attached logs for your reference you can open this logs in Wireshark1_1544441011468_Appliction-deny logs.pcapng 0_1544441011456_Appliction_Allow logs.pcapng . when we disable SSL filter then Livechat app packet allow and when we enable SSL filter then packet denying logs.