@johnpoz said in How to keep networks separated:

Seems odd to me that your saying pfsense is getting a public IP - but other devices are getting 192 - this isn't normally how a gateway in bridge mode works.

That's how the att garbage works. Their gateways have what's called passthrough mode. Via dhcp it assigned the public ip to a single device on the lan side.

However, the public ip still remains assigned to the gateway's wan as well. It's a pseudo passthrough mode of sorts, fake bridge.

The end result, customer's device (router, pfsense, etc) has what appears to be a public ip as well as the gateway. As such, the gateway can assign various private ip's to other devices (wired and wireless) connected its ethernet ports and/or wifi ssid. A traceroute behind the customer's router (pfsense or other), will show the gateway ip as the first hop (192.168.1.254) rather than the real wan gateway.

For those of us on fiber in areas not get upgraded to xg-pon, several bypass methods exist which eliminate the isp gateway box entirely. The best is extracting (or buying) the 802.1x certs then implementing them in software using wpa_supplicant. This gives customer full access and control of the network, no double nat, etc. Also a /60 PD for ipv6 vs /64 from the gateway box.

The other methods still rely on the gateway box in one manner or another.

What IP range is used in the router before pfSense? I think pfSense is looking ok, don't know about that switch.

@derek_nos said in Netgate 2100 Vlans With Aruba 1930 Switch And AP15:

so the following should be fine for native vlan1 and vlan30

Yep!

Okay so I indirectly "fixed" my problem. All it took was installing Debian as I couldn't install proxmox directly via serial console, then modded Debian into proxmox, virtualised pfsense with virtio networks cards.

I don't know why a testing device acquired an IP address for the Guests VLAN while connected to a wireless network associated with the IOT VLAN. I tweaked subnet/VLAN settings a little, but still very similar to the settings as described above. The testing device now acquires an IP address in the expected subnet, when connected to the IOT wireless network, so I guess that problem is resolved...
Even after the device acquired an IP address in the expected subnet, it still had no Internet access. After adjusting outbound NAT, this too was resolved.

@andrea-rizzini for starters what are the rules on your private interface? Are you forcing traffic out a gateway before you allow access to your camera vlan? Or your camera IPs

But examples were given on how to create the source nat (or outbound nat on the iot camera vlan) interface.

It would just be an outbound nat using your IOT interface, and the IOT interface address. Now when you talk to the camera's from your private net, it looks like your talking from the IOT interface IP.

Currently I show uptime of
63 Days 06 Hours 39 Minutes 54 Seconds

Which would of been when I updated to 22.01

@marvosa @mcury @NOCling @the-other

Thanks for the help!

The issue has been resolved. I'm still not totally sure what the setting was, but something was of with my pfBlockerNG settings. I was playing around with some settings in there, screwed up, and had to run the wizard again. All of a sudden my HOME VLAN began working properly. Tested on both the Dell and TPLink switches.

Thanks again everyone!

@openwifi said in I need to create a bridge connecting my LAN to OPT port.:

@marvosa Implementing a switch was the initial plan but then a switch would be an extra layer on the network that might fail at any time, so I thought why not just use the extra port and switch it together with the LAN. That means I do not need an extra power outlet for the switch and also reduced an extra point of failure on my network

A switch is an integral part of proper network design, you can't think about it as adding an extra point of failure.

If you're adamant about a collapsed design, then your best bet from a performance standpoint is moving to an appliance with an integrated switch (e.g. Netgate 2100).

@opoplawski

????

Are you moving that Mac between the 2 connections? How is your network set up? Do you have the Wifi and Ethernet on different interfaces? If so, why?

Can't seem to submit an edit of my post so:

Edit: Nevermind, I bought a switch... I already started this thread with "I know this isn't good practice",and trying to fix this issue, I realized, even as a temp fix it's not a good idea to do this, so I'm going to set the network up the proper way...

@worldhopp I believe you just solved my issue! I was just visualizing tagged and untagged backward. I'll let you know for sure how it turns out.

Thanks for the response on this old forum.

@dotdash said in Same Networks in different VLANs:

multiple routing tables is just that and not actually several routers

We could debate semantics I guess ;)

To "me" VRF is actual another router.. Since it is a whole set of new routing tables, and sure other interfaces.. Even if they are "virtual"

"Virtual routing and forwarding (VRF) is an IP-based computer network technology that enables the simultaneous co-existence of multiple virtual routers (VRs) as instances or virtual router instances (VRIs) within the same router."

think the OP should just use different networks for the vlans

We agree here ;)

Solved...
For some reason, "Firewall -> NAT -> Outbound" showed me an "Auto created rule for ISAKMP - ... to WAN" for one failing VLAN, but it did not add the "randomize Source port" entry automatically.

No clue why... I also seem to have had "Manual Outbound NAT rule generation." on, but then I wonder how I ended up with the above auto created rule.

In any case, I now added the needed NAT entries manuall and now finally it works :)

@johnpoz : Linksys EA7300 - You said it would work, but it doesn't!!! 😆 🤣

Not listed as supported on the DD-WRT web site. 😞

But it is supported on OpenWRT with vLan! Yay!

So, cool beans! I can (probably) take it from here.
Thanks for your, and everyone's, help!!!

@ossgeek said in Best Practices for VLANs with Multiple Interfaces:

it would be a few extra clicks to configure.

Either way adding more vlans to a physical interface is no big deal, be it you have untagged on the interface already or not. Sure you would have to change the config on your switch a bit.

But I run native (untagged) network on same interface I also have tagged vlans on.. There is nothing saying you can not do that - unless you had some limitation of your switch? Or again some company policy stated not to do that ;)

@viragomann Big thanks for this, man. One click fix after days of troubleshooting and even consulting with others.