Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - 350flyer

#1

Quote from: lmoore on September 01, 2026, 04:14:42 PM
Quote from: 350flyer on August 31, 2026, 10:15:40 PM1. What is the best way to capture DHCP traffic on the VLAN 90 interface in OPNsense?

When troubleshooting it's worth checking the log files - https://docs.opnsense.org/manual/logging_services.html

The simplest way to see if OPNsense is seeing a DHCP request on VLAN 90 is to look at Kea's log file: Services -> Kea DHCP -> Log File

This will most likely open with a view listing Warning. To see DHCP requests and acknowledgements, from the drop-down list select Informational.

To capture packets use the packet capture tool - https://docs.opnsense.org/manual/diagnostics_interfaces.html#packet-capture

Interfaces -> Diagnostics -> Packet Capture

 - Select the interface
 - Enable Promiscuous
 - Set Protocol to UDP
 - Set Port to 67
 - Set Count to 2
 - Click on 'Start'

Connect a device to VLAN 90. If after a few minutes the job is still running it would be worth seeing if a request was received by clicking on the "View capture in standard detail" icon.


I have now done packet captures, although I initially wasn't seeing any DHCP traffic on OPNsense. I will also check the Kea log specifically at the Informational level as you suggest, because that should independently tell me whether Kea is actually receiving a DHCP request.

One interesting result so far is that I captured traffic directly on the EAP773 and can see the client's DHCP Discover with VLAN ID 90.

I then captured on OPNsense, including the VLAN 90 interface and the physical parent interface, while forcing the client to release and renew its DHCP lease. I did not see the DHCP Discover arriving at OPNsense.

So at the moment I have:

Client → EAP773: DHCP Discover visible, VLAN 90 tagged
EAP773 → switch: expected VLAN 90
Switch → OPNsense: DHCP Discover not currently visible
Kea: still checking the log for confirmation

I'll repeat the OPNsense capture using your exact settings:

Interface: VLAN 90
Promiscuous: enabled
Protocol: UDP
Port: 67
Start capture
Force the client to renew DHCP
Inspect the live capture

I'll also check the Kea log under Services → Kea DHCP → Log File with the filter set to Informational.


Quote from: fornax on September 01, 2026, 05:57:04 AMLike you I'm largely self-taught and still fairly new to this, but I can at least offer a couple of suggestions:

  • Connect a laptop (or other device that you can manually configure) to the Wifi network, configure a static IP appropriate to the network, and then see if it can ping the router's IP on that network. That can tell you if there's any communication getting to the router at all.
  • Maybe also try setting up a VLAN 90 access port on the switch and see if your tests change at all there.
  • If you're using a centralized management interface for the network hardware, maybe check the switch and APs directly as well and make sure the configs are what you think they are.

I have actually been trying to isolate the problem in exactly this way.

I have now confirmed that the VLAN 90 interface on OPNsense is 192.168.90.1/24, and the client is associated with the CCTV_WIFI SSID but receives a 169.254.x.x address.

I also performed a packet capture directly on the EAP773. The interesting part is that I can see the client's DHCP Discover being transmitted with 802.1Q VLAN 90.

However, when I capture on OPNsense, I cannot see the DHCP Discover arriving on the VLAN 90 interface. I also tried capturing on the physical parent interface and filtering for DHCP/UDP 67/68, but still didn't see it.

So your static-IP suggestion is a good next test because it removes DHCP completely from the equation (in theory ). I'll temporarily configure the laptop with something like:

192.168.90.200 / 255.255.255.0
Gateway: 192.168.90.1

and then try to ping 192.168.90.1.

I'll also configure an unused switch port as an untagged/access port for VLAN 90 and connect the laptop directly. That should give us two very useful tests:

1. Wi-Fi + static IP → ping 192.168.90.1

2. Wired VLAN 90 access port + DHCP

If the static Wi-Fi client cannot reach 192.168.90.1, then this isn't really a DHCP problem — the VLAN 90 traffic isn't reaching the OPNsense interface correctly.

If the static Wi-Fi client can reach 192.168.90.1, then the VLAN path is working and we can concentrate on Kea DHCP.

And if the wired VLAN 90 client gets a DHCP lease, that would strongly point toward the EAP773/SSID side of the problem.

Thanks  for that,  I think the static-IP test is one of the best ways to separate the possibilities

