Strange setup

Strange setup

[Evan Borgstrom]

I've got sort of a strange setup that I'm looking to accomplish some
strange async routing. I know how I want to accomplish it and am pretty
sure that I can do it with netfilter but just can't seem to find the
proper way.

Here's the rundown on the network setup:

[ LAN ] --
[ DMZ ] -- [ Firewall/Router ] -- [ WAN ]
                    |
                    |
                 [ WLAN ]


The WLAN is between myself and a couple of other people in my building to
provide redundant paths out of each of our networks and is working
beautifully. We all advertise (via BGP) blocks close to us to each to
provide the shortest path as well.

Comming from the WAN I have a /29 routed to the DMZ which services a
number of machines that provide different services.

The firewall/router is a linux box that is running iptables.


Now the problem:
Because of the advertisments comming over the WLAN I now have about 40
routes in the kernel routing table. Most of them are not very specific
since we advertise our ISP's blocks to each other, so I have routes for
/16's, /21's, etc... What happens is when someone that resides in one of
these blocks that I'm getting advertisements for tries to access an
address in my /29 their return path follows the advertisment over the
WLAN.

Using the iproute2 package I've created a second routing table with a
single default route out my WAN default route. I'm hopping that there's a
way to tag the connection in the conntrack table and then -j MARK it when
a related,established packet comes back so that I use the iproute2 package
to specify that the second routing table will be used.

Anyone know of a way that I can accomplish this?

Thanks in advance,
Evan

-- 
Evan Borgstrom <evan@unixpimps.org>
http://www.unixpimps.org - SIG:ILL

Re: Strange setup

[Evan Borgstrom]

> Now the problem:
> Because of the advertisments comming over the WLAN I now have about 40
> routes in the kernel routing table. Most of them are not very specific
> since we advertise our ISP's blocks to each other, so I have routes for
> /16's, /21's, etc... What happens is when someone that resides in one of
> these blocks that I'm getting advertisements for tries to access an
> address in my /29 their return path follows the advertisment over the
> WLAN.

I guess I need to explain this a little more.
The WLAN uses RFC1918 IP space and therefore requires it to be NAT'd when
it leaves one of the other nodes on the WLAN. This causes the return
packet to the user who made the request to the /29 to be different and
causes them to be dropped.


-- 
Evan Borgstrom <evan@unixpimps.org>
http://www.unixpimps.org - SIG:ILL

Re: Strange setup

[Peter Johnson]

If this traffic isn't LAN related then just do

ip rule add from $WAN_IP table $TABLE_NAME

ip route add default via $WAN_PEER_IP dev $WAN_IF table $TABLE_NAME

This will add a source based route so that traffic entering on the
$WAN_IF has its resonses exit on the $WAN_IF.

See the Advanced Routing HOWTO for more info.

Regards,

PJ

On Mon, 2003-01-20 at 08:35, Evan Borgstrom wrote:
> I've got sort of a strange setup that I'm looking to accomplish some
> strange async routing. I know how I want to accomplish it and am pretty
> sure that I can do it with netfilter but just can't seem to find the
> proper way.
> 
> Here's the rundown on the network setup:
> 
> [ LAN ] --
> [ DMZ ] -- [ Firewall/Router ] -- [ WAN ]
>                     |
>                     |
>                  [ WLAN ]
> 
> 
> The WLAN is between myself and a couple of other people in my building to
> provide redundant paths out of each of our networks and is working
> beautifully. We all advertise (via BGP) blocks close to us to each to
> provide the shortest path as well.
> 
> Comming from the WAN I have a /29 routed to the DMZ which services a
> number of machines that provide different services.
> 
> The firewall/router is a linux box that is running iptables.
> 
> 
> Now the problem:
> Because of the advertisments comming over the WLAN I now have about 40
> routes in the kernel routing table. Most of them are not very specific
> since we advertise our ISP's blocks to each other, so I have routes for
> /16's, /21's, etc... What happens is when someone that resides in one of
> these blocks that I'm getting advertisements for tries to access an
> address in my /29 their return path follows the advertisment over the
> WLAN.
> 
> Using the iproute2 package I've created a second routing table with a
> single default route out my WAN default route. I'm hopping that there's a
> way to tag the connection in the conntrack table and then -j MARK it when
> a related,established packet comes back so that I use the iproute2 package
> to specify that the second routing table will be used.
> 
> Anyone know of a way that I can accomplish this?
> 
> Thanks in advance,
> Evan
> 
> -- 
> Evan Borgstrom <evan@unixpimps.org>
> http://www.unixpimps.org - SIG:ILL
> 
> 
> 
-- 

