Re: Strange setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux