Forcing certain traffic over a certain wan.
-
I have a multi-wan/single-lan setup.
One of my wans is a T1.
I would like to set it up so that only voip, MSRDP, email, and dns go over this interface, and the other wans are used for everything else.
Along with that, my voip server can support 20 concurrent calls at 30K per call. So I need to dedicate at least 600Kbps of the 1.54Mbps T1 to voip traffic (do you think I should dedicate more just for some headroom to be safe?) and then the rest goes to MSRDP, email and dns queries. I don't want any other traffice going over the T1.I'm not ever sure if I use the traffic shaper for this? Or some sort of firewall rules? Port forwarding?
I posted here because traffic shaper made the most sense.When I tried the traffic shaper wizard, it didn't like that I was trying to dedicate more than 30% of the live to something, and I couldn't figure out how to manually create the traffic shaping queues. I'm a fast learner, so I just a point in the right direction on where I should start.
Thanks in advance for any and all help!
-
MicroMasters in IRC helped me come up with a solutions to this problem…
It goes as follows:
Under Firewall >> Rules >> Lan:
Create a rule for each port I want unblocked, and at the very bottom under "Advanced Features" >> click on "Default Gateway" and set the default gateway to the wan interface that I want all of the 4 traffic items flowing out of.THEN
Create a rule to "Block" for "any" to "any" going out the same default gateway that I set earlier.This way only my 4 traffic items are allowed out that connection, and nothing else.
Then, I need to perfect the art of traffic shaping the connection from there to dedicate a block of at least 600Kbps for my voip traffic.
He kindly pointed me in the way of this article:
http://doc.pfsense.org/index.php/Traffic_Shaping_Guide -
Nevermind.
I worked on it last night and couldn't get it to work. Maybe there's something I'm missing, but this is the setup that I tried to put in place that didn't work:
Proto Source Port Destination Port Gateway Queue Schedule
PASS * VOIPServer * * * WAN03 none
REJECT * VOIPServer * * * LoadBalanceOfWAN00&02 none
PASS TCP PRIMARYDC 53 (DNS) * * WAN03 none
PASS TCP SECONDARYDC 53 (DNS) * * WAN03 none
REJECT TCP PRIMARYDC 53 (DNS) * * LoadBalanceOfWAN00&02 none
REJECT TCP SECONDARYDC 53 (DNS) * * LoadBalanceOfWAN00&02 none
PASS TCP PRIMARYDC 25 (SMTP) * * WAN03 none
PASS TCP PRIMARYDC 143 (IMAP) * * WAN03 none
PASS TCP PRIMARYDC 80 (HTTP) * * WAN03 none
PASS TCP PRIMARYDC 443 (HTTPS) * * WAN03 none
PASS * * * * * WAN03 none^^^^^^^^ I know that all looks really ugly, but if you paste it into excel or something similar, it should format itself correctly. I couldn't figure out how to format a table on here nicely and easily without individually creating each row and column.
-
Oh, and this is the setup on my "LAN" tab in the "Firewall" >> "Rules" section.
-
For <=1mbps I'd use dedicated dsl line(s) (if you can get a cheap service level guaranteeing 1mbps both ways or similar) for voip and route non time critical traffic (Email web etc) over a different line(s).
Assume g729, 20ms packets, SIP, straight through no vpn etc etc prob 30kbps is ok. But G711 is really much better.
I'd get routing working first then worry about priority traffic of both signalling and the actual voice traffic second.
routing based on destination and src IPs? maybe something like fixed routes out and 1:1 nat in
If your just using the one WAN physical network card and Virtual IPs then System ->Advanced -> Firewall and NAT Disable reply-to on WAN rules should be selected AFAIK.
Anyway hope there is something in that you can use.
-
Move your reject rules to before your allow rules so it rejects the way you dont want it to go first then the next rule will allow where you do want it to go
REJECT * VOIPServer * * * LoadBalanceOfWAN00&02 none
PASS * VOIPServer * * * WAN03 none -
ya, i tried the role reversal, and figured the blocking should be first. Just to tell the server "hey, you can't use this connection, try something else." I'll try it again tonight. I think a large part of my issue is that I didn't flush the states. so it was still referencing old connections. I'll flush the states tonight when nobody is on, and try again.
-
oh, and squid/squidgaurd. I'm guessing I should add the exclusion list for the proxy? I haven't done that yet, not really thinking that that would muck things up for sure.
-
Flushing the states will solve your problem i have the same setup on a couple of jobs for my VoIP systems and email servers so each one uses a different WAN connection rules dont work until you reset the states
-
Try turning of squid to start with to confirm it works then add the exclusion and turn squid on other wise you maybe getting led up the garden path!!
-
other thing that I realized I did wrong: I had the protocol column set to TCP for almost all of them, INCLUDING the DNS rules. While DNS uses UDP almost all of the time. >_<
Another big DOH!
So I've set the DNS rules to TCP/UDP. i'll flush the states between 5/6 tonight when no one is on the network, and we'll try this again.
-
Hi I was just wondering how you got on?
-
Well, I dunno if I reset the states too many times? Or what… but my pfSense instance is TOAST. Was almst done getting everything worked out on it, when all of a sudden I couldn't get any traffic to flow through. Routing stopped completely. I could connect into the web gui. It show all of my connections were up and green, but no firewall traffic, and no open states (other than me connecting into the webgui) were showing. Everything else just died. And I couldn't get it back no matter what services I restarted and just plain stopped completely... it just wouldn't come back. I uninstalled all packages, disabled everything, loaded an old config backup, set back to factory defaults. Nothing worked. So I'm back to square one, TRIMing the SSD in the box and reinstalling pfSense from the ground up. Hopefully it won't die again on me for no reason.
-
Well I'm FINALLY back to where I last left off.
I got my box back up and running again and have all of my previous settings in place.
How do you think this looks for my rules setup?
-
LAN00 net * * * * none Default allow LAN to any rule
-
PhoneServer * * * FCGroup none
IGMP PhoneServer * 224.0.0.2 * FCGroup none
- PhoneServer * * * LBGroup none
TCP/UDP ClientsInternalDNS 53 (DNS) * * FCGroup none
TCP/UDP ClientsInternalDNS 53 (DNS) * * LBGroup none
TCP ExchangeServer PortsInternalEmail * * FCGroup none
-
-
-
-
- FCGroup none
-
-
-
Where FCGroup is the Failover Cluster group of WAN interfaces that's comprised of all wan adapters, but with the T1 setup as the primary (top tier) and DSL lines setup as the last ditch effort if the T1 goes down.
and LBGroup is the Load Balance group of WAN interfaces that's comprised of JUST DSL adapters.My efforts are set forth to accomplish having the DSL lines handle most of the interwebtubez traffic, while the T1 will handle phones, email, dns queries, and some terminal server sessions and NOTHING else.
You think my above setup will accomplish this????
-
-
I think the order of rules is wrong. I have been away for a few years so I am a but rusty but the more specific rules need to be at the top.
You have the general rules on top so the other rules wont get used. -
That is correct. You need to have the rules in top down order with the highest priority first. Basically the firewall is just going to start at the top of the list and look for a match. So you want to have a specific rule listed first so that way the traffic uses that rule. So in the case of DNS, you want to the first rule to mention any traffic using port 53 goes to your FCGroup. The firewall will hit that rule and use it to direct traffic accordingly. Even if you have another rule below it which will either block or direct traffic elsewhere the firewall won't process it since it doesn't need to. Just make sure all of your rules are specific and you don't need any block rules at all. They will simply process down the list until they either find the rule you intended for they make it to the default allow rule.
from your list it's a bit difficult to tell what each rule means, but just remember if the rule matches it will process which ever one is first. So in the case of:
LAN00 net * * * * none Default allow LAN to any rule
* * * * * FCGroup noneMost traffic is going to hit the default rule and the FCGroup rule will never be used. You do NOT want to have a reject rule before the allow rule otherwise you'll just block all traffic for that port. EDIT: Just want to be more clear that the firewall is only looking for the first match in the list. Once it finds a match the firewall doesn't continue on looking for either a block or a pass. If the first match is a block all of that traffic is going to be blocked, if the first match is pass then all of that traffic with be passed.
REJECT * VOIPServer * * * LoadBalanceOfWAN00&02 none
PASS * VOIPServer * * * WAN03 noneThat will simply drop all traffic going to the VOIPServer because the firewall is going to see that rule matches the traffic and will apply it.
If you have:
PASS * VOIPServer * * * WAN03 none
LAN00 net * * * * none Default allow LAN to any ruleThat is going to catch any traffic that is headed to the VOIPServer and pass it through that interface. If the traffics destination is not VOIPServer then it will simply skip that rule and move to the next one which says go out the default connection. Where you need to be careful is that in your instance it's going to pass ALL traffic headed for that IP down WAN03 and not just voip traffic. If you don't want other things like SSH, web requests, etc to use that you need to be more specific with your rule. I would probably limit the source to only your LAN subnet or even a smaller range of IP addresses on which your VOIP clients are on, and possibly have a port range so it only picks up traffic that is VOIP. Other traffic will still make it to the same destination, it will just do it using the default route instead of your WAN03 one.
-
K, thanx guys. I'll try this once I get my pfSense working AGAIN.
Second time it's broke on me.
You can view my other thread about my pfSense wigging out here:
http://forum.pfsense.org/index.php/topic,49331.msg261712.html#msg261712
Once I have it back in a working state I'll check this out again and work out the kinks of my ruleset.
Thanx again for the help!