On Thu, Sep 5, 2013 at 2:40 PM, Tracy Reed <tr...@ultraviolet.org> wrote:

> I've got a few bucks available for a really good Shorewall consultant
> since I
> haven't yet been able to figure this one out myself...
>
> On Tue, Sep 03, 2013 at 11:49:22AM PDT, Tracy Reed spake thusly:
> > Hello all,
> >
> > I am running shorewall-4.5.0.1 on CentOS 6.4 and having trouble getting
> certain
> > internal IP addresses to NAT out via certain interfaces. This is
> complicated by
> > the fact that I am using two different providers.
> >
> > First, my providers file (boiletplate comment lines removed):
> >
> > pbb     1       4       main            eth1            207.71.189.129
>  track,balance
> > vbb     2       5       main            eth2            217.240.176.1
> track,balance
> >
> > Then my masq file:
> >
> > eth1                    10.0.2.32/32    207.71.189.254  # mail server
> > eth1                    10.0.2.0/24     207.71.189.130  # everything
> else
> >
> > my tcrules:
> >
> > # Per the providers file, traffic marked 4 goes out PBB while traffic
> marked 5 goes out VBB.
> > # Default everything out of PBB. Should eventually change this to VBB.
> > 4       10.0.0.0/8              0.0.0.0/0
> > # All of this goes out VBB.
> > 5       10.0.2.37       0.0.0.0/0 # post
> > 5       10.0.2.8        0.0.0.0/0 # util1
> > 5       10.0.2.48       0.0.0.0/0 # ftp
> > 5       10.0.2.106      0.0.0.0/0 # rezaspider
> > 5       10.0.2.111      0.0.0.0/0 # spider1-eth0:1
> > 5       10.0.2.112      0.0.0.0/0 # spider1-eth0:2
> > 5       10.0.2.113      0.0.0.0/0 # spider1-eth0:3
> > 5       10.0.2.114      0.0.0.0/0 # spider1-eth0:4
> >
> > And my rules file:
> > # Let the many spider1 interfaces access the outside for spidering
> > ACCEPT  dmz:10.0.2.110          vbb                     tcp     http
> > ACCEPT  dmz:10.0.2.110          vbb                     tcp     https
> > ACCEPT  dmz:10.0.2.111          vbb                     tcp     http
> > ACCEPT  dmz:10.0.2.111          vbb                     tcp     https
> > ACCEPT  dmz:10.0.2.112          vbb                     tcp     http
> > ACCEPT  dmz:10.0.2.112          vbb                     tcp     https
> > ACCEPT  dmz:10.0.2.113          vbb                     tcp     http
> > ACCEPT  dmz:10.0.2.113          vbb                     tcp     https
> >
> > I'm ultimately trying to get any traffic from 10.0.2.111 to go out
> > 217.240.176.67 and traffic from 10.0.2.112 to go out 217.240.176.68 etc.
> With
> > this config I cannot source a connection from 10.0.2.111 to any outside
> IP
> > address:
> >
> > [root@spider1 ~]# curl --interface eth0:1 http://ifconfig.me
> > curl: (7) couldn't connect to host
> > [root@spider1 ~]# /sbin/ifconfig eth0:1
> > eth0:1    Link encap:Ethernet  HWaddr 00:16:3E:0D:15:21
> >           inet addr:10.0.2.111  Bcast:10.0.2.255  Mask:255.255.255.0
> >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >           Interrupt:23
> >
> > What am I doing wrong here? I am somewhat confused on whether this sort
> of
> > masq/NAT is to be done through the masq file or the tcrules file. The
> first
> > throught is to try to do this through the masq file but the
> shorewall-masq
> > manpage says:
> >
> >     Warning
> >     If you have more than one ISP link, adding entries to this file will
> not
> >     force connections to go out through a particular link. You must use
> entries
> >     in shorewall-rtrules[1](5) or PREROUTING entries in
> shorewall-tcrules[2](5)
> >     to do that.
> >
> > So that is what I am trying to do. Does this mean that the masq file
> serves no
> > purpose at all in a multi-ISP setup such as I have?
> >
> > Which is preferred, rtrules or tcrules? I'm going with tcrules for now
> since
> > that is where I'm setting my traffic with mark 4 which sends it out the
> "pbb"
> > provider.
> >
> > --
> > Tracy Reed
>
>
> Traffic control can be implemented in a few ways, YMMV but my experience
is that

tcrules marks the packets.
masq changes the address when exiting an interface.
what you are missing is entries in rtrules to decide where the packets go.

I've extracted from my configuration the following example:

rtrules:  The following states the 192.168.1.0/24 subnet routes via
provider "blkmDP" with a priority of 26101
192.168.1.0/24 - blkmDP 26101

providers: This provider has an IP of 10.3.11.64 from my perspective gw is
10.3.11.1
blkmDP 4 103 - eth1.9:10.3.11.64 10.3.11.1 loose

masq: everything from 192.168.1.0/24 going via eth1.9 should become
10.3.11.64
eth1.9 192.168.1.0/24 10.3.11.64

tcrules: nothing interesting here.
empty

I believe there are some flags in the shorewall.conf that may change the
above behaviour though, so maybe relevant:
TC=
TC_ENABLED=Yes
TC_EXPERT=No
CLEAR_TC=Yes
WIDE_TC_MARKS=No
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to