'Conformity is the jailer of freedom and the enemy of growth.' - John F.
Kennedy

Re: Strange setup

[Evan Borgstrom]

That's not gonna work in my sitation. I guess I need to further explain
how I'm looking for traffic to flow.


If traffic is from the WAN bound for the DMZ then the return path needs to
leave the WAN.

If traffic is from the WLAN bound for the DMZ then the return path needs
to leave the WLAN.

So, I need to be able to mark the connection somehow as the inbound
traffic from the WAN is bound for the DMZ so that I can specify a
different routing table for the return path so that it will leave the WAN
as well, otherwise it might end up with a more specific route through the
WLAN which will cause problems.

Does that make more sense?

-Evan

> If this traffic isn't LAN related then just do
>
> ip rule add from $WAN_IP table $TABLE_NAME
>
> ip route add default via $WAN_PEER_IP dev $WAN_IF table $TABLE_NAME
>
> This will add a source based route so that traffic entering on the
> $WAN_IF has its resonses exit on the $WAN_IF.
>
> See the Advanced Routing HOWTO for more info.
>
> Regards,
>
> PJ
>
> On Mon, 2003-01-20 at 08:35, Evan Borgstrom wrote:
>> I've got sort of a strange setup that I'm looking to accomplish some
>> strange async routing. I know how I want to accomplish it and am
>> pretty sure that I can do it with netfilter but just can't seem to
>> find the proper way.
>>
>> Here's the rundown on the network setup:
>>
>> [ LAN ] --
>> [ DMZ ] -- [ Firewall/Router ] -- [ WAN ]
>>                     |
>>                     |
>>                  [ WLAN ]
>>
>>
>> The WLAN is between myself and a couple of other people in my building
>> to provide redundant paths out of each of our networks and is working
>> beautifully. We all advertise (via BGP) blocks close to us to each to
>> provide the shortest path as well.
>>
>> Comming from the WAN I have a /29 routed to the DMZ which services a
>> number of machines that provide different services.
>>
>> The firewall/router is a linux box that is running iptables.
>>
>>
>> Now the problem:
>> Because of the advertisments comming over the WLAN I now have about 40
>> routes in the kernel routing table. Most of them are not very specific
>> since we advertise our ISP's blocks to each other, so I have routes
>> for /16's, /21's, etc... What happens is when someone that resides in
>> one of these blocks that I'm getting advertisements for tries to
>> access an address in my /29 their return path follows the advertisment
>> over the WLAN.
>>
>> Using the iproute2 package I've created a second routing table with a
>> single default route out my WAN default route. I'm hopping that
>> there's a way to tag the connection in the conntrack table and then -j
>> MARK it when a related,established packet comes back so that I use the
>> iproute2 package to specify that the second routing table will be
>> used.
>>
>> Anyone know of a way that I can accomplish this?
>>
>> Thanks in advance,
>> Evan
>>
>> --
>> Evan Borgstrom <evan@unixpimps.org>
>> http://www.unixpimps.org - SIG:ILL
>>
>>
>>
> --
>
> 'Conformity is the jailer of freedom and the enemy of growth.' - John F.
> Kennedy


-- 
Evan Borgstrom <evan@unixpimps.org>
http://www.unixpimps.org - SIG:ILL

Re: Strange setup

[Peter Johnson]

Ok now I see the problem. The same external source ip can send to the
same internal DMZ IP ... correct ?


