@miracullix So just bridge the ports together and give it a try. You can always "undo" what you setup - go in reverse order to tear it all apart.
Under Interfaces, select the Bridge button. In there, click the Add button. In there add the 2 ports you want together (use the shift key on the keyboard to select multiple ports) and then click the Save button. Keep in mind, the only interfaces you can add to a bridge are "enabled" interfaces. In other words, they have to be active. I think the 4100 comes with all interface ports enabled.
So, now that you have a bridge added, you have to enable it and set it up. Be careful here, I think you could inadvertently lose your LAN connection and the IP address range you already had on it.
Long story short, I don't believe you can simply click a couple of buttons and add another available interface to a bridge. There's a little bit of setup, and some pretty good setting tweaks. And, obviously the performance hit. So, that's why it's said to just add a switch to keep it simple.
I figured out how to connect my computer to the pfsense vm. On windows server 2016 i went to network connections where i can see all my ethernet adapters. Then i selected in my case ethernet 3 where my computer is connected and the internal lan adapted and bridged the two adapters. In the bridged adapter i changed the ipv4 adress and i was connected to the router.
However now i am connected but still dont have internet and i am able to ping 220.127.116.11 but not google.com i get the error dns could not be resolved when trying to access internet in chrome.
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.
I solved the issue a while ago and forgot to answer here.
After entering the IP in Captive Portal / Allowed IP Addresses, everything was perfect.
As my CP is authenticated, so I believe that the question was precisely at that point. The other end had no way to authenticate itself to be able to pass and from the moment I released the IP there, he started to communicate. I even thought about doing a test of this type, taking the CP's authentication to see if it worked directly, but I ended up not having time.
Anyway ... it's resolved.
Thanks to everyone who was willing to try to help.
@gabriel-silveira Se você tem 2 provedores, os 2 estão conectados no pfsense, certo?
O Gateway group permite você configurar essas saídas de Internet em failover por exemplo, caso provedor A caia, utilize o provedor B até que o A seja restabelecido.
Ou caso você queria por exemplo que a VLAN20 utilize o provedor A apenas, você adiciona na regra de Firewall que permite o acesso a Internet dessa VLAN o gateway apontando para o gateway do provedor A.
Você fez alguma configuração nesse sentido?
Pois caso tenha feito, você precisará criar regras de Firewall, permitindo a conexão entre as VLANs, com gateway sem alteração, ou seja, em default, e essa regra deverá estar no topo.
Ela precisa estar antes das regras que permitem o acesso a Internet com gateway específico, ou seja, que não seja default.
Uma recomendação para que possamos te ajudar melhor, é sempre postar uma topologia do ambiente. Estou tendo que fazer suposições sobre o problema e o ambiente.
I think the problem is not within the Router but in the testserver.
Even though I did a reinstall recently and never installed anything else than apache2 and openssh-server, a tcpdump confirmed that the packets arrive at my testserver but my testserver does not respond to them for whatever reason. So most probably my fault.
I would not expect a port forward to be required there as Plex can usually be accessed from anywhere, even externally.
UPnP is disabled by default in pfSense and you should leave it that way unless you have a very good reason not to. Plex can open port forwards in the firewall to allow access otherwise.
Usually when people device their network like you have it is for security. Consider what would happen if one of your cameras was found to have a vulnerability and was hacked for example. What would that give anyone access to?
You probably want firewall rules on the 192.168.2.1 interface in pfSense that allow only the required access outbound. So the cameras may not need any external access or maybe only to a known IP or set of IPs. Wifi IoT style devices may not need any access to to the LAN subnet. Though maybe you want Alexa to be able to control Hive....
What you want to do is allow only the traffic that is needed and segregate devices as much as possible to mitigate any security issues should they occur.
Does your access point allow for multiple SSIDs / VLANs?
If so I would create more so you can separate general access devices like laptops and tablets from IoT devices like cameras and Alexa.
Currently you have separated devices simply by wired or wifi and that might not be the best way. The Hive and Hue hubs are IoT devices. I would want those on a separate subnet to desktop PCs and servers if possible.
ok so here are the results of my efforts last night until 0130!
I am currently unable to get my plex to work.
the plex server is on the server 192.168.1.251 and I am trying to access it via the tv firestick. can anyone help?Skynet.jpg
Nein, die Clients müssen ohne Gateway auf den Webserver kommen.
Dann musst du für diese Verbindung eine eigene Regel definieren, die kein GW erzwingt.
Also Quelle: LAN net, Ziel: Webserver
und diese Regel oberhalb der anderen positionieren, damit sie auch angewandt wird.
Genau diese Regel hat in meiner Konfiguration gefehlt. 😃
Vielen Dank nochmal an alle Beteiligten für die Lösung meines Problems. 👍
Even if your ISP doesn't provide IPv6, you can still have it, using a tunnel from hurricane electric. They are free, they perform well, they are very reliable and they work. I used one for years before my ISP implemented IPv6. There are lots people here who can help you set it up.
Bei der NAT Regel könntest du statt tcp/udp/* gleich ganz "*" any Protocol nehmen. Wird mit Sicherheit einfacher sein. Aber im Prinzip hat sich diese Lösung - durchaus korrekt - schon beim Lesen deines ersten Posts angedeutet, wenn du schriebst, dass du 403 Forbidden oder Logins wie von extern bekommst.
Viele IoT oder andere Lösungen erkennen ihr eigenes Netz/LAN und nehmen für alles andere dann an, dass hier entfernter Zugriff bzw. Logins der Fall ist. Hier müsstest du case-by-case nachsehen, wo du ggf. zusätzliche interne Netze definieren kannst, damit die Anwendung/Lösung das VPN Netz als lokal/LAN erkennt. Mit der erstellten NAT Regel bist du aber hier noch einfacher unterwegs und wirst einfach mit der IP der pfSense intern gemappt, was die Geräte dann zufriedenstellen wird (wenn du eine besser nachverfolgbare IP brauchst, ist es kein Problem eine zusätzliche Alias IP auf die Sense zu nehmen und diese als interne NAT Adresse zu nutzen).