VLAN rule ignored because of unmanaged switch?
-
Hi,
last week I received my SG-2440 and have been learning a lot of new stuff since then.
I have created 2 VLAN's and my devices get the IP's set by the DHCP server of the VLAN interface.I have 2 unmanaged switches for legacy and cabling reasons, if needed they will be replaced.
I attached a diagram of a part of my network.
I have:
modem -> pfSense -> managed switch ->
port 11 -> server (VLAN7 - 192.168.1.250)
port 22 -> unmanaged switch -> unmanaged switch -> desktop (VLAN2 192.168.2.10)On VLAN2 I have following rule which works fine:
IPv4 * 192.168.2.10 * 192.168.1.250 * * none IPv4 * VLAN2 net * * * * none
On VLAN7 I have following rule which doesn't work:
IPv4 * 192.168.1.250 * 192.168.2.10 * * none IPv4 * VLAN7 net * * * * none
I did several tests and it seems that I can block access from devices TO VLAN7 and the server specific but not TO VLAN2.
I suspect that the unmanaged switched are the reason but don't completely understand what the exact cause is.
Thanks in advance!
-
The VLAN2 port from your switch to your unmanaged switches should be untagged.
-
Thanks for your reply.
That port is untagged.
All the ports are untagged except the trunk port, I added this port to each VLAN as tagged. -
Then it should be working. Look at everything again.
-
How are your rules supposed to be blocking anything anyway? You haven't given us enough information. Are those pass rules? Block rules?
-
sorry, I copy/pasted it but didn't notice that I didn't copy the action by selecting the text.
I added screenshots now :)
VLAN5 has no ports connected and ADMIN is only connected in case I lock myself out.I have been looking at this and searching for 3 days now but cannot find what I did wrong.
If you say the pfSense settings are ok it might be the switch although I only changed VLAN ports there and set Management LAN to VLAN2 (the switch gets IP 192.168.2.2).
-
Your unmanaged switches do not care what VLAN they're on as long as the managed port connected to them is UNTAGGED.
What, specifically, (one thing not a laundry list) is not working?
-
Thanks for the info.
Blocking access from a specific host on VLAN7 to a specific host on VLAN2 isn't working.
I can still ping and SSH to 192.168.2.10 with a rule I expected to work.These block rules don't work:
IPv4 * 192.168.1.250 * 192.168.2.10 * * none
IPv4 * 192.168.1.250 * VLAN2 net * * nonethis block rule does work (can no longer ping and SSH) but it blocks a whole VLAN
IPv4 * VLAN7 net * 192.168.2.10 * * noneThe port on the switch connected to the unmanaged switch is port 11 which should be untagged.
Port 24 is the trunk which is tagged on each VLAN (if I understand correctly).
-
Then you are not sourcing from 192.168.1.250 like you think you are, the traffic is not coming into VLAN 2, or host 192.168.1.250 has another path to VLAN 7. You are applying the changes right?
Or your testing methodology is wrong and what you're really seeing is an already-established connection/state after you add the block rule.
Put the rule in place, establish a NEW ssh connection from 192.168.1.250 to 192.168.2.10 (which should fail).
If it succeeds, look at Diagnostics > States, filter on 192.168.2.10, and post the results.
You're looking for something like this:
LAN tcp 172.22.81.8:22 <- 192.168.223.6:57332 ESTABLISHED:ESTABLISHED
OFFICEVPN tcp 192.168.223.6:57332 -> 172.22.81.8:22 ESTABLISHED:ESTABLISHEDWhich represents an ssh session from 192.168.223.6 to 172.22.81.8.
-
Thanks! Your last post made me look in the right direction and I found the cause.
Then you are not sourcing from 192.168.1.250 like you think you are, the traffic is not coming into VLAN 2, or host 192.168.1.250 has another path to VLAN 7.
the server had another path..
A long time ago I created a jail on which I had to disable VIMAGE to get it to work the way I needed it. This seems to have caused a second IP address to exist on the same interface (192.168.1.245) which I didn't notice until now.
Weird thing was I SSH into 192.168.1.250 and when I start an SSH session from the server (from outside the jail) it goes out on 192.168.1.245. I need to look into this.
Anyway, once I added 192.168.1.245 instead of 192.168.1.250 to the rule everything worked as expected.If it succeeds, look at Diagnostics > States, filter on 192.168.2.10, and post the results.
Also thanks for this tip!
For completeness I add my output here as requested
VLAN7 tcp 192.168.2.130:22 <- 192.168.1.245:41476 FIN_WAIT_2:FIN_WAIT_2
VLAN2 tcp 192.168.1.245:41476 -> 192.168.2.130:22 FIN_WAIT_2:FIN_WAIT_2Thanks again for your time and help!
It was a learnful experience for me.
I can now use this to test and configure further.Is it recommended to prefix the subject with SOLVED?
-
the server had another path..
Actually, you weren't sourcing from .250.
Either way, glad you found it.