[Appolodies for the poor ASCII art]

                                          _______________
       /------- WAN  ----- \             /               \
source                       router ---- | DMZ (dest)     |
       \------- WLAN ----- /             \_______________/



On Mon, 2003-01-20 at 11:45, Evan Borgstrom wrote:
> That's not gonna work in my sitation. I guess I need to further explain
> how I'm looking for traffic to flow.
> 
> 
> If traffic is from the WAN bound for the DMZ then the return path needs to
> leave the WAN.
> 
> If traffic is from the WLAN bound for the DMZ then the return path needs
> to leave the WLAN.
> 
> So, I need to be able to mark the connection somehow as the inbound
> traffic from the WAN is bound for the DMZ so that I can specify a
> different routing table for the return path so that it will leave the WAN
> as well, otherwise it might end up with a more specific route through the
> WLAN which will cause problems.
> 
> Does that make more sense?
> 
> -Evan
> 
> > If this traffic isn't LAN related then just do
> >
> > ip rule add from $WAN_IP table $TABLE_NAME
> >
> > ip route add default via $WAN_PEER_IP dev $WAN_IF table $TABLE_NAME
> >
> > This will add a source based route so that traffic entering on the
> > $WAN_IF has its resonses exit on the $WAN_IF.
> >
> > See the Advanced Routing HOWTO for more info.
> >
> > Regards,
> >
> > PJ
> >
> > On Mon, 2003-01-20 at 08:35, Evan Borgstrom wrote:
> >> I've got sort of a strange setup that I'm looking to accomplish some
> >> strange async routing. I know how I want to accomplish it and am
> >> pretty sure that I can do it with netfilter but just can't seem to
> >> find the proper way.
> >>
> >> Here's the rundown on the network setup:
> >>
> >> [ LAN ] --
> >> [ DMZ ] -- [ Firewall/Router ] -- [ WAN ]
> >>                     |
> >>                     |
> >>                  [ WLAN ]
> >>
> >>
> >> The WLAN is between myself and a couple of other people in my building
> >> to provide redundant paths out of each of our networks and is working
> >> beautifully. We all advertise (via BGP) blocks close to us to each to
> >> provide the shortest path as well.
> >>
> >> Comming from the WAN I have a /29 routed to the DMZ which services a
> >> number of machines that provide different services.
> >>
> >> The firewall/router is a linux box that is running iptables.
> >>
> >>
> >> Now the problem:
> >> Because of the advertisments comming over the WLAN I now have about 40
> >> routes in the kernel routing table. Most of them are not very specific
> >> since we advertise our ISP's blocks to each other, so I have routes
> >> for /16's, /21's, etc... What happens is when someone that resides in
> >> one of these blocks that I'm getting advertisements for tries to
> >> access an address in my /29 their return path follows the advertisment
> >> over the WLAN.
> >>
> >> Using the iproute2 package I've created a second routing table with a
> >> single default route out my WAN default route. I'm hopping that
> >> there's a way to tag the connection in the conntrack table and then -j
> >> MARK it when a related,established packet comes back so that I use the
> >> iproute2 package to specify that the second routing table will be
> >> used.
> >>
> >> Anyone know of a way that I can accomplish this?
> >>
> >> Thanks in advance,
> >> Evan
> >>
> >> --
> >> Evan Borgstrom <evan@unixpimps.org>
> >> http://www.unixpimps.org - SIG:ILL
> >>
> >>
> >>
> > --
> >
> > 'Conformity is the jailer of freedom and the enemy of growth.' - John F.
> > Kennedy
> 
> 
> -- 
> Evan Borgstrom <evan@unixpimps.org>
> http://www.unixpimps.org - SIG:ILL
> 
> 
> 
-- 

Some people wish to get what they deserve, while others fear the same.

Homepage: http://www.wizardslair.net

Re: Strange setup

[Peter Johnson]

Ok, gotcha now...

