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
On 5/19/06, Josh Simoneau <jsimoneau at lmtcs dot com> wrote:
> 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.
> 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,
> On 5/18/06, Josh Simoneau <jsimoneau at lmtcs dot com> wrote:
> I wasn't able to get a definite answer searching through the
> 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
> locations connect to this over a VPN. Each location will have
> its own
> private subnet. I want to ensure that m0n0wall is capable of
> traffic shaping (is this considered QoS or is there something
> 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
> 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