PFSense with Cisco 3560 VLAN Setup

[winet]

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.

[winet]

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

[winet]

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.

[blackbrayn]

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.

[marvosa]

@blackbrayn:

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.

[winet]

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)


[Derelict]

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.

[winet]

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.

[winet]

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.

[Derelict]

Hmm.  Seems a default route to pfSense would have been sufficient.