Still do 
ip rule add from $WAN_IP table $WAN_TABLE
ip rule add from $WLAN_IP table $WLAN_TABLE
and 
ip route add default via $WAN_PEER_IP dev $WAN_IF table $WAN_TABLE
ip route add default via $WLAN_PEER_IP dev $WAN_IF table $WLAN_TABLE

Add iptables rules approximately as follows:

$IPTABLES -t nat -A PREROUTING -i $WAN_IF -j DNAT $DMZ_IP_0-16
$IPTABLES -t nat -A PREROUTING -i $WLAN_IF -j DNAT $DMZ_IP_17-32

$IPTABLES -t nat -A POSTROUTING -o $WAN_IF -j SNAT $WAN_IP
$IPTABLES -t nat -A POSTROUTING -o $WLAN_IF -j SNAT $WLAN_IP

$IPTABLES -t filter -A FORWARD -i $WAN_IF -o $DMZ_IF -j ACCEPT
$IPTABLES -t filter -A FORWARD -i $WLAN_IF -o $DMZ_IF -j ACCEPT

That takes care of the initial connection i.e. SYN packets. The IPTables
nat table is only used on the initial packet on each connection.

For the actual routing, the only thing that I can think of is assigning
two IPs (aliases) to each server in the DMZ say .0-16 for WAN and 17-32
for WLAN then using

$IPTABLES -t mangle -A PREROUTING -s $DMZ_IP_0-16 -j MARK --set-mark 1
and
$IPTABLES -t mangle -A PREROUTING -s $DMZ_IP_17-32 -j MARK --set-mark 2

then add

ip rule add fwmark 1 table $WAN_TABLE
and
ip rule add fwmark 2 table $WLAN_TABLE


Sorry but that is all I can come up with at the moment.

PJ

-- 

Quitters never win, and winners never quit, but those who never quit AND
never win are idiots.

Re: Strange setup

[Evan Borgstrom]

Thanks for the reply Peter,

That's the sortta setup I was playing with yesterday. Kindda kludgey but
it would work.

What would be nice is if connection tracking would log the source
interface of the last packet. That way in the PREROUTING table I could
check that and change the mark on the packet so that it would pick a
different routing table. Perhaps I should look at implementing that on
my setup to see how it works...

The only other way I thought of doing it was using TOS bits inside the
network (say give an 8 to anything coming over the WAN and a 16 to
anything coming over the WLAN), but I can't find a way to make my sun
boxes set the same TOS for related pakets...

If anyone else has ideas, comments, etc... on this I'm always up to
listen.

-Evan

On Mon, 2003-01-20 at 02:50, Peter Johnson wrote:
> Ok, gotcha now...
> 
> Still do 
> ip rule add from $WAN_IP table $WAN_TABLE
> ip rule add from $WLAN_IP table $WLAN_TABLE
> and 
> ip route add default via $WAN_PEER_IP dev $WAN_IF table $WAN_TABLE
> ip route add default via $WLAN_PEER_IP dev $WAN_IF table $WLAN_TABLE
> 
> Add iptables rules approximately as follows:
> 
> $IPTABLES -t nat -A PREROUTING -i $WAN_IF -j DNAT $DMZ_IP_0-16
> $IPTABLES -t nat -A PREROUTING -i $WLAN_IF -j DNAT $DMZ_IP_17-32
> 
> $IPTABLES -t nat -A POSTROUTING -o $WAN_IF -j SNAT $WAN_IP
> $IPTABLES -t nat -A POSTROUTING -o $WLAN_IF -j SNAT $WLAN_IP
> 
> $IPTABLES -t filter -A FORWARD -i $WAN_IF -o $DMZ_IF -j ACCEPT
> $IPTABLES -t filter -A FORWARD -i $WLAN_IF -o $DMZ_IF -j ACCEPT
> 
> That takes care of the initial connection i.e. SYN packets. The IPTables
> nat table is only used on the initial packet on each connection.
> 
> For the actual routing, the only thing that I can think of is assigning
> two IPs (aliases) to each server in the DMZ say .0-16 for WAN and 17-32
> for WLAN then using
> 
> $IPTABLES -t mangle -A PREROUTING -s $DMZ_IP_0-16 -j MARK --set-mark 1
> and
> $IPTABLES -t mangle -A PREROUTING -s $DMZ_IP_17-32 -j MARK --set-mark 2
> 
> then add
> 
> ip rule add fwmark 1 table $WAN_TABLE
> and
> ip rule add fwmark 2 table $WLAN_TABLE
> 
> 
> Sorry but that is all I can come up with at the moment.
> 
> PJ
-- 
Evan Borgstrom <evan@unixpimps.org>
http://www.unixpimps.org
http://www.ragga-jungle.com