#2
Hello everyone,
I am an amateur home lab and networking enthusiast and am largely self-taught. Networking is not my professional field (Airline Capt), so I am still learning and building my knowledge as I go. Most of what I have learned so far has come from YouTube tutorials, online documentation and forums, hands-on experimentation in my own home lab, and assistance from ChatGPT. I may therefore sometimes use incorrect terminology or overlook something that may seem obvious to more experienced network professionals. I am very willing to learn and would genuinely appreciate any guidance, corrections, or suggestions on the best way to troubleshoot and understand the issuei am facing.


Summary of the problem

I recently created a new Wi-Fi VLAN specifically for access to my CCTV infrastructure. The new network is:

QuoteVLAN 90 – CCTV Wi-Fi

The SSID broadcasts correctly from my TP-Link Omada EAP773 access points,  my iPhone can see SSID CCTV WIFI signal but has issues connecting to it (details explained below).

the client does not receive an IP address from DHCP. Instead, after failing to obtain a lease, the client receives a self-assigned address in the:

Quote169.254.x.x range.

The important point is that I have several other VLANs and Wi-Fi SSIDs using exactly the same OPNsense router, TP-Link switch infrastructure, trunk uplink, and EAP773 access points. Those VLANs are all working correctly and clients receive DHCP addresses normally.

At the moment, VLAN 90 is the only VLAN  or any vlan trying to access the other netowrk (CCTV Network) on physical separate port on my i225 NIC.

My objective is to determine systematically where the DHCP traffic for VLAN 90 is failing rather than making random changes to working configurations.

My network architecture

My network is built around an OPNsense router, with VLAN routing and DHCP provided centrally by OPNsense.

OPNsense router

The router hardware is:

QuoteLenovo ThinkCentre M920Q Tiny
Intel Core i7-9700T
32 GB RAM
1 TB SSD
Intel i226 quad-port Ethernet adapter

The current software versions are:

QuoteOPNsense 26.7.3_8-amd64
FreeBSD 15.1-RELEASE-p3
OpenSSL 3.5.8

OPNsense handles routing between my various internal networks and VLANs.

General network layout - My architecture is broadly as follows:

                    Internet
                       |
                       |
                    OPNsense
                       |
                       |
                 Main LAN trunk
                       |
                       |
          TP-Link Omada SG3428XPP-M2
                       |
             -------------------
             |                 |
           Port 2            Port 3
             |                 |
           EAP773            EAP773
             |                 |
        Multiple SSIDs   Multiple SSIDs
        Multiple VLANs   Multiple VLANs



The main trunk connection between the TP-Link switch and OPNsense is on: Switch Port 24

The two currently active EAP773 access points are connected to: Switch Port 2 and Switch Port 3

I have four EAP773 access points in total, although only two are currently connected. The other two are available for testing if necessary.

Existing VLANs

I have multiple networks for different purposes, including:

Default/Main Network
Home Lab
Aviation Wi-Fi
Guest Wi-Fi
IoT
Management
CCTV Wi-Fi

The existing VLANs and their associated wireless networks are working correctly. Clients connecting to those existing SSIDs successfully receive:

IP address
Default gateway
DNS information
DHCP lease

This is why the VLAN 90 issue is confusing: the same general infrastructure is already successfully transporting multiple VLANs.

Purpose of VLAN 90 – CCTV Wi-Fi

I created VLAN 90 specifically as a dedicated wireless network for trusted devices that need access to my CCTV infrastructure (CCTV Network) Located on a different physical port (igc3) on my Opnsense router.

The intended clients include:

CCTV monitoring tablets
Trusted computers
Trusted mobile devices

The VLAN has its own:

OPNsense VLAN interface
Dedicated DHCP subnet
Dedicated Kea DHCP pool
Firewall rules

For security reasons, I will not include my exact internal addressing in this post, but the CCTV Wi-Fi VLAN (192.168.90.X/24) uses a separate private subnet from the physical CCTV network (10.10.10.X/24 on igc3)

DHCP

I am using:

Kea DHCPv4

on OPNsense.

For VLAN 90, I have configured:

VLAN interface enabled
VLAN assigned to the correct parent interface
Dedicated DHCP subnet
Dedicated DHCP address pool
OPNsense interface as the gateway
VLAN 90 interface selected/configured in Kea DHCP

Kea DHCP is functioning correctly for my other networks. The issue appears to be isolated specifically to clients connecting through the new VLAN 90 SSID.

TP-Link Omada switch configuration - My main switch is:

