[oclug] Repost from OCLUG Tech list
Bill Strosberg
oclug at strosberg.com
Wed Sep 2 12:41:26 EDT 2009
Brad Barnett wrote:
> Bill,
>
> A bit of what you are saying, needs clarification (at least for me to
> grok ;) .
>
> However, I only think two or three people on this list will even know how
> to do what you want. I've done similar things for several clients, but
> most people don't even know about iproute2, let alone how to even
> calculate a netmask.
>
> Anyhow, before I ask my questions, I suggest you try posting to the LARTC
> list.
>
> http://lartc.org/
>
> http://lartc.org/#mailinglist
>
> This is the place to go for more in depth routing questions. You'll
> move from two or three able bodies, to hundreds that are capable of
> understanding your issue...
> Anyhow, on to your question below.
>
> One thing I find confusing, is that you mention that all external traffic
> comes through the VOIP router, but then you mention that you want to
> route external traffic through the VOIP router.
>
> You also say that the VOIP router can route traffic through an alternate
> ethernet interface, if the primary is down.
>
> So, do you want to route all external network traffic through the VOIP
> router, because during a failover, traffic is supposed to from your VOIP
> connection, into your Linux box, then to the router, then to your Linux
> box, then to your internal network??
>
> This seems a bit weird!
>
> I'll show you what network diagram I have in my head:
>
> internet via eth2/ppp0 ==
> | Internet | from VOIP = VOIP
box=eth3= linux router = internal network (eth0)
> provider
>
>
> (I've ignored the wireless connection for now)
>
> So, I'm not sure why you'd want to route traffic from ppp0, through eth3,
> into the VOIP router...
>
> I'm also confused as to why you're routing external Chinese IPs, from
> ppp0, through to the VOIP provider..
>
> Anyhow, one thing you can do, to better control routing, is to mark
> packets. Once packets are marked, you can then use iptables to control
> where they can go, and what they can do.
> Example:
>
> ip ru add fwmark 0x12 table 40
> (packets marked with mark 12 go into table 40)
> ip route add default via 10.10.10.10 src 10.10.10.16 table 40
> (same idea you have)
> ip rule add from 10.10.10.16 table 40
> (note, this is a duplicate of what I'm doing below, and above, with
mark!)
> iptables -t mangle -I OUTPUT -s 10.10.10.16 -j MARK --set-mark 12
> (mark those packets!)
>
> Part of the problem, is that routing only works at a certain part of the
> chain. NAT, source and destination mangling, and so on, can alter
> whether or not the "ip rule add from 10.10.10.16 table 40" or "iptables
> -t mangle -I OUTPUT -s 10.10.10.16 -j MARK --set-mark 12" works to add
> that packet to the table you want...
>
> This is due to the fact that Linux routing is still a little wonky, and
> additionally, Linux routing keeps changing. The last 3 or 4 years have
> seen quite a few changes, and have even resulted in changes for when
> packets are effected by what chain (INPUT, OUTPUT, NAT, etc!).
>
> Anyhow, try the above for a start, if you think that packets should be in
> that table, but don't seem to be getting there! Adding iptables to
the mix, can help.
>
>
>
>
> On Wed, 02 Sep 2009 08:44:06 -0400
> Bill Strosberg <oclug at strosberg.com> wrote:
>
>
>> All:
>>
>> I'm reposting this here as it seems the tech list isn't getting a lot
>> of traffic since the last time I was there.
>>
>>
---------------------------------------------------------------------------------------
>>
>> It's been years since I posted here. I've got a situation that I could
>> use some help on.
>>
>> I've got a client who is doing some interesting things. I've got a
>> firewall with four Ethernet interfaces in that connects to the Internet
>> via PPPoE.
>>
>> eth0 - Internal private network
>> eth1 - Public wireless network for their clients and visitor use
>> eth2 - connection to DSL via PPPoE
>> eth3 - connection to internal VOIP system (use for failover if dedicated
>> VOIP internet connection fails)
>> tun0 - OpenVPN
>> ppp0 - External connection
>>
>> Everything has worked fine in this site for years. The client recently
>> decided to move to a VOIP system for their internal phones, and it has
>> it's own Internet connection to the provider. The VOIP provider's
>> proprietary router has an Ethernet interface to allow failover
>> connection to a secondary provider if their own network fails.
>>
>> eth3 is set up as static 10.20.0.2/255.255.0.0/16 with the external
>> Ethernet interface on the VOIP ro222.88.20.0uter (10.20.0.1) as the
default gateway
>> on the network.
>>
>> I've set up iproute2 to add a new table in /etc/iproute2/rt_tables:
>>
>> 100 voip_provider
>> 255 local
>> 254 main
>> 253 default
>>
>> In /etc/network I've added a script if-post-up-eth3.sh:
>>
>> ip rule add from 222.88.20.0/24 table voip_provider
>> ip rule add from 222.88.21.0/24 table voip_provider
>> ip rule add from 222.88.22.0/24 table voip_provider
>> ip route add default via 10.20.0.1 dev eth3 table voip_provider
>> ip route flush cache
>>
>> ip masq is working for eth3.
>>
>> I can connect a PC on the eth3 10.20.0.0/16 network and it has no
>> problem surfing etc.
>>
>> What I want to do is have packets from all of the specified external
>> subnets routed out of the firewall to the address 10.20.0.1 on eth3.
>> Basically, all external traffic from these source address ranges need to
>> be forwarded to the VOIP provider's router, with no exception.
>>
>> Any ideas?
>>
>> --
>> Bill S
>>
>> --
>> OCLUG general discussion list
>> OCLUG at lists.oclug.on.ca
>> http://oclug.on.ca/mailman/listinfo/oclug
>>
Brad:
I guess I wasn't clear (not an unusual case).
I only want packets from the VOIP provider's specified public subnets to
route to the eth3 interface - hence my attempt at source routing. All
other packets are handled as per ip masq - sent back to their
originating internal network or talking directly to the firewall.
Basically, the VOIP provider needs to be able to talk to their router on
demand from outside the firewall if their own ppp interface is down. It
is an externally hosted VOIP situation, where the VOIP branch exchange
is somewhere in the Internet cloud.
I'll read through your example and response in depth to understand
things better now.
Thanks!
--
Bill
More information about the OCLUG
mailing list