SLUG Mailing List Archives
Re: [SLUG] route traffic through multiple interfaces
- To: slug@xxxxxxxxxxx
- Subject: Re: [SLUG] route traffic through multiple interfaces
- From: Daniel Pittman <daniel@xxxxxxxxxxxx>
- Date: Fri, 05 Sep 2008 14:36:08 +1000
- Organization: I know I put it down here, somewhere.
- User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/23.0.60 (gnu/linux)
"Chris Zhang" <sangiorgiomaggiore@xxxxxxxxx> writes:
> On Fri, Sep 5, 2008 at 11:16 AM, Daniel Pittman <daniel@xxxxxxxxxxxx> wrote:
> "Chris Zhang" <sangiorgiomaggiore@xxxxxxxxx> writes:
> You were correct in guessing what I was after. I am trying to get VOIP
> working over 3G.
> My understanding is that there are at least two places this can be
> Firstly, the app(e.g. Truphone) won't let you connect unless you have
> a working WIFI connection. This is why I was asking for NATting
> possibility(I didn't describe it properly). - Assign wifi interface
> with an IP (192.168.1.1/24) and forward all traffic to 3G interface
> with a public IP.
> Since 'ipfw' won't work the way it does in a normal BSD, the only
> thing I thought would be changing the routing table, which you pointed
> out not possible.
I wouldn't expect so, but I don't know the BSD / Apple IP stack nearly
as well as the Linux stack, so it /may/ be able to implement suitable
policy routing or NAT for you...
I wouldn't hold my breath though. Like buying a games console, Apple
products are "no user serviceable parts" systems: use it their way, or
face a life of hoping that you keep ahead of their efforts to stop you.
> The other place where VOIP might get blocked is from the ISP,
> e.g. filtering on 3G network. My thought was to setup a tunnel and
> encrypt VOIP inside that tunnel. It should in theory bypass ISP
> restriction shouldn't it?
Yes, assuming that they will pass the tunnelled VPN traffic. It is
worth noting that you are probably going to be violating your
contractual agreement with the ISP at this point, and that they *will*
kick you off the contract -- or worse -- for this.
Like the device, if you really want to run VoIP from the phone it
probably pays to go ahead and find a contract that meets your needs up
front than to try an end-run around the ISP / vendor.
> Alternatively, I am not sure if VOIP works over a socks proxy. This
> requires iPhone being a socks client, which it doesn't support, nor
> have I found any thrid party apps that can do this.
Of course not -- Apple have already pulled at least one application from
their store that made the device act as a wireless to 3G router, and
have a policy that this will *not* happen.
A SOCKS proxy would face the same fate: not on the approved list, so no
ability to run it. Look forward to breaking the security on the phone,
then watching the anti-"piracy" parts of Apple get nastier to what you
do, if you really intend to use this.
> Last resort would prob. be ssh tunnelling. but I doubt this would work
> since the ports VOIP uses are in 10,000 ~ 20,000 range?
That depends on your client, but you really do *NOT* want to push UDP
over TCP, which ssh tunnelling is.
> This is the idea, except for the packets won't go out to wire. Traffic
> => NIC A's IP => NIC B's IP => NIC B's gateway. This is, as you
> pointed out, NATing, I am convinced it is not possible without
> iptables or such.
Correct: this is not something that a regular routing table can do.
There /might/ be an equivalent of the "fast NAT" feature of the Linux
routing table available to you, but I don't hold much hope...