[SOLVED] VLAN treachery - DHCP Addresses but No Internet Access
-
Okay, so I'm trying to VLAN a NetGear ProSafe GS108Tv2 smart switch with my pfSense appliance.
In the VLANs, I have only one separate VLAN set up on my LAN interface, VLAN 100. I've created an interface on pfSense for that VLAN on the LAN port on my VK-T40E appliance.
On the switch, I've configured the VLANs and set up VLANID 100. Under VLAN Membership, the uplink port (port 1) has the following set for it:
VLAN1: Untagged
VLAN100: TaggedPort 7 on the switch, has a PVID set of VLAN 100. It is also configured as follows:
VLAN1: (Removed)
VLAN100: TaggedThe client connected to the port on the switch (port 7) is getting DHCP addresses from pfSense correctly within the range set for DHCP on VLAN100, but is unable to reach out to the Internet.
The VLAN100 interface as a IPv4 ALLOW ANY->ANY rule in place, so I dont think it'd be the firewall rules. Any idea where I should check next?
-
did you configure the client to send TAGGED packages? (since you configured the port that way)
simple clients generally live on UNTAGGED ports.
did you set the PVID correctly on port 7 ?If all above appears correct … can you ping a pfsense-interface from the client? Can you now get to the internet?
-
I don't know how you're getting DHCP, but unless you've configured a tagged interface on the client computer, the port the computer is connected to should be untagged 100.
-
Forgot to mention before I hit "Save" on my last edit that I did in fact do advanced PVID configuration on the switch, it's currently configured such that the port on the switch is configured for VLAN100. The client computer is an Lubuntu system that's connected to the switch and isn't configured to send any type of tagged packets. However, it is getting a DHCP address from the pfSense firewall within the DHCP range I've set.
I checked if the port the client is on is marked "UNTAGGED" on that VLAN and I changed it to UNTAGGED, still no dice and no internet/outbound connection to the Internet.
-
untag port 7
-
untag port 7
Read the edit to the last message I posted, even untagged it's still resulting in no access to anything.
Having said this, I also can't reach anything else on the network, not the switch management IP (which is 10.0.10.1), not the wireless interface (on OPT1), and not even the 10.0.0.1 I've set for the pfSense admin page as the LAN interface IP (without the VLAN). Not entirely sure where to go from here…
-
so basically we have this?:
Switch management IP: 10.0.10.1/24
Pfsense_no_vlan: 10.0.10.x /24
Pfsense_Vlan100: 10.0.0.1/24
Client_Port7: 10.0.0.x/24 -
so basically we have this?:
Switch management IP: 10.0.10.1/24
Pfsense_no_vlan: 10.0.10.x /24
Pfsense_Vlan100: 10.0.0.1/24
Client_Port7: 10.0.0.x/24This is effectively what's configured, going from pfSense to the client:
pfSense LAN Interface: 10.0.0.1/8 (DHCP Off)
Switch Management IP: 10.0.10.1/8 (static)
pfSense VLAN100: 10.100.0.1/16; DHCP Range is 10.100.10.1 - 10.100.20.255
Switch_Port7: VLAN100
Client_PC (connected to Switch_Port7): 10.100.10.1/16The switch can be reached from the one device on OPT1 I have which is allowed to reach to all the other subnets/vlans/interfaces in pfSense. Devices downstream from the switch on VLAN 100 can't be reached (including in VLAN100), however the other ports which are just marked as VLAN1 by default (and are static IP assigned to the IP range inside of 10.0.0.1 - 10.0.7.255 for the LAN interface range) are able to be reached and can reach outside to the Internet.
(NOTE: I think this may be more than just a VLAN issue, so any help in diagnosing/fixing this will help me NOT make mistakes in the future.)
-
You can't use 10.0.0.0/8 and 10.X.X.X/16. those subnets conflict.
-
You can't use 10.0.0.0/8 and 10.X.X.X/16. those subnets conflict.
facepalms Doh, I knew I forgot something. I've given the non-VLAN'd LAN 10.0.0.0/16 and left the rest as it was, and tweaked the config on the switch itself so it has the right net mask.
Anyways, weird discovery: Apparently there was a static DHCP assignment that got added for the client system and somehow THAT broke VLAN routing of information. Either that, or
dhclient
decided to go and break itself. It looks like the issue might've been related to that, because now data's being routed correctly. shrugs