ip_conntrack: table full, dropping packet.

[hare ram]

Hi

iam getting this error
what is the problem

when i do dmesg in redhat

ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
NET: 1 messages suppressed.
ip_conntrack: table full, dropping packet.
NET: 3 messages suppressed.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
NET: 10 messages suppressed.
ip_conntrack: table full, dropping packet.
NET: 7 messages suppressed.
ip_conntrack: table full, dropping packet.
NET: 5 messages suppressed.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
NET: 2 messages suppressed.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
NET: 2 messages suppressed.
ip_conntrack: table full, dropping packet.
NET: 5 messages suppressed.
ip_conntrack: table full, dropping packet.
NET: 3 messages suppressed.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
ip_conntrack: table full, dropping packet.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.
61.218.53.226 sent an invalid ICMP error to a broadcast.

Re: ip_conntrack: table full, dropping packet.

[Maciej Soltysiak]

> iam getting this error
> what is the problem
The conntrack table is full and your machine can not store
more connection tracking information, as each tracked connection
takes up some memory.

Increase your
/proc/sys/net/ipv4/ip_conntrack_max

as described in the FAQ. The FAQ shows how to calculate the value
for your system.

Regards,
Maciej Soltysiak

Re: Strange setup

[Peter Johnson]

ooops ... before too many people comment, the IPs should have been 0-15
and 16-31


On Mon, 2003-01-20 at 18:50, Peter Johnson wrote:
> Ok, gotcha now...
> 
> Still do 
> ip rule add from $WAN_IP table $WAN_TABLE
> ip rule add from $WLAN_IP table $WLAN_TABLE
> and 
> ip route add default via $WAN_PEER_IP dev $WAN_IF table $WAN_TABLE
> ip route add default via $WLAN_PEER_IP dev $WAN_IF table $WLAN_TABLE
> 
> Add iptables rules approximately as follows:
> 
> $IPTABLES -t nat -A PREROUTING -i $WAN_IF -j DNAT $DMZ_IP_0-16
> $IPTABLES -t nat -A PREROUTING -i $WLAN_IF -j DNAT $DMZ_IP_17-32
> 
> $IPTABLES -t nat -A POSTROUTING -o $WAN_IF -j SNAT $WAN_IP
> $IPTABLES -t nat -A POSTROUTING -o $WLAN_IF -j SNAT $WLAN_IP
> 
> $IPTABLES -t filter -A FORWARD -i $WAN_IF -o $DMZ_IF -j ACCEPT
> $IPTABLES -t filter -A FORWARD -i $WLAN_IF -o $DMZ_IF -j ACCEPT
> 
> That takes care of the initial connection i.e. SYN packets. The IPTables
> nat table is only used on the initial packet on each connection.
> 
> For the actual routing, the only thing that I can think of is assigning
> two IPs (aliases) to each server in the DMZ say .0-16 for WAN and 17-32
> for WLAN then using
> 
> $IPTABLES -t mangle -A PREROUTING -s $DMZ_IP_0-16 -j MARK --set-mark 1
> and
> $IPTABLES -t mangle -A PREROUTING -s $DMZ_IP_17-32 -j MARK --set-mark 2
> 
> then add
> 
> ip rule add fwmark 1 table $WAN_TABLE
> and
> ip rule add fwmark 2 table $WLAN_TABLE
> 
> 
> Sorry but that is all I can come up with at the moment.
> 
> PJ
> 
> -- 
> 
> Quitters never win, and winners never quit, but those who never quit AND
> never win are idiots.
> 
> 
> 
> 
-- 