TP-Link Omada SG3428XPP-M2

The switch carries multiple working VLANs.

The main OPNsense uplink is: Port 24

This is the trunk carrying the various VLANs between OPNsense and the switch.

The EAP773 access points are connected to: Port 2 and Port 3

The AP ports use the default network for AP management and carry the wireless VLANs as tagged networks. The existing Wi-Fi VLANs are working correctly using this configuration.

When I tested VLAN 90, it was added as a tagged VLAN on:

Port 24 – OPNsense trunk
Port 2 – EAP773
Port 3 – EAP773

Therefore, my expectation was that VLAN 90 traffic should follow the same path as the other working wireless VLANs.

Wireless access points - The access points are: TP-Link Omada EAP773 (I have: 4 × EAP773 Currently two are active).

The CCTV Wi-Fi SSID and most of the configuration on the tp-link hardware was created in Omada controller running on a minisforum MS-A2 in a LXC container in Proxmox and mapped to: VLAN 90

The SSID itself broadcasts correctly.

My iPhone (16 Pro Max) can:

See the SSID but has issues  connecting to the SSID However, it does not receive a DHCP lease. Instead, it eventually receives a: 169.254.x.x self-assigned address.

This appears to indicate that Wi-Fi association is successful, but the DHCP exchange is failing somewhere along the network path.

CCTV infrastructure

My CCTV infrastructure is deliberately separated from the main LAN. The physical CCTV network is connected to a separate physical interface on OPNsense.

The general design is:

IP Cameras
    |
    |
Dahua PoE Switch
    |
    |
Dahua NVR
    |
    |
Dedicated CCTV network
    |
    |
Dedicated physical OPNsense interface

The CCTV switch I currently have is: Dahua PFS3218-16ET-135, This is the 16-port POE Dahua switch.

My NVR is: Dahua DHI-NVR5216-E12

The CCTV network is separate from VLAN 90, located on a seperate port in igc3 (intel i226 quad port)

The purpose of VLAN 90 is not to place cameras directly onto Wi-Fi. Instead, VLAN 90 is intended to provide trusted wireless devices with controlled access to the separate CCTV network.

Conceptually:

CCTV Wi-Fi VLAN
       |
       | Firewall-controlled access
       |
       v
Physical CCTV Network
       |
       +--- Dahua Switch
       |
       +--- IP Cameras
       |
       +--- Dahua DHI-NVR5216-E12

Other parts of my home lab

I also operate a home lab environment that is separated logically from the CCTV infrastructure. I run a Proxmox server hosting various services.

Relevant services include:

Internal DNS
Split DNS
Home lab services
Reverse proxy infrastructure

I use Nginx Proxy Manager as my reverse proxy solution. The internal DNS infrastructure provides split DNS for my internal services.

I mention this for completeness regarding my general network architecture, although I do not believe it is directly related to the DHCP failure because the VLAN 90 client is failing before it even receives an IP address, gateway, or DNS information.

Firewall configuration

For VLAN 90, I created firewall rules intended to control access from the CCTV Wi-Fi network to the separate CCTV network. My initial firewall rule was essentially:

Action:
Pass

Direction:
In

IP Version:
IPv4

Protocol:
Any

Source:
CCTV Wi-Fi network

Destination:
CCTV network

The purpose was to allow trusted devices connected to the CCTV Wi-Fi SSID to reach the CCTV equipment. However, during troubleshooting I began questioning whether this rule could somehow be contributing to the DHCP failure.

My understanding is that the normal client firewall rule should not be the reason a DHCP client cannot obtain its initial lease, because DHCP occurs before the client has an assigned IP address and before normal routed traffic between networks takes place. I therefore did not want to start changing firewall rules randomly without understanding whether they were actually relevant.

Troubleshooting performed so far

I have tried to troubleshoot this by reviewing the configuration at each stage.

1. Confirmed that the SSID is broadcasting The CCTV Wi-Fi SSID is visible. Therefore, the access point is successfully broadcasting the SSID.

2. Confirmed the client does not receive a DHCP lease The client does not receive an address from the VLAN 90 DHCP pool.Instead, it eventually receives: 169.254.x.x This strongly suggests DHCP is not completing.

3. Checked Kea DHCP configuration

  • The VLAN 90 interface is configured in OPNsense.
  • The VLAN has a dedicated DHCP subnet and pool.
  • The relevant VLAN interface is enabled and configured for DHCP service.
  • Kea DHCP itself is functioning for my other networks.

