Mike Lander wrote:
> I am building a shorewall box that the last post has the SSH error and
> wanted
> some feedback from the list if possible. At first I thought the two ISP's I
> building this
> for had two T-1's with FQ ip's as it. I have the box built for this ready to
> go.
> Now I find out that one of the T-1's is non-routed with 5 useable ips
> /29--Good
> the other T-1 is natted in using one of the local lan Ip's. Both full
> T-1's-----Not so Good
> The Idea is to load balance and route specific stuff like mail etc:
> The second ISP will NOT give me a FQ ip. Shorewall fits the bill
> perfect for this need.
> Currently the network is using routeback and static routes
> to route specific traffic to the natted ISP gateway. The only solution I
> could
> think of was, I asked the ISP if they could change the currently
> natted gateway (lan ip on internal) to a different Class 3 IP such as
> 10.15.75.1
> then I could configure my second ISP to the same network
> 10.15.75.2 and track and balance the routes.
> Now would there be a better way to do this and leave the
> Natted ISP with the same IP as the lan (loc) if ??
I'd really need to see the routing tables and route rules from a
shorewall dump to have a better understanding of your layout. Having
said that, when you use the providers file, there will be a host route
to that isp's gateway created in that isp's routing table, which should
override any network route using that address space. In short it should
work without changing any addressing, I have that running now:
Table LOC:
10.3.0.1 dev eth0 scope link src 10.3.0.75 <<==host route to gateway=
10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.75
default via 10.3.0.1 dev eth0
Table SHAW:
24.78.192.1 dev eth1 scope link src 24.78.192.197
10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.75
24.78.192.0/23 dev eth1 proto kernel scope link src 24.78.192.197
169.254.0.0/16 dev eth1 scope link
default via 24.78.192.1 dev eth1
Table main:
10.3.0.0/24 dev eth0 proto kernel scope link src 10.3.0.75
24.78.192.0/23 dev eth1 proto kernel scope link src 24.78.192.197
169.254.0.0/16 dev eth1 scope link
default
nexthop via 24.78.192.1 dev eth1 weight 1
nexthop via 10.3.0.1 dev eth0 weight 1
So any thing that uses the "loc" addressing would hit this route rule:
20256: from 10.3.0.75 lookup LOC
and then use the LOC routing table where there is the host route to the
gateway. Having 1 (like me, I trust my loc zone) or 2 interfaces (much
safer, I had that setup too, till the nic died, too lazy to change it.)
for that address space should not matter, as long as that host route is
present, the traffic *should* find the gateway. There might be other
things that I had to do to pull this off, but I just can't recall what,
if any, at the moment.
< Just saw Tom's post, I don't type or copy&paste that fast...>
Just because I have this working doesn't diminish Tom's warning about
routing/ARP hell, (Think my fire is out now, it been a couple of years
;) ) you have been warned...
Think I had to use a /32 mask on the nic that was connected to the
gateway in the 2 interface setup, so there would be no network route
present for it, just the above host route to the gateway.
Hope it helps,
Jerry
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
