On 11/12/2010 11:29 AM, Tom Eastep wrote:
>
> One key piece of information that was omitted is that your Shorewall
> configuration uses policy routing (providers).
>
> - Therefore, the firewall apparently ignores the packet even though
>    there is a perm ARP table entry for 10.1.19.248.
>
>       ? (10.1.19.248) at * PERM PUP on eth1.4
>
> When you have VPN connections that come and go, it is recommended that
> you set USE_DEFAULT_RT=Yes which causes all packets to be first routed
> via the main table and only if they don't match an entry in the main
> table do they get sent to a provider table. In this configuration, there
> is no default route in the main table. This allows dynamic changes in
> the main table to be visible to all packets.
>

That was the fix, thank you.  I had turned off USE_DEFAULT_RT so that systems 
on 
the PROC (industrial) side of the network would have no knowledge of the routes 
on the CORP (business) side.

Is there any harm or advantage in using route_rules to accomplish the same 
thing?  ie, instead of having the corporate routes in route-eth1.2 so that they 
end up in the main table as in...

198.162.160.0/19 via 10.1.16.254 dev eth1.2
199.60.192.0/20 via 10.1.16.254 dev eth1.2
192.40.217.0/24 via 10.1.16.254 dev eth1.2
192.168.0.0/16 via 10.1.16.254 dev eth1.2
172.16.0.0/12 via 10.1.16.254 dev eth1.2
10.0.0.0/8 via 10.1.16.254 dev eth1.2

I add them to the route_rules as in...

#SOURCE                 DEST                    PROVIDER        PRIORITY
eth1.2                  -                       CORP            1000
eth1.3                  -                       CORP            1000
eth1.4                  -                       WRLS            1000
eth1.5                  -                       WRLS            1000
-                       198.162.160.0/19        CORP            1001
-                       199.60.192.0/20         CORP            1001
-                       192.40.217.0/24         CORP            1001
-                       192.168.0.0/16          CORP            1001
-                       172.16.0.0/12           CORP            1001
-                       10.0.0.0/8              CORP            1001

With the resulting routing senario.

Routing Rules

0:      from all lookup 255
999:    from all lookup main
1000:   from all iif eth1.2 lookup CORP
1000:   from all iif eth1.3 lookup CORP
1000:   from all iif eth1.4 lookup WRLS
1000:   from all iif eth1.5 lookup WRLS
1001:   from all to 198.162.160.0/19 lookup CORP
1001:   from all to 199.60.192.0/20 lookup CORP
1001:   from all to 192.40.217.0/24 lookup CORP
1001:   from all to 192.168.0.0/16 lookup CORP
1001:   from all to 172.16.0.0/12 lookup CORP
1001:   from all to 10.0.0.0/8 lookup CORP
10000:  from all fwmark 0x1 lookup CORP
10001:  from all fwmark 0x2 lookup WRLS
20000:  from 10.1.16.22 lookup CORP
20256:  from 204.244.116.180 lookup WRLS
32767:  from all lookup default

Table CORP:

10.1.16.254 dev eth1.2  scope link  src 10.1.16.22
default via 10.1.16.254 dev eth1.2  src 10.1.16.22

Table default:

default
         nexthop via 10.1.16.254  dev eth1.2 weight 1
         nexthop via 204.244.116.190  dev eth0 weight 1

Table main:

204.244.116.128/26 dev eth0  proto kernel  scope link  src 204.244.116.180
10.1.20.0/24 dev eth1.5  proto kernel  scope link  src 10.1.20.1
10.1.16.0/24 dev eth1.2  proto kernel  scope link  src 10.1.16.22
10.1.17.0/24 dev eth1.3  proto kernel  scope link  src 10.1.17.1
10.1.19.0/24 dev eth1.4  proto kernel  scope link  src 10.1.19.1

Table WRLS:

204.244.116.190 dev eth0  scope link  src 204.244.116.180
default via 204.244.116.190 dev eth0  src 204.244.116.180


> The alternative is to include ppp0 in the COPY column for the WRLS
> provider and restart Shorewall each time that a pptp link comes up.
>
I don't think I want the firewall changing on a busy router.

One other question.  How do I force the firewall itself to use eth0 and its 
default route for outgoing connections?  As it is I have a 50/50 chance of 
hitting the corporate ISA server for outgoing connections for yum updates and 
ssh sessions.  It is just those two protocols that I am concerned about.  Would 
it fit in tcrules?

Thanks again Tom for your help.

------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to