CP + Inter VLAN routing
-
I have a setup were I have 2 VLANs, one for wired clients and one for WiFi users. Both VLANs use a separate CP zone, since i need to configure different bandwidth limits for both VLANs.
All works fine. But now I'm getting a request to configure inter VLAN routing since WiFi clients need to access resources on the wired VLAN ( a server ).
I can't configure the inter VLAN on the access switch since that's not allowed for security reasons.
So I need to configure the inter VLAN routing on the pfSense. But I don't know how. I'm looking for so,me option were I can bypass the CP when I route to a local address ex. WiFi VLAN to wired VLAN.
I could just allow the servers to bypass the CP I guess but I don't really want to go trough CP.
Hope someone can help me out to figure this out.
Here's some drawing of the situation:
WiFi VLAN –---------------------------------------------------------------- CP --------------------------UTM -------- WWW
|
Inter VLANrouting needed here
|
Wired VLAN -----------------------------------------------------------------CP--------------------------UTM--------WWWThanks in advance
-
What device(s) is/are the default gateway(s) for hosts on both VLANs?
-
Default gateways for both VLANs a are the pfSense interfaces.
-
So just put pass rules on the Wi-Fi interface for the servers/ports on Wired you want them to have access to. If you want them to have access to these servers whether or not they're through the portal, put the server IP in allowed IP addresses in the Wi-Fi CP and probably a MAC address pass-through for the server in the Wired CP. Better would be to move the server outside of the CP onto another interface.
-
If I put the MAC of the server in the passtrough would the bandwidth limits still apply to the WiFi users? ( I could simply test this but I can't access the box right now and just need some ideas before I start on it next week)
I could set the server on a different interfaces/VLAN without a CP. That way I could add the IP of the server in the allow IP on the WiFi CP. I guess that is what u mean with: Better put it on a different interface.
-
So I saw a reply of you Derelict were u stated to change some things in captiveportal.inc.
The uidea was to change the ipfw in captiveportal.inc. So that would result in something like:
pass traffic destined for Wired VLAN
add 65531 pass ip from Wifi subnet to Wired subnet in
I couldn't determined if this worked but I would love this approach.
-
Yes. That's what I mean by another interface.
Your limiters should still apply to the CP clients even with pass-through entries, though not for the traffic to/from that server. You could probably generically limit that traffic with a limiter defined just for that.
No, I wouldn't modify captiveportal.inc. I would put the IP in the allowed IPs and limit the ports with firewall rules.
-
Alright that would be fine as long as the bandwidth limit won't apply.
Thanks for your fast ( and with fast I mean really fast) reply on my question!
-
So I tried both solutions. Adding the MACs and IPs manually and editing captiveportal.inc
Both worked perfectly. I chose for the later since I need to deploy the same config around 20 times. It would take to much time adding all those IP addresses manually.
-
Your limiters should still apply to the CP clients even with pass-through entries, though not for the traffic to/from that server. You could probably generically limit that traffic with a limiter defined just for that.
Actually, I can't remember in what order the rules are processed. I'm pretty sure your traffic to the pass-through devices will not be limited before adding the captive portal entry by logging in but they might be in effect afterward.
-
Sounds right. I'll test it next week to make sure.
-
You do not need any of these apart adding allowed ips for the services to be reached and firewall rules to allow the services to be reached.
-
Yes but its easier for me to add a whole subnet in captiveportal.inc since I have no control what IPs the servers will get. I only supply a pre configured pfsense.