The truth is out there? Does anyone know the URL?

Homepage: http://www.wizardslair.net

Re: Strange setup

[Evan Borgstrom]

Ok, I've come across how cisco implements exactly what I'm looking to
do. I realize that this is not a cisco, but possibly from reading this
someone will further understand what I'm trying to accomplish and think
of a way to do so with netfilter.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/secur_c/scprt3/screflex.htm

Basically, Reflexive access lists (explained in that URL) allow you to
use a 'reflect' target when you are creating an access list, this
reflect target then ensures that traffic will leave the interface the
session began on. For instance, if I have eth1 and gre1 both possible
interfaces for inbound traffic to the DMZ, when traffic enters eth1 I
need a mechanism to ensure it leaves eth1 as well even if a more
specific route exists pointing to gre1.

Anyone got any ideas?

-Evan

On Mon, 2003-01-20 at 09:49, Evan Borgstrom wrote:
> Thanks for the reply Peter,
> 
> That's the sortta setup I was playing with yesterday. Kindda kludgey but
> it would work.
> 
> What would be nice is if connection tracking would log the source
> interface of the last packet. That way in the PREROUTING table I could
> check that and change the mark on the packet so that it would pick a
> different routing table. Perhaps I should look at implementing that on
> my setup to see how it works...
> 
> The only other way I thought of doing it was using TOS bits inside the
> network (say give an 8 to anything coming over the WAN and a 16 to
> anything coming over the WLAN), but I can't find a way to make my sun
> boxes set the same TOS for related pakets...
> 
> If anyone else has ideas, comments, etc... on this I'm always up to
> listen.
> 
> -Evan
> 
> On Mon, 2003-01-20 at 02:50, Peter Johnson wrote:
> > Ok, gotcha now...
> > 
> > Still do 
> > ip rule add from $WAN_IP table $WAN_TABLE
> > ip rule add from $WLAN_IP table $WLAN_TABLE
> > and 
> > ip route add default via $WAN_PEER_IP dev $WAN_IF table $WAN_TABLE
> > ip route add default via $WLAN_PEER_IP dev $WAN_IF table $WLAN_TABLE
> > 
> > Add iptables rules approximately as follows:
> > 
> > $IPTABLES -t nat -A PREROUTING -i $WAN_IF -j DNAT $DMZ_IP_0-16
> > $IPTABLES -t nat -A PREROUTING -i $WLAN_IF -j DNAT $DMZ_IP_17-32
> > 
> > $IPTABLES -t nat -A POSTROUTING -o $WAN_IF -j SNAT $WAN_IP
> > $IPTABLES -t nat -A POSTROUTING -o $WLAN_IF -j SNAT $WLAN_IP
> > 
> > $IPTABLES -t filter -A FORWARD -i $WAN_IF -o $DMZ_IF -j ACCEPT
> > $IPTABLES -t filter -A FORWARD -i $WLAN_IF -o $DMZ_IF -j ACCEPT
> > 
> > That takes care of the initial connection i.e. SYN packets. The IPTables
> > nat table is only used on the initial packet on each connection.
> > 
> > For the actual routing, the only thing that I can think of is assigning
> > two IPs (aliases) to each server in the DMZ say .0-16 for WAN and 17-32
> > for WLAN then using
> > 
> > $IPTABLES -t mangle -A PREROUTING -s $DMZ_IP_0-16 -j MARK --set-mark 1
> > and
> > $IPTABLES -t mangle -A PREROUTING -s $DMZ_IP_17-32 -j MARK --set-mark 2
> > 
> > then add
> > 
> > ip rule add fwmark 1 table $WAN_TABLE
> > and
> > ip rule add fwmark 2 table $WLAN_TABLE
> > 
> > 
> > Sorry but that is all I can come up with at the moment.
> > 
> > PJ
-- 
Evan Borgstrom <evan@unixpimps.org>
http://www.unixpimps.org
http://www.ragga-jungle.com