@bp81
So then the problem is the ubiquiti.
Show pics of the config.

@nilocretep said in Devices on VLAN can't access the internet:

all have a setup of /24.

well why are you pinging 198.168.178.1 from 192.168.179.111 - why would you not ping the IP of pfsense on that interface? but yeah if that was another IP on pfsense rules allow it then sure you could ping it.

Also you rules for security cameras never going to allow anything - you have the source as the securitycamera address not the net.

@sarxworks
There's all kinds of problems.
First, no IP on the vlan, it'll never talk to anything.
Second, the 172.16 network didn't exist, you kinda just threw IP's on the 2 devices and left it at that.
As I said, the host and VM aren't connected correctly.
I'd have to go through the setup again to say more but the whole thing was wrong.

Just to add, if you do default the pfSense install, you'll need to change the LAN network. Can't have the same subnet on the WAN and the LAN.

@eroji glad you found your solution..

@evilecho For a vpn-killswitch you only tag the rule with the VPN-gateway set, if you use PBR.

@viragomann Thank you for your advice. This is in line with what I found out so far.

In more general terms, here is what I found:

1: It is possible to create a bridge between a tagged VLAN interface and an untagged LAN interface just like between two untagged interfaces, except if the tagged VLAN's parent interface is also a member of a bridge. See here for more: https://redmine.pfsense.org/issues/11139. For example, if LAN on ix0, VLAN10 on ix0.10 and LAN2 on ix1, then I can create a bridge between VLAN10 and LAN2 if, and only if, LAN is not a member of a bridge.

2: This bridging works well between a WAN interface and a VLAN, which itself is bound to a LAN parent interface. To use the example above, this would be between the WAN interface and LAN10. In my case, where the WAN is a "private WAN" behind an Internet facing gateway (ISP-GW), the Netgate's WAN interface (like any other member interface) can be configured to receive an IP address via DHCP (but not have a DHCP server) from the ISP-GW (192.168.192.0/24). All other devices connected to this bridge will also be able to receive an IP address from ISP-GW. Note that all addresses on member interfaces and all connected devices are (must be) in the same subnet. Also note that, generally, this does not work without the double NAT/gateway setup, because it would need multiple IP addresses from the ISP.

3: For DHCP address assignment to work, a firewall rule may be required on all bridge member interfaces (except probably the one where the DHCP server resides): source 0.0.0.0, source port 68, destination address 255.255.255.255 and destination port 67. This message is the first to be sent in the DHCP protocol. There are two aspects to this that I don't fully understand yet:

3.1: The rule may not be required if one of the bridge member interfaces receives a DHCP address. It seems that pfSense automatically adds a hidden rule to that effect. What is not clear to me is whether this hidden rule applies only to the bridge member that receives a DHCP address, or whether it applies to all bridge members.

3.2: I don't understand the role of the system tunables net.link.bridge.pfil_bridge and net.link.bridge.pfil_member. It is easy to find a variety of explanations for these, but none of these is complete. There are two aspects of firewall rules in brides and bridge members: a) govern the traffic between the bridge interface or a member interface entering/exiting the firewall/routing engine, and b) filtering the traffic between the member interfaces without it entering the firewall. I suspect the system tunables apply to the first aspect, but not to the second.

3.3: Testing of this is complicated by the facts that a) devices cache their IP address and use the last address when trying to renew an address lease, and b) the bridge caches the MAC addresses on each bridged segment. When changing the firewall rule mentioned above and the system tunable settings, all the caches need to be flushed to determine the impact of the change.

4: Concerning the propagation of the traffic on the Unifi switches (and I assume this is similar to other managed switches): to make this work the only thing required is to declare the VLAN, without specifying DHCP/seubnet/gateway parameters. This makes the switch aware that the VLAN exists. The VLAN can then be added to trunk profiles (as tagged traffic) and to port profiles for VLAN-unaware end nodes' access to the untagged data stream.

I will further update this when I have gained a better understanding for 3.2.

Any further comments are welcome.

Peter

@jarhead
Yeah, there's link.
I've just realized that the original router, apart from VLAN and fixed MAC address, it has a hostname configured.

So, I decided to add the same hostname in pfSense WAN interface and the spoofed MAC has disappeared (greyed xx in GUI and no spoofed MAC at CLI). I guess I have to repeat the process of unlink WAN physical interface from VLAN and start again, but it does not give much confidence...

I know how to check packet counters with "ip address" in Linux, but not in FreeBSD... xD

pfSense DHCP Logs are showing dhclient process sending DHCPDISCOVER over igb1.1074, but no answer apparently.

@rcoleman-netgate i think via LDAP group membership is possible but the pfsense UI has only user options...

@johnpoz Ahh ok. Geez this is overly complicated but i understand a bit more.
When you have no choice this is the solution :)
Thanks for clarifying.

@chpalmer I know this is a really old one but it's one of the top results while looking around for a solution to the problem being described here...

You provided the hint about how to fix it, at least in my circumstance - I had to REMOVE the MAC address from the WAN interface, I don't know what was going on there but I had a value previously assigned there and once I removed it everything started working fine. I probably had the MAC Address value set previously from a long time ago and it caused some issue when getting everything assigned to the new LAGG interface. I don't really know for sure but removing the value from MAC Address fixed the issue for me.

Thank you.

@jbarbanera
You can remove the nat 1:1 rule. That is not the use case, it is meant for.

Check if the network settings are correct on both machines.

Is pfSense the default gateway on both. I assume it isn't at least on the WAN computer.
If it isn't add a static route to it for the other network behind pfSense and point it to pfSense IP.

👻 Yeah, that could be the issue. I have heard from users to stay away from Realtek NICs. I made sure that I got a used 4-port Intel NIC, less than $20 from eBay, which has been working flawlessly under pfSense when I built my pfSense box two years ago. 👻

@johnpoz said in allowing roku discovery across VLANs:

full byte

HA!

@jaaasshh Did you ever figure this out? I know this breaks @johnpoz's heart but I'm trying to do the same.

@jarhead And when you do there's no need to redact interface names or internal MAC addresses... public IPs, FQDNs, usernames? Sure.

@uquevedo Groovy. Glad it worked

I should also mention, the DMZ network we are trying to setup is a routed network. The ISP has a static route pointed at our firewall with this particular network.