VLAN problem (long) [solved kind of]
-
sorry for the long post but can someone tell me if this is a bug or behaviour i have to expect?
First what works:
THIS WORKS!client1 client2 | | | | LAN1 LAN pfSense1-Link1----Link2-pfSense2 | | WAN1 WAN2 \ / \ / \ / \ / \ / Gateway
Both pfSenses are fresh setup 1.2RC2
pfSense1 is embedded
Client1: 10.0.0.200/24
LAN1: 10.0.0.1/24
Link1: 172.16.0.1/30
WAN1: 192.168.20.6/29pfSense2 is a fullInstall
Client2: 10.0.4.200/24
LAN2: 10.0.4.1/24
Link2: 172.16.0.2/30
WAN2: 192.168.20.5/29Gateway: 192.168.20.1/29
On all interfaces a rule allow any-to-any
Enabled on both pfSenses RIP on LAN and LINK.I can ping from everywhere to everywhere and transfer data. No problems at all.
–------------------------------------------------------------------------------
now where the problems start:Assuming i dont have 3 real interfaces per box i start using VLANs.
client1 client2 | | | | LAN1 LAN pfSense1 pfSense2 | | WAN1/Link1 WAN2/Link2 \ / \ / \ / \ / \ / \ / \ / Switch | Gateway
Both pfSenses are fresh setup 1.2RC2
pfSense1 is embedded
Client1: 10.0.0.200/24
LAN1: 10.0.0.1/24
Link1: VLAN400 172.16.0.1/30
WAN1: 192.168.20.6/29pfSense2 is a fullInstall
Client2: 10.0.4.200/24
LAN2: 10.0.4.1/24
Link2: VLAN400 172.16.0.2/30
WAN2: 192.168.20.5/29Gateway: 192.168.20.1/29
On all interfaces a rule allow any-to-any
Enabled on both pfSenses RIP on LAN and LINK.After assigning the VLAN's and changing the Link-Interface from the real Interface to the VLAN Interface, it doesnt come up. even if it's activated in config it's still marked down on the interface list.
After deactivating and reactivating it is marked as up and i can ping it but not the other side of the link.–> ping from pfsense1 to Link1-IP(172.16.0.1) successfull.
--> ping from pfsense1 to Link2-IP(172.16.0.2) no response.
--> ping from pfsense2 to Link2-IP(172.16.0.2) successfull.
--> ping from pfsense2 to Link1-IP(172.16.0.1) no response.also i get lots of messages in the log like:
Aug 30 00:26:54 last message repeated 2 times
Aug 30 00:26:54 last message repeated 2 times
Aug 30 00:24:54 routed[5773]: vlan0 (172.16.0.1/30) is duplicated by sis2 (172.16.0.1/30)
Aug 30 00:24:54 routed[5773]: vlan0 (172.16.0.1/30) is duplicated by sis2 (172.16.0.1/30)
Aug 30 00:23:54 routed[5773]: vlan0 (172.16.0.1/30) is duplicated by sis2 (172.16.0.1/30)
Aug 30 00:23:54 routed[5773]: vlan0 (172.16.0.1/30) is duplicated by sis2 (172.16.0.1/30)
Aug 30 00:23:10 login: login on console as root
Aug 30 00:23:05 login: login on console as root
Aug 30 00:23:00 check_reload_status: reloading filter
Aug 30 00:22:54 routed[5773]: vlan0 (172.16.0.1/30) is duplicated by sis2 (172.16.0.1/30)
Aug 30 00:22:46 last message repeated 2 times
Aug 30 00:22:54 routed[5773]: vlan0 (172.16.0.1/30) is duplicated by sis2 (172.16.0.1/30)looks to me like a conflict between the old interface config with the new config
after a reboot these messages go away.now i can ping from everywhere to everywhere
i can ping.
but that's about it.if i try to connect from client1(10.0.0.200) to the pfSense2 on Link2-IP(172.16.0.2) i get the prompt for the login and then it loads and loads and loads
and i just have a blank screen.
if i look at the state-table of pfsense1 i see the following state:tcp 10.0.0.200:3420 -> 172.16.0.1:64705 -> 172.16.0.2:80 ESTABLISHED:ESTABLISHED
so "something" has to go through.
if i try to connect to a normal windows share from client1 on client2 i get something similar.
i get the password prompt and the normal window where you can see shared printers and shared folder:
but as soon as i try to open one of the folders the connection dies.
states:tcp 10.0.0.200:3451 -> 172.16.0.1:54010 -> 10.0.4.200:139 ESTABLISHED:SYN_SENT
tcp 10.0.0.200:3439 -> 172.16.0.1:52263 -> 10.0.4.200:445 TIME_WAIT:TIME_WAIT
tcp 172.16.0.1:60272 <- 10.0.4.200:445 CLOSED:SYN_SENT
tcp 10.0.0.200:3450 -> 172.16.0.1:62935 -> 10.0.4.200:445 ESTABLISHED:ESTABLISHED
udp 224.0.0.9:520 <- 10.0.0.1:520 NO_TRAFFIC:SINGLE
udp 224.0.0.9:520 <- 172.16.0.1:520 NO_TRAFFIC:SINGLE
udp 224.0.0.9:520 <- 172.16.0.2:520 NO_TRAFFIC:SINGLE
udp 10.0.0.1:520 -> 224.0.0.9:520 SINGLE:NO_TRAFFIC
udp 172.16.0.1:520 -> 224.0.0.9:520 SINGLE:NO_TRAFFICi tried the following
i went back to connect the two boxes with a cable directly on a real interface ans setup the VLAN on this third interface.
like this:client1 client2 | | | | LAN1 LAN pfSense1-Link1----Link2-pfSense2 | | WAN1 WAN2 \ / \ / \ / \ / \ / Gateway
Both pfSenses are fresh setup 1.2RC2
pfSense1 is embedded
Client1: 10.0.0.200/24
LAN1: 10.0.0.1/24
Link1: VLAN400 172.16.0.1/30
WAN1: 192.168.20.6/29pfSense2 is a fullInstall
Client2: 10.0.4.200/24
LAN2: 10.0.4.1/24
Link2: VLAN400 172.16.0.2/30
WAN2: 192.168.20.5/29Gateway: 192.168.20.1/29
On all interfaces a rule allow any-to-any
Enabled on both pfSenses RIP on LAN and LINK.this works again O_o
with the following statestcp 10.0.0.200:3528 -> 172.16.0.1:60112 -> 10.0.4.200:139 ESTABLISHED:SYN_SENT
tcp 10.0.0.200:3513 -> 172.16.0.1:55611 -> 10.0.4.200:445 TIME_WAIT:TIME_WAIT
tcp 10.0.0.200:3527 -> 172.16.0.1:65438 -> 10.0.4.200:445 ESTABLISHED:ESTABLISHED
udp 224.0.0.9:520 <- 10.0.0.1:520 NO_TRAFFIC:SINGLE
udp 224.0.0.9:520 <- 172.16.0.1:520 NO_TRAFFIC:SINGLE
udp 224.0.0.9:520 <- 172.16.0.2:520 NO_TRAFFIC:SINGLE
udp 10.0.0.1:520 -> 224.0.0.9:520 SINGLE:NO_TRAFFIC
udp 172.16.0.1:520 -> 224.0.0.9:520 SINGLE:NO_TRAFFIC
udp 10.0.0.255:138 <- 10.0.0.200:138 NO_TRAFFIC:SINGLENow i tried something different:
I took a VLAN capable Switch.client1 client2 | | | | LAN1 LAN pfSense1 pfSense2 | | WAN1/Link1 WAN2/Link2 \ / \ / \ / \ / \ / \ / \ / VLAN-Switch | Gateway
Both pfSenses are fresh setup 1.2RC2
pfSense1 is embedded
Client1: 10.0.0.200/24
LAN1: 10.0.0.1/24
Link1: VLAN401 172.16.0.1/30
WAN1: 192.168.20.6/29pfSense2 is a fullInstall
Client2: 10.0.4.200/24
LAN2: 10.0.4.1/24
Link2: VLAN400 172.16.0.2/30
WAN2: 192.168.20.5/29Gateway: 192.168.20.1/29
On all interfaces a rule allow any-to-any
Enabled on both pfSenses RIP on LAN and LINK.As you can see i changed the VLAN on Link1 from 400 to 401
IEEE 802.1Q PVID Table Port PVID 01 300 02 300 03 301 04 301 20 2 21 401 22 2 23 400 24 2
IEEE 802.1Q VLAN Settings VLAN ID Member Port 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 300 U U 301 U U 400 U T 2 U U U 401 T U
WAN1 to 20
WAN2 to 24
Cable to Gateway 22
all egress untagged.Link1 to 20
Link2 to 24
egress tagged
the same data gets eggressed untagged on ports 21 and 23
now i just took a short cable and connected 23 with 21.what i basically did:
the untagged data from pfsense (traffic on WAN) can go to the gateway.
the tagged data from pfsense gets untagged and then retagged (convert from 400 to 401 and vice versa)and that works
So traffic is possible from everywhere to everywhere–------------------------------------------------------------------------------
Now my problem is i dont have enought cables.
pfSense1 and Gateway are in the same place. pfSense2 is in another place and i have only 1 cable between them.I changed the network in the following manner
client2 | | LAN2 pfSense2 | Link2 WAN2 | |________Client1 | LAN1 Link1 Uplink1 | pfSense1 | Gateway
Both pfSenses are fresh setup 1.2RC2
pfSense1 is embedded
Client1: 10.0.0.200/24
LAN1: 10.0.0.1/24
Link1: VLAN400172.16.0.1/30
Uplink1: VLAN500192.168.10.1/30
WAN1: 192.168.20.6/29pfSense2 is a fullInstall
Client2: 10.0.4.200/24
LAN2: 10.0.4.1/24
Link2: VLAN400172.16.0.2/30
WAN2: VLAN500192.168.10.2/30Gateway: 192.168.20.1/29
On all interfaces a rule allow any-to-any
Enabled on both pfSenses RIP on LAN and LINK.As before just like this it does not work.
Even worse. i can define the first interface but as soon as the second interface is activated all VLANs go down (link down).I did the same "workaround" than before with a VLAN capable switch and retagging Link1 to VLAN401, and Uplink1 to VLAN501 and that works now.
But i would prefer if there was an easier way than having a switch in between that does nothing than retag packets.
(unfortunately VLAN-capable switches dont grow on tree's :( especially not for poor students :D )
Any suggestions?Greeting
Matthias -
i tried something else.
i stopped doing the retagging.Link1: VLAN400 172.16.0.1/30
Uplink1: VLAN500 192.168.10.1/30Link2: VLAN400 172.16.0.2/30
WAN2: VLAN500 192.168.10.2/30and i changed the ports on the switch to:
IEEE 802.1Q PVID Table Port PVID 20 2 22 2 24 2
IEEE 802.1Q VLAN Settings VLAN ID Member Port 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 400 T T 2 U U U 500 T T
and this works just well.
now i think it's very strange that i cannot establish a VLAN link between 2 pfSenses with a normal "dumb" switch that should just forward the VLAN tagged packets, but with a VLAN switcht it works.
So i took a old 100Mbit Hub which is even dumber than a normal switch.
and it works too…...so i went back to my original switch an plugged back in... and i stops working again.
has anyone ever experienced something like this?
-
Hi!
i assume the "non-VLAN-capable-switch" wants to look at the packet and does not find the right information at the right place (arp, vlan-tag) and thus throws away the packet. the capable switch will look at it and interpret it correctly. The hub though does "garbage in - garbage out" and seems to do the job?
I must assume that it was not very clear to me what you are trying to achieve from your description (I might be to tired or lazy imagining everything/the ascii drawing didn't make it to well). maybe you point out the goal and there is an easier solution?btw there are vlan capable switches for CHF 200 (linksys 8 port) or if you want to fiddle around with it: get a linksys router CHF 90 at the ETH discount, add the linux WRT54G firmware on top and see you have a 4 port VLAN capable cheapo switch. ;-)
with this, you might even save the money for one of the pfsense boxes?on the other hand, if you could give me a hint with the IPSEC question, I would be greatful. ;-)
Best,
B.
-
Suggestion for CHF 90?
-
Thanks for your suggestions about the VLAN switches.
But i probably wont buy for 200.- an 8-port if i can get for 300.- a gigabit-capable 24 port switch :)But i solved the problem with just another normal switch for 24.- from steg. Wireshark helped in the end find the problem with packages delivered to the wrong port because of messed up ARP.
-
OK. Great to hear!
BTW: Just for the records, can you mention what brands the working and the notworking switches are?
Thanks!