4. Checked the OPNsense firewall rules. I created a firewall rule allowing the CCTV Wi-Fi network to access the separate CCTV network. However, because the client is failing before receiving an address, I am unsure whether this rule is relevant to the DHCP issue. I considered changing the destination to: Any to allow general connectivity temporarily, but I did not want to change security policies unnecessarily before identifying where the DHCP failure is occurring.

5. Checked the TP-Link trunk and AP ports. The main uplink/trunk on Port 24 is working for the other VLANs. The EAP773 ports on Ports 2 and 3 are also working for the existing Wi-Fi VLANs. During testing, VLAN 90 was added as a tagged network to the trunk and the AP ports. The configuration otherwise followed the same pattern as the other working wireless VLANs. This is one of the reasons I am struggling to understand why VLAN 90 is behaving differently.

What I have not yet been able to confirm

The critical question I have not yet answered is:

Does the DHCP Discover packet from the VLAN 90 wireless client actually reach the VLAN 90 interface on OPNsense?

The expected path is:

iPhone
   |
   | CCTV Wi-Fi SSID / VLAN 90
   v
EAP773
   |
   | Tagged VLAN 90
   v
Switch Port 2 or 3
   |
   | Tagged VLAN 90
   v
Switch Port 24
   |
   | VLAN trunk
   v
OPNsense VLAN 90 Interface
   |
   v
Kea DHCP

At some point in that path, the DHCP process appears to be failing.

My current thinking

Since the other VLANs work through the same infrastructure, I would like to isolate the problem rather than change multiple settings simultaneously.

I currently have two spare EAP773 access points. I am considering configuring an unused switch port with the same AP trunk configuration and explicitly adding VLAN 90. I would then:

1. Connect a spare EAP773 to the unused port.

2. Configure/test the same CCTV Wi-Fi SSID.

3. Attempt to connect with the iPhone.

4. Check whether DHCP succeeds.

If it works, I could then move the same access point to one of the existing AP ports.

This should help isolate whether the issue is related to:

  • The original EAP773 access point
  • The existing switch ports
  • The Omada configuration
  • VLAN 90 tagging
  • The trunk
  • OPNsense
  • Kea DHCP
  • Assistance requested

I would appreciate advice on the best logical troubleshooting procedure from here. In particular:

1. What is the best way to capture DHCP traffic on the VLAN 90 interface in OPNsense? I would like to confirm whether OPNsense actually receives the client's DHCP Discover packet. I expect this would immediately divide the problem into two possibilities:

No DHCP Discover reaches OPNsense
        |
        v
Likely AP / switch port / VLAN tagging / trunk issue

or:

DHCP Discover reaches OPNsense
        |
        v
Likely Kea DHCP / VLAN interface / DHCP configuration issue

2. Could the firewall rule on the VLAN interface affect the initial DHCP process? Or should DHCP continue to work independently of the rule controlling access from the CCTV Wi-Fi VLAN to the separate CCTV network?

3. Is there anything specific to Kea DHCP that I should verify when adding a new VLAN interface? Since Kea DHCP works on the other networks, I am wondering if there is a VLAN-specific setting I may have missed.

4. Is there anything specific to TP-Link Omada/EAP VLAN configuration that could allow an SSID to broadcast and accept client associations, but prevent DHCP traffic for that VLAN from reaching the router? This seems particularly relevant because all of my other SSIDs and VLANs work through the same physical equipment. Just a side note , all my Tp-LInk hardware was configured via the omada controller located on my Minisforum MS-A2 running on a LXC in proxmox.

5. Would a packet capture on OPNsense be the best next diagnostic step before changing any configuration? My preference is to identify exactly where the DHCP traffic stops rather than modifying working firewall, switch, or DHCP configurations blindly.

As an additional troubleshooting step, I attempted to perform a packet capture using the built-in OPNsense diagnostics tools. I selected the relevant VLAN/interface and attempted to capture traffic while connecting a client to the CCTV Wi-Fi SSID. However, the resulting PCAP capture file appeared to be blank, with no useful packets captured. This adds another question to the troubleshooting process:

Is DHCP traffic actually reaching the OPNsense VLAN interface at all?

At this stage, I have not been able to determine whether the blank packet capture means: VLAN 90 traffic is not reaching OPNsense or whether: I selected the wrong interface for the packet capture

or

There is another issue with how the packet capture is being performed

