intravlan traffic again and rule 1000000103 - help!

cedrictang

I have looked a few pages on the forum and haven't been able to find a solution. Newbie.

I have id'ed a couple of potential sources of problems. Here is my set up.

netgate 6100
dual wan

vlan107 is the IoT network
vlan18 is the main network

trying to get rdp going from a tv 192.168.109.9 on the IoT network to a pc 192.168.18.97 on the main lan, as well as trying to get to the NAS.
Not able to connect.

None of the allowed IoT devices can actually connect to the main lan even though I have set up the rules. I even put a PC on the IoT vlan and created a rule to allow all traffic but even with that rule I cannot even ping the main lan. But the DNS is working somehow (second last rule) coz I can see all the IoT devices querying the pi-hole on the main lan.

Any ideas?
Thank you very much!

Image 06-12-2025 at 21.27.jpeg

Image 06-12-2025 at 21.28.jpeg

SteveITS

@cedrictang which rule is supposed to allow the .109.9 device?

patient0

@cedrictang said in intravlan traffic again and rule 1000000103 - help!:

trying to get rdp going from a tv 192.168.109.9 on the IoT network to a pc 192.168.18.97 on the main lan, as well as trying to get to the NAS.

Did you disable or adjust the Windows pc firewall? From other posts it appears Windows per default doesn't allow connections from non-local sources.

Is VLAN107 192.168.109.0/24? I guess .107.0/24 would be less confusing ;) but to each its own.

And I assume we're talking about the following rules:

samsung_m7 -> pt_pve01_win10_18_97
samsung_du7100 -> pt_pve01_win10_18_97
samsung_du7100 -> ugreen_4800p

Of the three rules only the samsung_du7100 -> pt_pve01_win10_18_97 has hits (0/2 KiB), the other two read 0/0 KiB which means these were never used or matched.

If we see the VLAN107 rules in the screenshot, VLAN107 is 192.168.109.0/24 and the samsung_du7100 alias contains 192.168.109.9, then that rule gotta work for IPv4 traffic.

johnpoz

@patient0 said in intravlan traffic again and rule 1000000103 - help!:

If we see the VLAN107 rules in the screenshot

Odd that he would make the iot network the normal lan interface - this interface he is showing has the antilock out rules on it. This would be on the normal lan.

patient0

@johnpoz said in intravlan traffic again and rule 1000000103 - help!:

Odd that he would make the iot network the normal lan interface

I agree but writing it out he/she may realise that the rules work or not work the way he/she thinks. That the rules have to be defined on the interface the traffic is coming from, VLAN107 is that instance.

(the VLAN107 network is most probably .107.0/24 and not .109.0/24, according to the deny rules)

johnpoz

@patient0 agree not sure what he has going on here..

If this is the normal lan 192.168.18 - why doe the rule with 107 subnets as source show so much traffic on it.

cedrictang

Hello all.
Thanks for the reply.

There was a typo.
Should be 107.9 - this is a pc I stuck on the VLAN 107 to test.
I originally also put in a rule to allow the full VLAN107 subnet to pass to the windows machine on 192.168.18.97. And that generated the first screenshot. It didn't work.

The samsung tvs (m7/du7100) are on 107.189, 107.188).

The above screenshot is the rules defined in VLAN107 and not the main lan of 192.168.18.0/24

VLAN 107 is the IoT subnet.

Regards,
Cedric

patient0

@cedrictang said in intravlan traffic again and rule 1000000103 - help!:

The above screenshot is the rules defined in VLAN107 and not the main lan of 192.168.18.0/24

Then it has to work but the 0/0 B show that the rules are never hit.

If you add a computer to VLAN107/IoT, can you ping the TVs (that would not involve pfSense at all)?

Btw: is that a new setup, or to put it differently: is the VLAN configuration/setup correct?

johnpoz

@cedrictang said in intravlan traffic again and rule 1000000103 - help!:

The above screenshot is the rules defined in VLAN107 and not the main lan of 192.168.18.0/24

Odd that you would use pfsense lan interface as your iot network - since this clearly has the anti-lock out rules on it. Not sure why you would want your iot network to be able to access your web gui?

Your main network should really be what is pfsense "lan" interface - then create another network/vlan for your iot network.

For what your doing it can work this way - but with the antilock on there - anything on your iot network would be able to access pfsense web gui, or ssh. If they have the creds.

If me this would be the first thing I would fix..

You can turn off the antilock - but you can not setup antilock on anything other than what pfsense considers its lan interface.

You didn't change interface names in the config did you - this can lead to problems..

cedrictang

@johnpoz

