Netgate SG-1000 microFirewall

Author Topic: Blocking RFC 1918 traffic not working  (Read 326 times)

0 Members and 1 Guest are viewing this topic.

Offline thingsmg

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
    • View Profile
Blocking RFC 1918 traffic not working
« on: February 24, 2018, 01:14:11 pm »
Hi to y'all

This is my first time I post something on forums, so bare with me.

I've been dealing with an issue kind of a headache for the last two days, I'm not able to block rfc 1918 on a specific subnet, just to let you know I have a pfsense 2.4.2-RELEASE-p1 version, and also have a four port nic card, one port for wan, one for lan (192.168.100.1/24), one for guest wifi clients (192.168.200.1/24) and the last port is not use at the moment, I've also installed squid proxy and squidguard to implement a transparent proxy on the wifi client interface to prevent clients reach porn sites and other stuff, and is working fine and also I've enabled dns resolver listening on all interface and last but not least, all clients on the wifi interface are going out through a vpn client, which is also working great.

So, what I'm trying to accomplish on the guest wifi interface (and I don't know right now if it even possible) is to have a internet only network, I don't want clients to see each other but the internet, right now I perfectly get the clients reach the internet through the vpn gateway and I've manage to block traffic from 192.168.200.x(wifi) to 192.168.100.x(lan).  But I can't block clients to see each other on the wifi interface, for example I do not want them to see the wireless access point which have an IP address of 192.168.200.2, but they do! I have a camera connected to the same interface with IP 192.168.200.101 and also any client can see the camera; how can I prevent clients to see each other?

Thank you so much in advance, for taking the time to help me solve this, I really appreciate.

Ps: I attach some print screen for you to have a view of the rules I have on the interface.
« Last Edit: February 24, 2018, 01:33:40 pm by thingsmg »

Offline Derelict

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10266
  • Karma: +1177/-313
    • View Profile
Re: Blocking RFC 1918 traffic not working
« Reply #1 on: February 24, 2018, 04:25:41 pm »
You cannot use a layer 3 device (life pfSense) to isolate layer 2 clients from each other. That has to be done in your switching or wireless infrastructure.

Client-to-client traffic occurs on the same subnet. The firewall is not involved at all.
Las Vegas, Nevada, USA
Use this diagram to describe your issue.
The pfSense Book is now available for just $24.70!
Do Not PM For Help! NO_WAN_EGRESSTM

Offline thingsmg

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
    • View Profile
Re: Blocking RFC 1918 traffic not working
« Reply #2 on: February 24, 2018, 06:34:11 pm »
Thanks for your reply, I thought that wasn't possible on pfsense.

Offline Harvy66

  • Hero Member
  • *****
  • Posts: 2360
  • Karma: +220/-12
    • View Profile
Re: Blocking RFC 1918 traffic not working
« Reply #3 on: February 25, 2018, 12:40:25 pm »
Thanks for your reply, I thought that wasn't possible on pfsense.
It's not possible on anything other than the switch/AP. You should never have two subnets in the same broadcast domain.

Offline JKnott

  • Hero Member
  • *****
  • Posts: 1382
  • Karma: +60/-13
    • View Profile
Re: Blocking RFC 1918 traffic not working
« Reply #4 on: February 25, 2018, 01:00:33 pm »
Quote
You should never have two subnets in the same broadcast domain.

Possible but not common on IPv4.  Entirely normal and supported on IPv6.
This page unintentionally left blank.

Offline Derelict

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10266
  • Karma: +1177/-313
    • View Profile
Re: Blocking RFC 1918 traffic not working
« Reply #5 on: February 25, 2018, 01:18:41 pm »
None of which is relevant to OP's problem. The subnets are on separate NICs as they should be.
Las Vegas, Nevada, USA
Use this diagram to describe your issue.
The pfSense Book is now available for just $24.70!
Do Not PM For Help! NO_WAN_EGRESSTM

Offline thingsmg

  • Newbie
  • *
  • Posts: 7
  • Karma: +0/-0
    • View Profile