Because the other VLANs are functioning correctly, but VLAN 90 clients receive a 169.254.x.x address, I believe confirming whether any DHCP Discover packets from VLAN 90 reach OPNsense is now one of the most important next troubleshooting steps

Thank you in advance to anyone who takes the time to read through this (awfully long)post and offer some advice. I'm still very much learning as I go, so I genuinely appreciate people sharing their experience and pointing me in the right direction.

#3
thanks for the reply.

Sy
QuoteHi,

It seems that there is Synflood attach in your network. Zenarmor reports this. Most probably, synflood attack causes to eat up system resources and Zenarmor engine is crashing. Can you check the reported devices?

The devices with MAC Addresses: 00:0c:29:20:11:20 count:56921
f8:75:a4:cc:70:0b count:5340

Local IP: 192.168.1.222 count:56921, 192.168.1.1 count:4127


this only occured after the update. the ip in question (192.168.1.222) is a local ubuntu server with docker & portainer running a few containers.


Seimus

QuoteAre you doing maybe some port scanning?

Regards,
S.

not that i am aware of.

this is the reply i got from support.

QuoteHi Ugur,
 
Did you check the local device for synflood issue. The attackers are creating many sessions and doesn't proceed. The system caches are full for a while and can not resource on the machine. Please check the following link to prevent synflood on OPNsense and check the local devices whixh Zenarmor has reported.
 
https://docs.opnsense.org/manual/firewall_settings.html#enable-syncookies
 
 
Best regards

i been reading some user have reported issue with the em0 nic. could it be a driver issue ? i have a spare intel i350 lying around should i use that instead?
#4
hello
firstly i would like to thank everyone here in advanced for your assistance.
i am a complete novice when it comes to opnsense Linux and zenamor so my apologise for my simple questions.
i been able to install opnsense and zenamor via online tutorials and had been running fine for the last few months, however the other day i did a update on opnsense and zenamor was part of the upgrade package...
i upadate process was finished i did a reboot and everything was running fine for about 15min then i started getting errors. the internet connection breaks every10-15min for about 3-4 min constantly
looking at the console i see the message
"generic_netmap_dtor emulated netmap adapter for em0 destroyed"

i keeps the process until i turn off the zenamor packet engine.

i tried looking on the web for a solution but there are a gazillion solutions but i dont know which one applies to me?
when i look at the notifications i get the message
Syn Flood Detected
source :engine
detial:
QuoteSyn flood has been detected. Top 5 flooder actors {"local_hw":[{"hw":"000c29201120", "count":56921},{"hw":"f875a4cc700b", "count":5340}], "remote_hw":[{"hw":"f875a4cc700b", "count":56921},{"hw":"88c39711a792", "count":1905},{"hw":"5c0214b056dc", "count":1086},{"hw":"9c9d7e91e89d", "count":995},{"hw":"143fa6aa1a01", "count":588}], "local_ip":[{"ip":"192.168.1.222", "count":56921},{"ip":"192.168.1.1", "count":4127},{"ip":"2606:4700::6811:1802", "count":536},{"ip":"2600:1901:0:5736::f800", "count":248},{"ip":"2600:1901:0:aab1::2100", "count":33}], "remote_ip":[{"ip":"192.168.1.207", "count":1905},{"ip":"192.168.1.206", "count":1086},{"ip":"185.128.114.203", "count":1031},{"ip":"192.168.1.191", "count":995},{"ip":"fe80::c69f:44ef:9517:3402", "count":564}]}

now this is jibberish to me :(
after turning of the packet engine the connection is stable
Engine   2.0   Jun 11, 2025 17:08
Database   2.0.25060914   Jun 11, 2025 17:08
Agent   2.0.2   Jun 11, 2025 16:51
UI   2.0.59



i have a subscription but when i try access the sunnyvalley support site i get an error 1034 hence unable to contact directly to the zenamor support page.

any solution to my issue??

#5
thanks for the feedback EricPerl,

QuoteA quick search on "opnsense iptv" reveals a few pages (OPN docs and forums, github) indicating that DHCP is relatively common.
But they often also indicate the use of DHCP options specific to the ISP, including classless-routes which I suspect is used to push routing info.

IGMP proxy also appears to be a critical component

from what im led to believe.. is that the dhcp element is required, as from my attachment. IGMP is also a must and will configure that after i can get this internet dropping issue resolved.

as mentioned i get the Vlans working 35,55 on Pfsense with no dropouts and started playing with igmp and firewall rules but i found the Pfsense UI confusing a constantly clicking back and forward so i got tired of it and  really like the Opnsense UI. setting up the pppoe with vlan35  was a bit different on Opnsense than Pfsense but from what i am lead to belive if it work their.. it should work on Opnsense aswell..... well in theory :)
#6
hi dseven
much appricated for the reply.