I don't know how that rule got there.
In the main lan firewall rule, this rule is not there.

This firewall was restored from a previous failed firmware upgrade.
I re-installed the os and then restored the previous config from the cloud. This was over a year ago.

It IS strange now that you mentioned it. When I click on the cog it goes to the System/Advanced/Admin Access page.

I have multiple vlans. The other vlans do not have this rule.

Here is the main Lan's firewall rules.
And the ethernet port assignments.

Image 07-12-2025 at 15.22.jpeg Image 07-12-2025 at 15.23.jpeg

cedrictang

@patient0

Yes I can ping the firewall 192.168.107.1 and everything in the same 107 subnet from the 107.9 PC.

johnpoz

@cedrictang you got something funky going on.. So your not seeing it on the native interface lan, but you see it on a vlan that rides on the lan interface ix1

I just added a vlan to my lan interface. And antilock is on the lan, but not shown on the vlan.

You could try disable the antilock out, so that it goes away on your vlan 107, and then re-enable it.. Prob had something to do with your config reload.

Just make sure you have access via a different rule to gui/ssh or console access when you disable it.

patient0

@cedrictang said in intravlan traffic again and rule 1000000103 - help!:

Yes I can ping the firewall 192.168.107.1 and everything in the same 107 subnet from the 107.9 PC

Mmmh, if the two aliases, samsung_du7100 and pt_pve01_win10_18_97 both are correct (no typos in the Samsung TV alias?) and the Samsung TV really has the IP 192.168.107.188 then I don't see how the rule doesn't hit.

Addition: regarding the auto-lockout rules on VLAN107, if you are comfortable with the command line:

In the /conf/config.xml under <interfaces>, the one interface that is defined in the <lan>...</lan> tags gets the auto-lockout rules (I gave it a go and swapped the tags of <lan> and <opt1>). This would indicate that VLAN107 is in the<lan>...</lan> tags.

cedrictang

@patient0

interesting!
yeah seem my 107 subnet is tagged as lan.
i don't know how that happened?!
I can download the file but what software would you suggest I edit this.
Presumably i upload it back onto the system and reboot!?!?!

cedrictang

Would it be safe to use the Diagnostics/Edit File function to edit the /conf/config.xml file to change the following around then?

	<lan>
		<descr><![CDATA[vlan107]]></descr>
		<if>ix1.107</if>
		<enable></enable>
		<spoofmac></spoofmac>
		<ipaddr>192.168.107.1</ipaddr>
		<subnet>24</subnet>
	</lan>


	<opt3>
		<enable></enable>
		<if>ix1</if>
		<descr><![CDATA[LAN]]></descr>
		<spoofmac></spoofmac>
		<ipaddr>192.168.18.1</ipaddr>
		<subnet>24</subnet>
	</opt3>

johnpoz

@cedrictang you could always export it, and then edit it - then restore it. Worse case is you put back the original with it messed up.. but that for could explain why your having issues.

What is weird is your assignment page you posted doesn't show that.. To be honest might be best to do a clean install fresh - what else is messed up?

patient0

@cedrictang Sorry, forgot to answer your previous post.

No, it's not enough because the interface names are also used in e.g the DHCP section and if you have selected individual interfaces for e.g. Unbound/DNS Resolver and probably other sections. Or have more VLANs whos parent interface has to be changed too.

You have to go through the config file and check were interfaces names pop up.

And I would not edit it that way. As @johnpoz suggest, backup, edit and restore.

johnpoz

@cedrictang I am just curious how it happened in the first place... your assignments show normal - what if you save there?

Maybe toggle the settings, then save again.. Clearly this info has to be pulling from different places in the xml? If shows correct on assignments - but clearly wrong because your antilock out is on wrong interface and your xml shows it wrong, etc.

cedrictang

@johnpoz

hello all.
Thanks for all the messages.
And sorry for the late reply.

I did take the plunge and edit the whole file in the Edit File editor portion of the webgui.
I did copy the whole xml out and went through all references to LAN and OPT3. There are about 20 of them.

It was a bit scary but I did make a cloud backup first.
So I am glad to report it seems to have worked after swapping LAN and OPT3 references.

The config.xml seems normal. My IoT vlan107 (now opt3) can do the rdp (and other stuff) as expected.

THANK YOU!

Image 14-12-2025 at 12.29.jpeg

johnpoz

@cedrictang glad you got it sorted - and thanks for coming back and reporting on your results.

Now the only question is how did it happen in the first place.. ??? Curious for sure. I could see if the interfaces swapped position like ethx was lan, and ethy was something else and their order changed on new hardware or on boot, etc. But vlan riding on interface - new one on me..