VLAN rule ignored because of unmanaged switch?
-
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.