QuoteI'm fairly sure that you do *not* want to make OPNsense a DHCP client on VLAN 55. It may be trying to use that as a route to the internet, and presumably your ISP wouldn't allow that.

from my previous post, another users same isp and iptv claims to have the setting correct for the wan interface, also claiming they had it up and running in Pfsense and was trying to get it to work on Opnsense. the picture i attched  in my previous post is the config they uses. i will however try the same config without the DHCP. I looked into the menu of the isp router i could inly see the 2 vlans (35,55) with dhcp.


QuoteHow are you planning on physically connecting the IPTV box? Does the IPTV box work if you connect it directly to the ONT (with OPNsense out of the picture)?
second part of the question, the iptv will only work when connected to the isp given router (zxyel) and not directly from the ONT... aprrently they are preconfigured with the relevant vlan's. I tried adding a switch between the ONT and Opnsense and simply connecting the STB to the switch (no joy).

the first par, My Opnsense box is a Lenovo M920q, it has an onboard eth port (em0) and Intel i350 4xport PCI NIC (igb0 igb1 igb2 igb3)
ONT- Opnsense WAN igb0
Lan = em0
IPTV lan igb3

igb3 port will go directly to the STB.
all other lan traffic will be on em0

QuoteIf you need to share a physical connection from the OPNsense location to the IPTV box location, perhaps you could create VLAN 55 devices on both WAN and LAN, and create a bridge between them

thats the issue i am having, as soon as i add the Vlan55 on the wan interface my internet connections drops :(



#7
Hey dish, thanks for the reply.

QuoteYour ISP/TV will require specific configuration, google your provider name + pfsense or opnsense etc and hopefully you can find it. If not you look for a guide for another provider and adopt it to yours. Check your service provider support page for the IPTV configuration.

thats major issue here, i moved here to turkey for work (airline industry) and the level of freedom for usage and hardware choice compared to other nations internet providers is massive. your 'locked on the hardware they give you' and will not divulge a micro bit of information to prevent you from using alternative hardware and just reply it not possible and they will not provide support. mind you me they will provide a really crusty isp firmware locked zyxel router where you can not even change the DNS and with out 10 devices connected it starts to hang and crash. im constantly rebooting 2-3 times a day ( changed the router 2 times barely better). if reading and searching the 'alternative means'  i managed to get pfsense running but switched to Opnsense i found it lot more intuitive and better eye candy + zenarmor.

i managed to get some info from another forum with the same isp and configures exactly the way picture attached indicates. they also used dhcp and reported no issue but my Net connection drops after a few minutes when i add vlan 55 to wan interface.


QuoteHere is an example for KPN netherlands (just translate the page), your config will end up similar.
https://j4me.synology.me/ - scroll down to iptv settings
Basically need specific interface config, igmp proxy, specific dhcp settings for tvbox so it pulls info from TVprovider, open up broadcasting, block the TV vlan from spamming your LAN etc

thank for that i seen a vid on that as well and came across it a few time and will definitely take a deep dive after i get this Vlan55 issue from dropping my net connection problem resolved.


QuoteI got tired of it and in the end the simple solution for me was to install the android app from the TV provider on my smartTV or GoogleTV dongle. This takes 5mins of your time and works just as well.

i agree it a faster and cleaner solution, even that didn't work for me after i installed Zenarmor, apparently it was adblocking a feature needed to run the app. took my 2-3 hours of figuring it out because the discription was ad blocked and had no information at all it to being related to the iptv app.
however, i am willing to loose a few more brain cells and cognitive functionality for now one reason being i like the idea if the net goes down i can still stream the iptv via the stb ( like the medieval sat dish :)))  )



#8
Tried everything except for bridging with no luck..
i was curious to see if it's an isolated issue so I decided to install Pfsense on my spare machine did the configuration and both vlans (35,55) on the wan interface and did not encounter any internet outage.
these are the steps i had taken within Opnsense:
1. Create Vlan 35 with (WAN) igb0 as the parent device
2. add point-to-point (pppoe) link interface vlan35
3. add interface (pppoe0) in interface assignments.
4. Create vlan55 with Wan as the parent device
5. add vlan55 interface via interface assignments
as stated above, without steps 4 and 5 internet works.

