[ previous ] [ next ] [ threads ]
 
 From:  "Marc Fargas" <telenieko at gmail dot com>
 To:  "Michael Whitby" <m dot whitby at gmail dot com>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Traffic shaping over VPN for VoIP?
 Date:  Sat, 20 May 2006 15:34:05 +0200
As far as I know, IPSec is applied after all shaping, firewall, NAT,
routing, etc. It's done just before the packet leaves the network interface.
Sure Manuel has more deep knowledge on that and can confim if firewall is
also checked before doing IPSec, but I'm almost sure of that (Otherwise
you'd have to explicitly allow the traffic inside the VPN on the WAN
firewall).

Josh, you can take two computers on the LAN, put m0n0 on both and build a
small lab scenario, set traffic shaping on a per-port basis and use iperf on
different ports, then you can see how the shaping applies on high load. you
could build a nicer scenario putting phones on each side of link and playing
around. Know that the link-speed you define on traffic shaping is the speed
that will be used, no matter if you connect the boxes at 100Mbps, when you
setup the shaping say it's 56Kbps and it will go at 56Kbps!

On my case I do the traffic shaping on a per host basis as all traffic that
goes to/from the Asterisk server is for VoIP, and all phones have
reinvite=no which forces them to go throught Asterisk.

Michael, sure you can match either ports, addresses, or subnets either on
source or destination among other options.

On 5/19/06, Michael Whitby <m dot whitby at gmail dot com> wrote:
>
> Marc,
>
> This is certainly interesting! I beleived that this was not possible due
> to
> comments received by other m0n0wall users so what you have said certainly
> makes me interested, I am in the same position as Josh and wish to have
> m0n0wall's at all sites in a star toplogy toa central office, all will be
> linked via IPSEC from the m0n0wall devices - it sounds like you are saying
> I
> can just use the traffic shaper perfectly as normal and apply all shaping
> rules to the WAN interface and this will shape the traffic inside the
> tunnel
> aswell as traffic not in the tunnel, therefore to distinguish between
> traffic in the tunnel and traffic outside of it I could just specify
> remote
> subnets in the rules so that only traffic destined to the other subnets
> gets
> matched?
>
> cheers,
> Michael
>
>
> On 5/19/06, Josh Simoneau <jsimoneau at lmtcs dot com> wrote:
> >
> > Marc,
> >
> > Thank you for you excellent reply. The VPN will be IPSEC
> > monowall-to-monowall in a star configuration connecting remote locations
> > to the central office with the SIP server. So it would seem that I can
> > do traffic shaping on the WAN interface. I believe my scenerio is much
> > like yours. Currently the site is using non-monowall devices that do not
> > support QoS and it is causing problems with voice quality. I wanted to
> > be sure the m0n0wall solution would work before convincing them to swap
> > out their equipment.
> >
> > Regards,
> > Josh Simoneau
> >
> > ________________________________
> >
> > From: Marc Fargas [mailto:telenieko at gmail dot com]
> > Sent: Thursday, May 18, 2006 5:53 PM
> > To: Josh Simoneau
> > Cc: m0n0wall at lists dot m0n0 dot ch
> > Subject: Re: [m0n0wall] Traffic shaping over VPN for VoIP?
> >
> >
> > Hi Josh,
> > You have some options here, If the VPN is handled between m0n0 and the
> > Internet OR it is an IPSec one, you can define your traffic shaping on
> > the WAN interface taking care of traffic on ports 5060 & 5004 to be
> > highest priority, and traffic going from or to the SIP proxy (It will
> > depend if your devices can re-invite or use random SDP/RTP ports)
> >
> > In case the VPN is done on the m0n0 box but is not IPSec you'll have to
> > get the shaping done on LAN because traffic on WAN will be inside the
> > VPN and therefore you won't be able to distinguish VoIP traffic from
> > other VPN traffic, take care that placing the shaping on the LAN
> > interface means that download/upload means the opposite of what it means
> > on WAN (seen from m0n0).
> >
> > In case the VPN is done on the LAN by another device... you can only
> > "match" the VPN traffic as is on the traffic shaping without knowing if
> > it's VoIP or anything else.
> >
> > I'm not sure if m0n0 can match QoS fields (have no box at hand now to
> > look at), if it can you can 'tag' the packets on the device (if it
> > supports so) or on the VPN software (I think openvpn had the ability to
> > 'respect' the QoS on tunneled packets) that could help on case 3 above.
> >
> > Hope it helps a bit, on my case I'm in the first case of the list, IPSec
> > tunnels between some offices (fully-meshed) and SIP traffic between
> > them, traffic shaping is done on WAN on ports 5060 and 5004 as my
> > devices allow me to specify ports. And it works fine (I can start
> > massive downloads without downgrading the voice quallity).
> >
> > See you,
> > Marc.
> >
> >
> >
> > On 5/18/06, Josh Simoneau <jsimoneau at lmtcs dot com> wrote:
> >
> >         Greetings,
> >
> >         I wasn't able to get a definite answer searching through the
> > archives,
> >         maybe someone here can tell me if they have had success with
> > this. We
> >         want to put an VoIP server at one location, and then have two
> > remote
> >         locations connect to this over a VPN. Each location will have
> > its own
> >         private subnet. I want to ensure that m0n0wall is capable of
> > doing
> >         traffic shaping (is this considered QoS or is there something
> > special
> >         about traffic shaping that keeps it from using the QoS label?)
> > over the
> >         VPN connection so that voice calls remain the highest priority.
> > We will
> >         be using standard SIP stuff.
> >
> >         I have done many m0n0wall VPNs and many traffic shaping
> > configurations,
> >         but never traffic shaping over the VPN. I just want to be 100%
> > sure this
> >         will work before I move forward with the project.
> >
> >         Many Thanks,
> >         Josh Simoneau
> >         Inventor of Electricity
> >
> >
> > ---------------------------------------------------------------------
> >         To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> >         For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> >
> >
> >
> >
> >
> >
>
>