PFSense with Cisco 3560 VLAN Setup
-
OP, my setup is nearly identical to yours and working. You didn't need any of that extra work on PFsense… all you needed was a routed port with an IP address of 192.168.20.254 and you were home free.
Of course you would need to either change the IP range of VLAN 100 or... change the LAN subnet on PFsense, assign your routed port an IP in the PFsense LAN and modify your default route accordingly.
-
marvosa, I appreciate the insight.
You highlighted o my my primary challenges with this setup.
Vlan 100 is a production network, service clients and hosts servers.
An outage for entire reconfig is not permissible at this time, so I am attempting to bring functionality without interruption in service.With the setup I outlined, I was bale to service clients on all Vlan and ironed out the issues with devices as Chromecast on any Vlan, however I have not been able to permit the pass through of servers and services that required access prior to Captive Portal Login, say for example a server that provided clients the opportunity to create and account so that they are able to use said account to in turn login to Captive Portal.
I attempted an alternate configuration consistent with the PFsense 2.1 guide and having some functionality issues, please review below and let me know what you think.
On the PFsense Box
WAN - bge0 - Interface WAN - 192.168.1.254 /24
LAN - xl0 - Interface LAN - 192.168.20.254
Other Interface - xl1 - In not assigned an interfaceVlans
Vlan 10 0n xl1 - 10.110.110.254 / 24
Vlan 11 0n xl1 - 10.110.111.254 / 24
Vlan 12 0n xl1 - 10.110.112.254 / 24DHCP, DNS, Captive Portal configured for all interfaceswith the exception of bge0 and xl1.
According to the guide, the parent interface refers to the physical interface where the VLANs reside, such as em0 or bge0, in my case (xl1).
When you configure VLANs on pfSense, each is assigned a virtual interface, starting with vlan0 and incrementing by one for each additional VLAN configured.
You should not assign your parent interface to any interface on pfSense — its sole function should be as the parent for the defined VLANs.On Cisco 3560
VTP Database - Vlan 10, Vlan 11, Vlan 12
Interface Vlan10 - 10.110.110.253 /24
Interface Vlan11 - 10.110.111.253 /24
Interface Vlan12 - 10.110.112.253 /24
The guide did not specify the need for these interfaces, I created them to be able to access core switch from respective vlans.Interface Fast 0/24 - Switchport mode trunk, switchport trunk dot1q, permit vlan all.
Interface Fast 0/8 - switchport access Vlan 10
Interface Fast 0/9 - switchport access Vlan 11Here is the challenge I face, clients are able to successfully engage DHCP services and are provided an IP address in the respective Vlan when connected to that vlan's associated port.
From the PFsense box, I am able to ping the clients with no challenge, everything appears to work well.
From the client, I am not able to ping the PFsense box at all.
The clients are pointed to their respective vlan interface IP address as their default gateway (10.110.110.254 and 10.110.111.254 respectively).I have read and read read the guide and also drew on other configurations examples and challenges outlined on the web, I have not yet found something that will help me resolve this challenge.
Do you have any pointers?
Appreciated.
-
I'm confused why you think you need layer3 interfaces on the switch AND pfSense. When do you route traffic to 10.110.111.253, for instance? But it's pretty harmless I guess.
Do you have the necessary firewall rules on the vlan11 and vlan12 interfaces on pfSense allowing the traffic into the interfaces? The rules allowing DHCP are automatically and transparently entered for you when you enable the DHCP server. Rules allowing all other traffic are not.
-
Thanks Derelict, in response to you feedback,
I'm confused why you think you need layer3 interfaces on the switch AND pfSense.
I do not think I need the L3 interfaces on the switch, I configured them as a means to get connectivity to the switch from every Vlan , say ssh for example.When do you route traffic to 10.110.111.253, for instance?
I do not route any traffic through these interfaces, I intend to use these to simply initiate connects to the switch as and when necessary from respective Vlans.Do you have the necessary firewall rules on the vlan11 and vlan12 interfaces on pfSense allowing the traffic into the interfaces?
Yes, I enabled a allow all rule on all Interfaces to ensure these were not getting in my way. All interfaces configured with a pass any any rule.Appreciate your support.
-
I neglected to point out this bit of info in my last representation of the configurations.
Interface Fast 0/24 - Switchport mode trunk, switchport trunk dot1q, permit Vlan all - Fast 0/24 is connected directly to xl1 interface on PFsense box.
Thanks
-
Just an update for anyone reading this post while looking for help.
My challenge with not being able to ping or communicate with respective Vlan gateways was as a result of incorrectly specified firewall rules.
I permitted traffic from anyone to anyone however that traffic was still specified as TCP in the protocol field.
Once the rule is update to Any protocol, from any network to any network I was able to successfully get out to the Internet using a host on any Vlan.I continue to iron out one challenge which, going on all the documentation I have seen appears to be hardware related.
Using a X1(4) interface with long frame support, but not Vlan hardware support appears to be inhibiting my ability to communicate to other hosts on the home network other than the default gateway. -
In my opinion , the c3560 should be used just as a switch and you can configure all the L3 interfaces on the pfsense box.
It would be more flexible , and there si no need to do static routing for every new subnet.
Not to mention - if problems occur , you can tcpudmp on the selected vlan straight from the pfsense box , not on all the L3 trafic + you are able to dump L2 trafic that you can't directly see from the current setup. -
In my opinion , the c3560 should be used just as a switch and you can configure all the L3 interfaces on the pfsense box.
It would be more flexible , and there si no need to do static routing for every new subnet.
Not to mention - if problems occur , you can tcpudmp on the selected vlan straight from the pfsense box , not on all the L3 trafic + you are able to dump L2 trafic that you can't directly see from the current setup.I disagree, it depends on your priorities. His current setup is going to give him the best performance as all inter-vlan traffic will be handled by the switch and only routing internet traffic to PFsense. Your suggestion would send inter-vlan traffic through PFsense, which could saturate that link and cause performance issues throughout the network.
The only thing you gain by terminating vlans on PFsense is the ability to have a firewall between vlans.
-
I appreciate both your inputs, very valid.
blackbrayn approached this from a ease of setup perspective while marvosa more so from a functionality perspective.
marvosa's point is exactly why I chose this setup, have the core switch manage all traffic local to the network and forward only traffic destined to the Internet to the PF box.I have also configured consistent with PF 2.1 manual, which instructs the use of an alternate interface which results in the creation of the Vlans on the PF box and also addresses the issue of potential bottle neck as the local network traffic remains on the alternate Interface.
See the attached for diagram of that setup.
Even with the PF recommended setup, I continue to experience a challenge where clients on respective Vlans are not able to communicate with hosts on the home network segment (LAN) other than the address of the LAN interface. Vlan clients can see out to the Internet, login to captive portal, but are not able to access production servers on the LAN network.
My research so far points to my interface type not being able to handle Vlan hardware support, according to manual, routing between all locally created network on the PF box is automatic. Here is what the manual says about the adapters, I have one of the X1(4) adapters. Any ideas?
If you encounter problems using one of the NICs listed under long frame support, trying an interface with VLAN hardware tagging support is recommended. We are not aware of any similar problems with NICs listed under VLAN hardware support.
Ethernet interfaces with VLAN hardware support:
bce(4), bge(4), cxgb(4), em(4), ixgb(4), msk(4), nge(4), re(4), stge(4), ti(4),
txp(4), vge(4).Ethernet interfaces with long frame support:
bfe(4), dc(4), fxp(4), gem(4), hme(4), le(4), nfe(4), nve(4), rl(4), sis(4), sk(4), ste(4), tl(4), tx(4), vr(4), xl(4)
 -
So are there SVIs on the switch or just VLANs? Your diagram looks like the interface addresses are on pfSense. Looks like even though the switch is in layer 3 mode you're using it as layer 2 which is fine.
Are the comments at the bottom of your diagram how it's working or how you want it to work?
There is no need for the clients behind the 3560 to be able to talk to the RADIUS server. Only pfSense has to do that. if you want them to, you need the proper firewall rules on your pfSense interfaces to pass the traffic.
-
Appreciate the feedback Derelict.
Per the 2.1 manual, one only need to configure identical vlan info on the core switch and not necessarily an interface.I have been over the Firewall rules for some time and currently I pass any protocol, form any host, to any host on all interfaces other than the WAN.
Regards connecting to the server, I require this functionality as the server also supports user services that may need to be accessed before the user can successfully login to the network, password reset for example.
I appreciate the insight, I am looking these rules over again.
-
All to close up this post.
The issue was one of routing, not on the PF box though.Going on the last net diagram, I had to make static entries to the respective Networks (Vlans, 10, 11, …) on the authentication server.
Had to tell the server how to get traffic back to the VLans.With that in place, everything works nicely.
Appreciates your insights.
-
Hmm. Seems a default route to pfSense would have been sufficient.