Re: Blocking RFC 1918 traffic not working
« Reply #6 on: February 25, 2018, 09:10:00 pm »
Thank y'all guys more than clear that it is not possible to do it, I'm still open if there's any idea on how to do it. Thanx.

Offline Derelict

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 10266
  • Karma: +1177/-313
    • View Profile
Re: Blocking RFC 1918 traffic not working
« Reply #7 on: February 25, 2018, 09:36:01 pm »
Do it in your wireless and switching (Layer 2) infrastructure.

Google wireless client isolation and switch port isolation. Look at your AP docs. Open a ticket with them.
Las Vegas, Nevada, USA
Use this diagram to describe your issue.
The pfSense Book is now available for just $24.70!
Do Not PM For Help! NO_WAN_EGRESSTM

Offline johnpoz

  • Hero Member
  • *****
  • Posts: 15761
  • Karma: +1502/-210
  • Not a pfSense employee, they cannot fire me...
    • View Profile
Re: Blocking RFC 1918 traffic not working
« Reply #8 on: February 26, 2018, 04:04:13 am »
"Entirely normal and supported on IPv6."

No it is NOT.... You do not route traffic between a link local and or globals on the same L2...

What part of this do you not understand??  You do not put 2 different global ipv6 prefixes on the same L2 and route between them.

Having a link local and global address or even a ULA on the same L2 is not the same thing..
- An intelligent man is sometimes forced to be drunk to spend time with his fools.
- Please don't PM me for personal help
- if you want to say thanks applaud or https://www.freebsdfoundation.org/donate/
1x SG-2440 2.4.3-RELEASE (work)
1x SG-3100 2.4.3-RELEASE (work)
1x SG-4860 2.4.3-RELEASE (home)

Offline JKnott

  • Hero Member
  • *****
  • Posts: 1382
  • Karma: +60/-13
    • View Profile
Re: Blocking RFC 1918 traffic not working
« Reply #9 on: February 26, 2018, 12:22:07 pm »
Hi Jon

You seem to be stuck on IPv4 to the point you don't know how things are on IPv6.  One example was our recent discussion about IPv6 transit networks, where you didn't seem to know IPv6 routing is done over link local addresses, not global or even local (ULA) addresses.  IPv6 was designed to allow things that were never considered or unlikely to be done on IPv4.  For example, it is understood that multiple prefixes on an Interface are normal.  They could be global or local  They're allowed and pfSense happily provides them.  It's also possible to have multiple default gateways on a network, with priority set according to what's supposed to be the primary vs fall back.  You might also have multiple gateways that provide specific routes to some destinations.  All this and more is part of IPv6.  One example I've read about for having global and local addresses on an interface is so that IoT, on the local prefix could be used, while also having global addresses for the Internet.  You might want to read a book, such as IPv6 Essentials, from O'Reilly to learn more.  I've read that and other books on IPv6.  I'm currently reading IPv6 Fundamentals: A Straightforward Approach to Understanding IPv6, from Cisco.  In those books you'll find these things and more were intended when IPv6 was designed.  IPv6 is about much more than just a larger address space.
This page unintentionally left blank.

Offline Harvy66

  • Hero Member
  • *****
  • Posts: 2360
  • Karma: +220/-12
    • View Profile
Re: Blocking RFC 1918 traffic not working
« Reply #10 on: March 02, 2018, 12:15:22 pm »
Thank y'all guys more than clear that it is not possible to do it, I'm still open if there's any idea on how to do it. Thanx.

Not possible via pfSense or any other firewall unless it somehow integrates into your switch/AP. There are APs or switches that can support some forms of client isolation within a broadcast domain. I've never used one, but I know they exist.

None of which is relevant to OP's problem. The subnets are on separate NICs as they should be.

I totally misread the second paragraph. I saw his current setup was seperate interfaces, but I thought they were trying to combine them.

Hi Jon

... IPv6 was designed to allow things that were never considered or unlikely to be done on IPv4.  ...

Having multiple subnets in the same broadcast domain has nothing to do with IPv4 vs IPv6. IPv6 may make certain aspects of it better or take advantage of certain aspects, but many of the downsides are exactly the same due to fundamental issues that are orthogonal to the Layer 3 protocol.