not sure what is going on but any help would be appreciated
#9
Turkish - Türkçe / TTNET fiber ve Vlan55
March 05, 2025, 09:14:01 PM
Merhaba herkes,
Öncelikle, ağ konusunda bir uzman değilim ve Opnsense konusunda da oldukça acemiyim, bu yüzden eğer sorun basit ya da saçmaysa şimdiden özür dilerim.

İnternetimi TTnet fiber bağlantısından alıyorum ve PON cihazından doğrudan Opnsense kutuma (Lenovo M920Q - 32GB RAM, Intel 8 çekirdekli i7-9700T, 1TB NVMe SSD ve 4 portlu Intel i350) bağlanıyor(igb0).

TTNet internet ve IPTV hizmetlerini aynı fiber bağlantı üzerinden sağlıyor. İnternet VLAN35 üzerinde PPPoE ile, IPTV ise VLAN55 üzerinden iletiliyor.
Burada, YouTube'da ve Google'da bulduğum kurulum kılavuzlarını takip ettim ve internet bağlantısını başarılı ve stabil bir şekilde çalıştırmayı başardım. Zenarmor (home aboneliği) kurdum, politikaları ayarladım ve her şey gayet iyi çalışıyor gibi görünüyor.

Ancak, IPTV VLAN'ı ile ilgili bir sorun yaşıyorum. Yaptığım araştırmalara göre VLAN55'i WAN arayüzüne eklemek oldukça basit görünüyor, ancak birkaç dakika sonra ağdaki internet bağlantısını tamamen kaybediyorum. VLAN55'i sildiğimde veya devre dışı bıraktığımda internet birkaç dakika içinde geri geliyor.
Bunun neden olduğunu bir türlü anlayamıyorum.

Ağ arayüzleriyle ilgili görseli ekledim;
Bir yerde hata mı yapıyorum?

Nihai hedefim IPTV hizmetimi LAN4 (igb3) arayüzü üzerinden TTNet Tivibu sağladığı STB cihazına iletmek ve bunu TV'ye bağlamak. (Bu bir sonraki adımım olacak, o kısmı nasıl yapılandıracağımı çözmeye çalışacağım.)

#10
hello pfry
thankyou for you feedback.

in the picture i didn't include the Vlan55 setup as it breaks my net connection, but you are correct. I create a vlan55 and assign the Parent as igb0 then add the vlan interface in the interface assignments.

i am thinking of experimenting in creating a vlan55 interface on the lan side but i haven't gotten to the stage of bridging them wan Vlan55 to igb3 vlan55
or simply create a vlan on the lan (igb3) and bridge the wan to lan vlan55. i havent done this as of yet as i am still trying to resolve the internet dropout issue

i also created a tcpdump (packet capture) from the diagnostic menu for Wan.Vlan55, Wan.Lan35 and Wan but these are gibberish to me at my knowledge level.
#11
Hello everyone,
firstly im no networking guru and relatively a noob in Opnsense so please accept my apologies in advance if its a stupid/simple issue.

I get the my internet from my ISP's fiber connection and from the PON device it goes strait into my Opnsense box (Lenovo M920Q with 32gb ram, Intel 8-core i7-9700T  1TB NVME SSD and 4 port Intel i350))

My ISP delivers the internet and IPTV services on the Same fiber connection. Internet in on the Vlan35 with pppoe and IPTV on Vlan55.
i followed the setup guides i found on here, youtube and google search and  obtained a good stable connection for the Internet. I have install Zenarmor (home subscription) and setup policies and as said before everything seems to work really good.

then problem i am having is in regards the the IPTV Vlan. Done the research and trying to configure the vlan55 on the Wan interface seems strait forward but
after a few minutes or so i totally loose the Internet on the network. i delete Vlan55 or disable the vlan55 interface and internets comes back a few moments later..
for the life of me , i can not figure out why.??
 
Network Interfaces is attached in the picture;
i am doing something wrong?


my ultimate aim is to stream my iptv service to (lan4 igb3)  to my isp STB which is connected to the TV. (that is my next step... try and figure out how to configure that setup..

(learning curve is getting steeper as i sniff around theseYou cannot view this attachment. system.. it was a breeze with my ASUS home router :))